Less reading around the work. More help doing it.

What you will accomplish

Create a saved draft, move it through review, schedule it, then deliberately invalidate the approval. Finish by exporting your workspace and ending the demo.

1. Open the demo login. Go to Demo login, use the public credentials displayed there, and acknowledge the temporary sample-data environment. A successful login opens your isolated workspace. An existing valid session may resume it.
2. Create a simple draft. Open the content library and create a text post for a connected sample channel. Use a fictional title such as “Studio notes” and a short caption. Save it, then reload the page to see your server-saved work.
3. Try a change request. Send the complete draft for review. In approvals, request changes with a concrete note, such as “Clarify who this is for.” Return to the draft, make the revision, and submit it for review again.
4. Approve and schedule. Approve the revised post and choose a future date and time. Read the timezone label at the input; the calendar displays the saved instant using your workspace timezone. Scheduling is a plan, not an automatic publishing job.
5. Test the guardrail. Edit the scheduled content. The post returns to draft and the old schedule clears. Submit, approve, and schedule again only after the new version is ready.
6. Simulate publication deliberately. For an approved or scheduled post, use the explicitly labeled demo publishing action. It becomes published in the demo, but nothing goes to a social network and no engagement data is invented.
7. Inspect the record. Review the activity history. Compare your actions with labeled example analytics; sample engagement numbers are not evidence of a real audience seeing your post.
8. Export, then finish. Export your workspace from settings before signing out. Logout deletes that demo workspace. The session also expires after 24 hours, so do not use it as long-term storage.

Define “ready” before you define “approved.”

A review queue should contain decisions, not unfinished briefs. Agree on what a reviewer needs to see: the intended audience, final caption, destination, media rights, disclosures, and any timing constraint.

• Content: Is the message complete, accurate, and appropriate for the destination?
• Audience: Is the intended visibility explicit, especially when privacy choices affect distribution?
• Rights: Can the creator use the original media and music? Does commercial content need disclosure?
• Timing: Is there a reason to publish at the proposed time, and is the timezone understood?

Write change requests someone can act on.

“Needs work” creates another round of interpretation. A useful note identifies the problem and the expected correction without forcing the creator to guess.

In the demo, a change request returns the content to draft. The next review should assess the revised version, not assume that a previous approval still applies.

Separate the responsibilities in your production plan.

Decide who can prepare content, who can approve it, who owns channel access, and who handles failures. The demo allows one visitor to exercise all actions; it does not prove separation of duties between real people.

An approved post that changes is a new decision. A channel that disconnects is a broken prerequisite. Neither should resume publishing merely because it was valid earlier.

Run these scenarios with a sample post.

1. Persistence: Save a draft or a workspace preference, reload, and confirm the change remains during your valid session.
2. Approval invalidation: Edit approved or scheduled content. Confirm that it becomes a draft and no longer has a schedule.
3. Channel disconnection: Disconnect a sample channel with planned work. Confirm the content remains but its affected unpublished work is returned to draft. Reconnect and confirm old schedules do not restart.
4. Conflicting tabs: Open the same workspace in two tabs, make a change in one, then attempt a save from the stale view. Confirm that the older state cannot silently replace the newer state.
5. Simulation boundary: Simulate a publish. Confirm it is marked as a demo action and is not represented as real social delivery or new engagement.
6. Data lifecycle: Export your workspace, sign out, and sign in again. The new session should start from sample content rather than retain the previous workspace.

Write a decision record.

For each scenario, record the action, the result you saw, and any open question. Then add a separate requirements list for capabilities the demo does not implement: real identity, role separation, social OAuth, provider approval, live delivery, retention commitments, or support terms.

Do not read a simulated connection, a price estimate, or a reference architecture diagram as proof of a production service. Ask for specific evidence before making that decision.