Service domains, analytics and deployment
Domain, URL-context and release settings affect how a service is reached, how it behaves when opened from a link, and how safely it moves through QA to production. Treat them as operational controls. A setting that looks small can change public routing, privacy or a person’s answers.
Configure a custom domain carefully
The Custom domain is the production address used for canonical links and browser-security configuration. Enter a fully qualified domain that the organisation controls and follow the Builder’s domain-verification and provisioning process. Do not edit the internal provisioning record: it is maintained by the platform.
You can choose whether the domain uniquely identifies this service and whether traffic from the default cloud address is allowed or redirected. Before making the custom domain the direct entry point, confirm that no other service already claims the same domain and that every intended route, link, sign-in flow and return URL works.
flowchart TD
A["Choose owned custom domain"] --> B["Check DNS and start provisioning"]
B --> C["Wait for active status"]
C --> D["Deploy a QA version and test entry routes"]
D --> E["Confirm redirects, sign-in and return URLs"]
E --> F["Release production version"]Removing or changing a domain can leave old links unusable. Plan redirects, support communications and rollback before the change, and check the status after the service is released.
Do not use URL context casually
URL form data support can allow query parameters to set journey context. Depending on the configuration, values can also pre-populate answers and may be applied when someone resumes a draft. This can be useful for tightly controlled links, but it is a security and privacy risk when values are untrusted.
If you enable it:
- Use an explicit whitelist of accepted parameter names.
- Never accept secrets, authorisation decisions or sensitive data from a URL.
- Decide whether a query value may pre-populate a field or should only be stored as context.
- Decide whether it may change a resumed journey.
- Test edited, missing, duplicated and malicious-looking parameters.
Do not assume that hiding a parameter from the page makes it safe. A person can change a URL before opening it.
Treat analytics as a data decision
The service can identify selected field IDs for analytics. This can help understand where a journey fails, but it can also send answer values beyond the service. Tag only the minimum data needed for an approved measurement purpose. Avoid names, contact details, free text, identifiers, sensitive answers and uploaded-file information unless there is a documented and appropriate basis to collect them.
Use aggregate journey measures where possible: completion, errors, drop-off, time on task and route selection often answer the service-improvement question without collecting detailed answers.
| Before enabling a field tag | Confirm |
|---|---|
| Purpose | The decision it will inform is specific and useful. |
| Data minimisation | A less detailed measure cannot answer the same question. |
| Transparency | Required privacy information explains the processing. |
| Destination | The team knows where the value is sent and who can access it. |
| Retention | The analytics data has an approved retention and deletion approach. |
Use read-only mode for the right purpose
Read-only mode prevents editing and submission. It can be useful for a controlled viewing period or a completed record, but it is not a substitute for removing access or retiring a service. Explain the person’s next step and test that linked actions, buttons and draft routes do not imply that editing remains possible.
Release through the normal lifecycle
The platform and frontend versions are set through deployment for compatibility. Do not hand-edit them to force a particular behaviour. Use the standard version history and deployment process so that the service, its pages and conditions remain compatible with the deployed environment.
- Save a meaningful version description.
- Test the version in User view and QA.
- Check the intended domain, links, access rules, integrations and analytics configuration.
- Deploy the approved version to production.
- Verify the public route and core journey after deployment.
- Record any issue and use the normal rollback or new-version process if needed.