Describe the change in business terms
State which administrative step changes, why it is needed and who requested it. Identify the affected workflow and its current version or configuration reference. For example, a routing change may send incomplete client-file tasks to a staffed review queue instead of one person. Describe the intended difference plainly enough for the practice owner to assess it. Avoid a change entry that says improved automation without explaining what a member of staff will see or do differently.
Identify affected work and boundaries
List the task types, staff roles and records the change touches. Distinguish new tasks from work already waiting in a queue. Confirm whether an existing approval or access rule is affected and who must review that impact. Do not treat an administrative change as permission to post ledger entries, make payments or lodge material. If the proposed behaviour extends beyond the agreed scope, record it as a separate decision for the practice before changing the workflow.
Link approval to the proposed behaviour
Name the person authorised to approve the workflow change and the evidence they reviewed. Record the decision against the proposed version, including any conditions or unresolved questions. A general request to reduce administration should not be treated as approval for every later configuration choice. If the implementation differs materially from what was reviewed, return the changed scope for the appropriate decision. Keep the log readable without placing passwords, client documents or unnecessary personal information in it.
Define checks before applying the change
Prepare fictional task examples that should behave differently and examples that should remain unchanged. Include an incomplete record, an unavailable destination and a repeated task where relevant. Agree the expected assignment and visible state before running the checks. Ask the technical owner how the prior configuration can be restored and what happens to work created during the trial. Restoration planning should account for pending tasks, rather than assume switching a setting back reconciles everything.
Rehearse a fictional routing revision
In a fictional practice, incomplete document packs are being assigned to a staff member who has changed roles. The approved revision routes new packs to a staffed intake queue. Internal tests confirm the new owner, preserve an existing professional-review assignment and show where an incomplete task waits. The team then checks how older queued work will transfer. The change log records those results and the practice decision instead of claiming success from a configuration screen alone.
Record the outcome and staff instructions
After the authorised change, check the destination task records and record the result, including any cases not yet verified. Tell affected staff what changed, when it applies and where to report an unexpected assignment. Keep the previous entry and related evidence available through the approved workspace. Reopen a change when its expected behaviour fails instead of silently editing away the earlier result. The log should help the next person understand which process is in use and why.