# Recommended flow for testing an experience in dev before production?

Asked by Callum Doyle on 2025-02-05. Tags: workflow, environments, deployment.

I have been burned enough times by "just edit it in prod" workflows that I want a
proper promotion pipeline before we let anyone publish experiences.

What I want is the CMS-style flow: build the experience against a dev
environment, QA it there against real slots, then ship the identical thing to
production. What is the intended way to do this with Croct? I can see workspaces
have environments but I have not found a "promote" button, so I want to know what
the actual supported workflow looks like before I invent my own

## 2 answers

### Answer from Croct Bot (2025-02-05)

The intended workflow rests on three mechanisms:

1. Environment separation. Workspaces hold multiple environments (dev and
   prod), each with its own application ID, and `croct.json5` maps applications
   per environment. Your dev deployment points at the dev application, so its
   traffic and content never mix with production.

2. [Preview links](https://docs.croct.com/explanation/content/preview) for the QA step. Before publishing in production, generate a
   preview link from the experience editor and review against the real slots.
   The preview widget shows the experience, variant, audience, and locale under
   review. One requirement to be aware of: the slot versions in the preview
   must match what the integrated code expects, so keep the environments on the
   same component versions during QA.

3. Per-environment publication. There is no single promote button; publication
   happens in each environment. The safety rails in production are the Draft
   status, which holds the experience [unpublished](https://docs.croct.com/explanation/experience/unpublished-changes) until you deliberately
   release it, and pausing, which immediately reverts visitors to default slot
   content if something looks wrong after release.

So the flow is: build and validate in dev, recreate or template the setup for
production, hold it in Draft, preview against production slots, then publish.

### Answer from natec (2025-02-06)

From someone running this in practice: the piece that made our pipeline feel
safe was treating pause as the rollback. Publishing to prod stopped being scary
once the team internalized that pausing an experience instantly serves default
content, no deploy, no cache purge, just back to baseline.

Also worth committing your `croct.json5` with both environment mappings from
day one. We had a week where a staging deploy pointed at the prod application
ID because the mapping lived in someone's local config, and the dev-traffic
pollution in our audience data was annoying to reason about afterwards. In the
repo, reviewed like any other config, problem gone.