Service identity, lifecycle and administration
These Service settings define how a service is identified, presented and managed over time. Most are set once, but a few—such as reference formats, retention, file folders and templates—need deliberate operational ownership. Change them through the normal version and deployment process, not as a quick fix in a live service.
Start with a stable service identity
The Service name is the human-readable name shown in the Builder, page titles and some messages. Choose wording that tells people what they can do, for example Apply for a parking permit, rather than an internal project code. If a different name is needed in the header or footer, use the separate service-name setting deliberately and check it in User view.
The Service ID is the stable, machine-readable identifier used in service URLs and integrations. It uses letters, numbers and hyphens. Keep it short, lower case and specific, such as parking-permit-application. Do not rename an established ID without assessing links, API calls, templates, actions and deployment records that may rely on it.
| Setting | Use it for | Key decision |
|---|---|---|
| Service name | The visible service title. | Is it meaningful to people and the service team? |
| Service ID | URLs and system references. | Will it remain stable for the life of the service? |
| Service name link maximum width | Controlling how a long header title behaves. | Does the header remain readable on a small screen? |
| Additional header link text | Service-specific header navigation. | Are each label and destination necessary and clear? |
| Share link text | Explaining a sharing action where sharing is enabled. | Does it tell people what access they are granting? |
Set a realistic draft-retention period
The User data retention period determines how long a saved draft remains available before it expires and the person must restart. Set it according to the time people need to gather information, the sensitivity of the data and the organisation’s retention rules. Explain the behaviour in the journey when someone could reasonably expect to return later.
Test both a returning draft and an expired draft. A retention decision is not complete until the person sees a clear, safe outcome in each case.
Design useful reference numbers
Use Submission reference format when the team and the person need a recognisable reference after submission. The format can combine fixed text with supported tokens for a zero-padded number, a random alphanumeric value and a user-group value. For example:
CASE-$nnnn-$aaaaThe reference should be short enough to quote over the phone or in correspondence, unique enough for the process, and free from unnecessary personal information. Test formatting across several submissions and confirm that the same reference appears consistently in the completion content, messages, exports and records that use it.
Keep files and generated documents organised
The File upload folder name provides a parent destination for uploaded files in the configured storage connection. Use a stable, purposeful path such as applications/permits. Avoid using names that reveal sensitive personal information or depend on a temporary team structure.
The Answers playback page title controls the title used for a downloadable answer document. Use a title that makes the file understandable once it is saved outside the service, for example Parking permit application – answers. If it includes dynamic content, test missing and unusual values as well as the standard case.
Decide whether a service is a template
A service can be marked as a reusable template rather than a deployable service. For a template, provide a clear Template description, category and thumbnail only when they help someone choose the right starting point. A good template is generic, safe to copy and contains no real submissions, credentials, live endpoints or organisation-specific content that would mislead a new owner.
flowchart TD
A["Create a reusable starting design"] --> B["Remove real data and environment-specific settings"]
B --> C["Write purpose and intended use"]
C --> D["Mark as a template"]
D --> E["Copy it to create a service"]
E --> F["Configure identity, integrations and deployment"]Do not expect a template to be deployable as-is. Treat the copied service as a new configuration and review its name, ID, authentication, styles, integrations, domains and content before use.
Domains and email settings are operational changes
Some identity settings affect public routing and correspondence. A custom domain can be configured to identify the service directly; confirm it does not conflict with another service and test every entry point and redirect. Service-level email subject and body templates can contain dynamic content. Keep them concise, accessible and free of secrets; test delivery with representative answers and a missing-value route.
Manage lifecycle changes safely
The Builder’s service settings include high-impact administrative operations. A service cannot be deleted while it remains deployed to QA or production, and deletion requires typed confirmation of the service ID. Treat deletion as irreversible unless the organisation has an established recovery arrangement.
Before you archive, duplicate, rename, transfer or delete a service:
- Check its deployment status and live links.
- Identify submissions, storage destinations, scheduled work and integrations that may still depend on it.
- Create or verify a replacement service where appropriate.
- Record the reason, owner and rollback approach in the change description.
- Test the replacement in QA before changing any live routing.