Release a deliberate, tested service version through Prototype, QA and Production. Treat content, settings, conditions, actions and connected systems as one release.

Use the right environment for the job

Release flow

flowchart LR
    A["Build a named version"] --> B["Check journeys in User view"]
    B --> C["Deploy the selected version to QA"]
    C --> D["Test QA integrations and failure paths"]
    D --> E["Approve the release evidence"]
    E --> F["Deploy the approved version to Production"]
    F --> G["Monitor and maintain"]

Test the participant journey first

Select User view from the Builder to see the service as a participant does. Start a fresh journey and follow the normal route. Then test every route that conditions, review pages, task lists, redirects or actions can create. A screen that looks correct in the Builder may behave differently once validation, navigation history and dynamic content are involved.

• Enter realistic valid answers and confirm the end-to-end route.
• Try missing, invalid, long and pasted answers to check validation and error messages.
• Change an earlier answer after reaching review, then check which pages and answers are still relevant.
• Test every condition true and false, including task-list states where relevant.
• Check the confirmation, exit and failure messages tell people what happens next.

Deploy an explicit version to QA

Open Environments and select QA environment. The deployment screen shows the service’s QA status and a version selector. Select the version you intend to test, then choose Deploy selected version to QA. Do not assume the current Builder state is automatically the QA version.

In QA, test real connections against their QA configuration. This includes data feeds, storage, messages, APIs, authentication and any action that changes or retrieves data. Use representative, non-sensitive test data. Confirm both the technical result and the participant’s resulting journey.

Important: A successful page-by-page test is not enough for a connected service. Test failure handling, timeouts, missing data, duplicate submissions and retries in QA before the service is released.

Prepare a Production release

Open Production environment and select the approved version. The screen clearly distinguishes links to the live service and live management dashboards. Check the selected version, deployment history and live configuration before choosing Deploy selected version to Production.

Before deploying, confirm that production-specific configuration is ready: domains, access rules, secrets, connected systems, file storage, notification settings, analytics and retention arrangements. QA configuration is not a substitute for production configuration, even when the service pages are identical.

Use change management to understand history

The Change management area records each version with the time, change description, deployment history and user who made the change. Use clear change descriptions so that another person can understand the purpose and scope of a release without comparing every setting.

You can restore an earlier version from the history. Restoring creates a new history entry; it does not erase the current version. Treat a restoration as a new change: test the restored version and deploy it deliberately to the environment where it is needed.

Maintain the service after release

• Monitor service analytics and action-failure alerts for unexpected behaviour.
• Review user feedback, abandonment, validation errors and support requests for opportunities to improve the journey.
• Keep page content, conditions, actions, connections and help information aligned when a business process changes.
• Review access, secrets, integrations and data sources regularly, especially when ownership changes.
• Use QA and an explicit version for every material change, even when the change looks small in the Builder.

Release checklist

1. Confirm the version and record what has changed.
2. Complete User view tests for all meaningful participant routes.
3. Deploy the selected version to QA and complete end-to-end testing.
4. Review QA evidence, connected-system results and failure paths.
5. Confirm the equivalent Production configuration and approvals.
6. Deploy the approved version to Production and monitor its first live use.

Related guides

• Add actions and workflows
• Connect data, files and SharePoint
• Service identity, lifecycle and administration
• Service change management
• Service environments and deployments
• Library integrations and data