DRAFT, REVIEW, PUBLISH
Improve a page without losing control of what is live
Arrange supported content blocks, review the draft and publish with the right permissions. Keep a clear distinction between editorial work and the public result.
Make the next improvement concrete
A website editor should make it possible to improve a particular explanation, image or next step. Tsumira works with structured pages and supported blocks, so the team can make that change without rewriting an entire site. Draft editing, public release and recovery are separate actions. This helps a company work on content while keeping responsibility for what a visitor can actually see.
Compose content from supported blocks
The editor supports practical page elements such as a hero, rich text, images, calls to action and supported content lists or grids. Add, remove and move blocks to give the page a useful reading order. Check links and image references in their actual context. The available structures provide an editing vocabulary; they do not mean that arbitrary application code or every imaginable custom widget can be placed on a public page.
- Structured content blocks
- Intentional section order
- Links and media in context
Keep review separate from publication
A person may have permission to improve a draft without having permission to publish it. Publication follows the page-status permission and the relevant public readiness checks. Review the visitor’s question, supporting detail and next action before releasing the draft. An AI-assisted editing proposal also needs that editorial judgment. Preparing improved wording does not itself authorize a public promise or make hidden internal information appropriate for publication.
- Draft editing permissions
- Authorized public release
- Human review of AI-assisted changes
Recover the previous public version deliberately
The supported rollback action restores the previous published page version through its publication history and recovery receipt. It is a defined recovery operation, not unlimited time travel for every action. Unpublishing and deleting are different decisions, and deletion is not a promise of later restoration. Record why a correction was necessary and inspect the public page after recovery rather than assuming that a successful edit also proves the visitor journey is correct.
- Previous published version recovery
- Publication history and receipts
- Deletion treated separately
A concrete workflow
Choose the page
Identify the visitor question and the exact section that needs improvement.
Edit the draft
Adjust supported blocks, wording, links and image selection.
Review and publish
Let an authorized person check the draft and release the intended page.
Verify or recover
Inspect the public result and use supported rollback if the previous publication is needed.
An illustrative working example
Example: correcting a service explanation
A team member improves the steps on a service page and replaces a misleading call to action. The draft is reviewed by the person responsible for publication, who checks the destination and mobile reading order. If the release introduces a material mistake, the previous published version can be restored using the supported recovery flow. The team then corrects the draft before a new release, rather than deleting the page and hoping to reconstruct it later.
Questions about this topic
Can someone edit without publishing?
Yes. Draft editing and the page-status publication permission are separate capabilities in the supported role model.
Can AI changes bypass review?
AI-assisted text preparation does not remove editorial responsibility or the authorization required to publish.
Does rollback restore any deleted page?
No. Previous-publication recovery is a specific supported operation. Hard deletion must not be treated as recoverable history.
Can we add any arbitrary widget?
The editor provides supported structured elements. This is not a claim that arbitrary scripts or every custom widget are accepted.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
Google Docs
Workflow concept: Review a revised service explanation before transferring its approved wording into the page draft.
Asana
Workflow concept: Track the responsible editor, reviewer and intended release for a specific page change.
Slack
Workflow concept: Discuss a publication correction and confirm when the actual public page has been checked.