Versions, publishing and the national portal
A service reaches citizens only through an approved version. This lesson covers testing a draft, submitting it, approval, what happens to applications in progress, how the national portal receives the service, and what else a service needs before it is done.
Drafts and versions
With versioned publishing switched on (the normal setting), Save writes to the service's one open draft version. The live service is not touched. The Versions and approval tab shows every version and its state:
| State | Meaning |
|---|---|
| Draft | The one open version you edit |
| Submitted | Waiting for approval; editing stops until it is decided or withdrawn |
| Scheduled | Approved to go live at a set time |
| Published | The live version. Never edited |
| Superseded | Was live, then replaced |
| Rejected | The approver said no, with a reason |
A brand-new service starts switched off with a draft version 1: nothing reaches citizens until someone else approves it. If a server has versioned publishing switched off, the tab says so and saved changes go live at once.
Test submission
Before submitting, try the draft as an applicant would. The Test submission panel shows a banner "Test only - nothing is saved or sent" and lets you:
- switch between phone, tablet and desktop width;
- fill the form and tick the documents as uploaded;
- see the server's answer: refused or accepted, errors under each field, missing documents, the fee and its lines, the
case number it would get, the due date and the messages it would send (with SMS length and segments);
- walk the case through its steps: complete a step, approve, return to the applicant, reject, or simulate payment.
Clear the run when you finish. Use synthetic answers only.
Submitting for approval
Click Submit for approval and write a change summary: what changed and why, in a sentence or two. The platform then runs its checks:
- Form and process checks. Errors block the submission (for example a step without a role, or a route without a
default path). Warnings are kept for the approver.
- Impact. The impact view lists applications in progress by status, and fields added, removed or retyped.
Breaking changes are refused, with advice to deprecate a field instead of removing it. Stricter checks need your confirmation. For each field that becomes required, you choose: apply to new applications only, flag existing ones, or backfill a value.
Approval
Another administrator approves or rejects the version. The approver must not have made, edited or submitted it; the server enforces this and answers MAKER_CANNOT_APPROVE otherwise. A rejection needs a reason, which the maker sees. The approver may set Publish at to schedule the version, or leave it empty to publish now. Every step is recorded in the audit trail and the change history, naming both people.
To undo a release, publish a copy of an earlier version as a new version (rollback). History is never rewritten.
Applications in progress
An application stays on the version of the service it was made under. If you add a question, applications already sent are not asked it; new applications are. This is why the impact view asks what to do about newly required fields.
Publishing to the national portal
Each MDA may run its own back office (a node); there is one national portal (the hub). You always design and publish a service on your own MDA's back office.
- When a version is published on a node, the node builds a manifest of the public service data (passport, form, fees,
documents, steps, translations), signs it and pushes it to the hub right after the change is committed.
- The hub checks the signature and that the sender owns the service, then shows the new version on the portal,
usually within seconds.
- If a push is missed, the hub pulls changes from every node every 15 minutes.
Things that stay on the node: drafts, output templates, assignment rules, revenue settings, and every application's answers, notes and documents.
The hub shows a node's service read-only, "Managed by" that node, and refuses any edit with 409 SERVICE_MANAGED_BY_NODE. System administration โ National catalogue sync shows the delivery status on both sides.
When is a service done?
An approved version is not the end. A service is done when:
- its configuration is complete (the earlier lessons);
- it is approved and published;
- its end-to-end test passes: find the service, sign in, apply, pay, every officer step, the decision, and the
issued document with its seal and QR verification. It must pass on both seed profiles, and in the federated topology when the service can live on a node;
- its documentation (screenshots at each step, a Markdown description and a Word document from the standard
template) has been generated by that test run and published to the central documentation share;
- its row in the service status list shows all five checks green: Form, Workflow, Outputs, E2E and Docs.
The E2E testing and documentation course teaches steps 3 to 5. The hub's service catalogue at /services shows each service's checks.
Checklist
- Passport complete and in plain English.
- Form uses library fields; nothing asked that the decision does not need.
- Every person's step has a role; every route has a default path; the simulation was run for each branch.
- Fees tested for each case type; finance approval where officers set fees.
- Required documents listed, with guidance, scoped to case types.
- Templates uploaded; every placeholder filled; Certificate particulars defined.
- Needed modules switched on for the ministry.
- Test submission run; version submitted with a clear change summary and approved by someone else.
- E2E test, documentation and status row done.
Check your understanding
- What does Save change while versioned publishing is on?
- What can you try in the Test submission panel, and what is saved?
- Who may approve a version, and who may not?
- What happens to an application sent before a new version adds a question?
- How does a service published on a node reach the national portal, and what if a push is missed?
- What answer does the hub give if someone tries to edit a node's service there?
- Which five checks must be green in the service status list?
Sign in to record your progress.
Previous: Output documents and capabilities Go to the assessment