// EXAMPLE · ROLE CHANGES
Hypothetical: A team changes roles. Its approvals and access need to follow.
A team leader moves into a new role. The organisation chart changes immediately. Purchasing approvals, shared folders and requests awaiting a decision still point to the old arrangement.
Hypothetical engagement example. It does not describe a completed client project or achieved results.
One appointment, several unfinished changes
In this example, a growing business appoints a new operations manager. The former manager will remain with the company in a different role. A colleague will temporarily cover part of the vacancy left by the incoming manager.
HR has recorded the appointments. However, the expense application still routes requests to the former manager. A shared mailbox contains unanswered supplier queries. Both managers can access folders relating to their old and new teams. Nobody has agreed who decides an urgent exception during the handover.
Establish what changes on the effective date
The engagement would start with the appointments and the work they affect. It would distinguish the authority to make a decision from the technical permission to operate an application. Changing one does not automatically change the other.
| Area | Decision to settle |
|---|---|
| Approval authority | Which decisions move to the new role, with what limits and from what date? |
| Open requests | Who takes responsibility for items already awaiting a decision? |
| Temporary cover | What can the covering colleague do, and when does that delegation end? |
| Application access | Which permissions are required for the new duties, and which should be removed? |
| Business records | Who takes over shared mailboxes, documents and recurring reviews? |
| Exceptions | Who decides if a request falls outside the new arrangement? |
Want to build the record behind this table? Our briefing on keeping an approval matrix current when roles change shows how.
Make the handover a controlled change
An agreed change record would connect the HR update, the approval changes and the system tasks. It would identify the authorising manager, the people making each change and the evidence needed to confirm completion.
The former manager’s access would be reviewed against the new duties rather than retained simply because the person is still employed. Historical decisions would remain attributable to the person who made them. Reassigning an open request would not rewrite its history.
Temporary access and delegated approval would have their own end dates and review arrangements. Any exception needed during the transition would be recorded rather than silently becoming permanent.
Check the arrangement in use
The review would trace a request submitted before the change and another submitted afterwards. It would also test an absence, a request above the approval limit and access to a folder belonging to the former team.
The proposed outputs would be a confirmed authority register, a completed change checklist, revised routing where supported by the relevant systems, and evidence of the access changes. Any unfinished item would have an owner and an agreed follow-up date.
Capabilities involved
Workforce would coordinate the employment and role records. Governance would establish authority and delegation. Technology & Automation and Cybersecurity would address routing and access. Corporate Legal Consultancy could review relevant appointment or delegation documents where required by the engagement.
Planning a promotion, handover or restructure?
Tell us which roles are changing and which decisions they hold today. In a first discussion we can outline a handover that covers the work, not only the appointment.
Related capabilities:Workforce Governance
Other examples
Hypothetical: Replacing a shared spreadsheet with a working application
Requests live in a shared spreadsheet that nobody fully trusts. See how scope, approvals, permissions, data migration, acceptance and support could be agreed before development begins.
Read the spreadsheet exampleHypothetical: A new application is live. The team needs to make it part of the work.
The new application is live, yet staff still keep their own trackers. See how role-based practice, task guides, configuration fixes and a support route could make it part of the daily work.
Read the software adoption example