Read the proposed change
Crew can discuss work and offer supported actions. A proposal should be reviewed as a request to change a specific record, not as a reason to skip your normal checks.
Confirm the website, target record and intended effect. If the proposal is broader than your request, ask for a narrower change before approving it.
Review in a consistent order
- Check the target article, post, page or setting.
- Read the current saved state.
- Compare the proposal with the outcome you requested.
- Verify facts, links, dates and destination selections.
- Confirm only the supported change you want.
- Reopen the record and inspect the saved result.
For a writing change, check that required conditions survived the rewrite. For a schedule, check the website’s timezone and source dependencies. For a page, check the visitor-facing result in preview.
Handle stale context
Another editor or a background task may change the record while you are discussing it. A stale revision or access failure should prompt a reload and comparison.
Do not keep retrying an old proposal without understanding what changed. Reframe the request against the latest saved version so the new work does not overwrite a colleague’s changes.
Keep publishing separate in your review
Editing content, approving it and delivering it are distinct events. Even where an assistant helps move through supported stages, the relevant permission and publishing checks remain in place.
Use recorded delivery results and public links to confirm publication. A conversational response that describes an intended action is not evidence that a provider accepted it.
When you lack permission, ask an organisation administrator to review your access or perform the appropriate action. Instructions in a chat do not grant administrative rights.