Joiner, mover, leaver checklist
Joiners, movers and leavers all turn on the same question: what should this role have, and what should it stop having. This agent builds the checklist from your access matrix and past setups, drafts the tasks, and names an owner for each. IT approves before any task is raised, and no access changes without a person.
Step by step
Take the role and change
The agent reads whether this is a joiner, a mover or a leaver, and which role and team is involved.
Read your access matrix
Tools, groups, licences and equipment for the role are drawn from your own matrix and the setups used for comparable roles.
Work out what changes
For a mover or a leaver it lists what should be added and what should be removed, rather than restating the whole role.
Name an owner per item
Each item is matched to the team or person who actions it, and anything with no owner is flagged instead of assumed.
Draft the tasks with dates
Tasks are drafted for your queue in the format the desk expects, with dates tied to the start or leave date.
An IT owner approves first
An IT owner reviews the checklist and approves. Only then are tasks raised, and access is granted or removed by a person.
Exactly what this agent can see, touch and change
The same five controls sit behind every ollo agent. These are this one's settings — visible before you build it, not buried in an admin screen afterwards.
Context
What reaches the modelIT teams handling steady joiner, mover and leaver volume across several teams and sites, where the right access for a role lives in people's heads.
Escalation
When it asks a personAn IT owner approves the checklist before any access task is raised
Applications & Rights
Which tools it uses, and what it may do in each
ConfluenceRead only
NotionRead only
SharePointRead only
SlackRead only
JiraWrites newCreates new records or documents. Never edits, moves or deletes anything that was already there.Verification
How you know it’s rightEvery claim links to the document it came from. A statement the agent cannot cite does not make it into the output — which is what makes the result reviewable in minutes rather than re-read end to end.
Who it’s for
IT teams handling steady joiner, mover and leaver volume across several teams and sites, where the right access for a role lives in people's heads.
What you’ll need
- A role and access matrix connected
- A ticket queue to write tasks to
- Agreed leaver timing rules
- An IT owner to approve each checklist
What you get
- An add and remove access list
- An equipment and setup checklist
- Drafted tasks with named owners
What it doesn’t do
It drafts the checklist and the tasks. It does not create accounts, grant or revoke access, or touch your identity provider, and it cannot confirm that a revocation actually happened.
We build the first one with you
Not a template you configure alone. We sit with your team, build it on real data, and hand over the controls.
Scope
One session with the people who actually do the work. We agree what the agent reads, what it may write, and who approves.
Co-build
Built on your own data, not a sandbox. You watch it being made, so you know why it behaves the way it does.
Handover
You own the controls. Change the context, tighten the rights, move the approval gate — without coming back to us.
Parts of the work currently spread across the categories below. It does not replace any of those products outright.
Frequently asked
Why does it not revoke access itself?
Because access changes are exactly where an unattended agent does the most damage. It prepares the work, names the owner and shows what should change. The change is made by someone with the rights and the accountability.
How does it know what a role should have?
From your own access matrix, and from the setups used for comparable roles where the matrix is thin. Where it is inferring rather than reading a rule, it says so, so the reviewer looks harder at that line.
Can it handle contractors and mid-year role changes?
Yes, where your rules cover them. A mover is handled as the difference between two roles rather than a fresh setup, which is usually where leftover access comes from.
What about leavers who need access for a handover?
Your timing rules decide that, and the checklist shows the date each item is due to be removed. Extending an item is a person's decision and stays visible on the checklist rather than being agreed in a side conversation.