Skip to main content

Development trial · sample information only

Configure and test an approval workflow

For Organisation Administrators: licensed Collaborators with the relevant organisation-wide permissions.

What you will achieve

Prepare an organisation workflow, publish an intentional version and test it on a controlled record before using it as a default.

“Test” here means a role-based rehearsal using a fictional or explicitly approved test record. It is not a promise of a built-in simulation button.

Before you start

Agree the entity type, states, approvers, rejection path and completion rule. Use a development fixture for rehearsal where possible. Have separate authorised people available for the roles being tested.

Changing a default affects future work. Publishing a workflow version does not migrate all existing work to that version.

Prepare the workflow

  1. Open Settings > Organisation > Compliance > Workflows.
  2. Review the existing workflows and their entity types. If adapting a platform workflow, use its duplication action; platform definitions are not your editable organisation draft.
  3. Create an organisation workflow with a meaningful Name, Entity type and Description, or open your existing draft.
  4. In the designer, inspect each state. Set its label and code deliberately, identify the initial and terminal states, and review any required fields or timing settings.
  5. Inspect each transition. Give it an action name a reader will understand, such as “Submit for review”. Review its source and destination, conditions, approval settings and actions.
  6. Provide a correction or rejection route where the process needs one. Check that an author cannot accidentally bypass the intended approval condition.
  7. Save Draft. Reopen it and compare the saved graph with the agreed process.

Publish and rehearse

  1. Select Publish Version, add a useful changelog and confirm Publish.
  2. If publication is blocked, read the graph-validation errors and repair the draft. Do not remove a necessary approval just to pass validation.
  3. Confirm the published version and active state. In-flight instances keep the version they started with; new instances use the applicable published version.
  4. Start a controlled record with this workflow using the available assignment controls. Test submission, approval, rejection and resubmission with the intended roles.
  5. Test an incomplete record and a person without approval authority. Confirm that each is blocked for the expected reason.
  6. Only after review, set the entity type's default workflow and decide whether overrides are allowed. Re-read the saved default.

Check it worked

Keep the workflow version, test record, actors, outcomes and approval decision. Check a new record starts with the intended workflow. Separately inspect an older in-flight record to confirm its version remains understood.

If something goes wrong

Problem Next action
Workflow is unavailable as a default Check entity type, active state and that a published version exists
A transition is missing Check the current state, conditions and acting role
A new version behaves incorrectly Stop wider adoption and restore a reviewed earlier version as a new draft; publish only after retesting
Existing work looks unchanged Inspect its pinned version; publication is not a bulk migration

Human judgement matters

Clearing a default can leave new records without a workflow where no platform default exists. Deleting a workflow is not a recall of in-flight work. Prefer a controlled correction with an audit trail.

What next?

For the wider context, see Configure features, review standards and workflows.

Tell authors and approvers what changed, which records it affects and where to report a blocked transition.

Get help

Contact your organisation's support route with this guide reference, the affected page and a sanitised error. Do not include passwords, keys or session details.

Was this article helpful?