Security & trust

Change Management

Test changes, keep releases traceable and separate responsibilities.

Controlled changes

Service version history and explicit QA and Production deployments help teams control publication. Your team can review a service change, test it with the relevant integrations and choose when the approved version becomes available to live users.

Platform releases follow a separate build and promotion process that verifies the tested version before Production promotion. Together, service and platform controls support traceable changes to the experience people use.

  • Review service changes before choosing a release version.
  • Test journeys, permissions and integrations in QA.
  • Verify the published service after Production deployment.
Read the deployment guide

Environment configuration

Manage service configuration and integration secrets by environment. QA and Production can use different credentials, destinations and identity-provider settings, keeping test activity apart from live operations.

Configuration changes can affect the service even when its visible questions stay the same. Check the systems, notifications and files involved, then test and apply the configuration to the intended environment.

  • Keep test and Production connections and credentials separate.
  • Review library-wide settings that affect multiple services.
  • Coordinate changes with identity and integration owners.
Read environment-specific properties and secrets

Separate responsibilities

Library roles can separate service design, QA deployment, Production deployment and live-data access. Assign these responsibilities around your organisation’s approval and operating processes, rather than giving every team member the same access.

Library security settings provide additional controls. Sandbox mode prevents Production deployments across the library, and export or analytics-view controls can limit operational data access independently of design permissions.

  • Give designers the access needed to build and test.
  • Limit Production publication to the responsible release roles.
  • Use the library-wide deployment guard for training or experimental work.
Read library security settings

Prepare the complete service for release

A ready-to-release service includes more than the visible journey. Authentication, privacy content, permissions, storage, notifications and downstream actions should all be checked against the intended Production arrangement.

Use QA to test successful completion, invalid inputs, restricted access and integration failures. Confirm the release owner and operational support route so the team knows how to respond if a live issue is reported.

  • Verify the complete journey with representative test information.
  • Check Production destinations and credentials before publishing.
  • Record the release version and confirm the live behaviour after deployment.
Explore the service workflow
Build with confidence

Secure services start with a conversation.

Talk to our team about your organisation’s security requirements, hosting choices and the services you want to deliver.