One author saving and publishing in Studio is straightforward. Ten authors across draft, review, approval, and scheduled publish, across multiple environments, is where the workflow rules matter. This page is the integration model between Studio and Contentstack's workflow primitives.

A Studio composition is stored as a Contentstack entry on the project's compositions content type. That means every Contentstack workflow feature applies to compositions automatically:

• Workflow stages (Draft to In Review to Approved to Published) work on compositions just like on any other entry
• Roles + permissions scope who can edit, who can review, who can publish
• Scheduled publishing works: author edits a composition, schedules it for next Tuesday, Studio renders the new layout starting Tuesday
• Environment promotion: publish to preview first, validate, then publish to production
• Variant aliases apply to compositions too, see variant aliases deep dive

Studio doesn't have its own workflow layer. It piggybacks on Contentstack's. This is by design: editors who already know Contentstack workflow keep working the way they always have; nothing new to learn for layout changes.

In Studio's canvas top-right:

• Save: writes the current state to the composition entry as a Draft.
• Deploy: publishes the entry to all environments configured on the project.

For teams with workflow stages, don't use Deploy directly. Instead:

1. Author makes changes, then clicks Save (entry stays in Draft / In Review).
2. Reviewer opens the composition entry in Contentstack, then reviews via the standard workflow UI.
3. Reviewer transitions the entry through stages (Draft to In Review to Approved) using Contentstack's workflow controls.
4. Final publish happens via Contentstack's publish UI, scoped to specific environments.

This gives you the full Contentstack workflow story applied to layout changes.

When you ship to multiple environments (staging, preview, production), use ONE Contentstack stack with multiple environments and one Studio project per target environment:

Studio project	Environment	Canvas URL
studio-staging	staging	https://staging.yoursite.com
studio-preview	preview	https://preview.yoursite.com
studio-production	production	https://yoursite.com

Same stack, same compositions, different environments. Publishing a composition to staging makes it available on the staging Studio project's render; publishing to production makes it live. This mirrors the standard Contentstack environment-promotion pattern.

Lock down who can edit compositions vs who can author content. Two roles to set up:

• Content Editor: can edit entries but NOT compositions (the layout itself is locked).
• Composition Editor: can edit both entries AND compositions.

This prevents "marketing changed the layout by accident": only people with explicit composition rights touch structure.

Author a Spring 2026 Landing composition in February. Schedule it to publish March 1st. Studio's canvas for the active composition shows the OLD layout until March 1st, then switches automatically.

This is just Contentstack scheduled publishing applied to the composition entry: no Studio-specific knob.

Pattern	Why it bites
Bypassing workflow with direct "Deploy" clicks	The workflow exists for a reason: direct publish skips review, breaks audit trails
One Studio project across all environments	Authoring against staging accidentally publishes to production; environment promotion can't be enforced
Letting every editor edit compositions	The whole point of separating CT content editors from composition editors is preserving structural integrity
Treating compositions as "code": putting them in version control via export/import	Compositions live in Contentstack with the full content workflow story; pulling them into git defeats that
Using Studio's Save button as a "publish"	Save = draft. Deploy = publish to all env. Workflow stages = real review. Know which you're using.

• Composition-level merge conflicts when two authors edit the same composition simultaneously: today, last-write-wins. Real-time collaborative editing is on the roadmap.
• Visual diff between composition versions: Contentstack shows JSON diff for compositions, but a visual side-by-side ("here's the layout before, here's after") isn't built in yet. Use entry-version comparison + screenshot-during-review as a workaround.
• Workflow comments scoped to a section of the composition: today comments are at the entry level, not "comment on this section." Approval workflows that need per-section feedback rely on attached docs or chat.

• Save vs Deploy: the canonical Save vs Deploy semantics
• Variant aliases: variants apply to compositions, including in workflow
• Production deployment edges: environment promotion + CDN invalidation