One invitation, the right access, and a clean exit

A developer joins on Monday. By Wednesday they can work, and getting there took somebody most of a day: an invitation to the GitHub organisation, then the two repositories that matter, then the Slack channels, then a seat somewhere so they can see the servers. None of it is hard. All of it is manual, and every step is a small decision made under time pressure by someone who wants to get back to their own work.

It is always faster to grant a little more than to work out the exact minimum, so the new person gets the whole organisation instead of two repositories, and nobody ever comes back to narrow it.

Six months later they leave, and the checklist that was never written down has to be run backwards from memory.

What happens in between

Between those two days, access drifts.

Somebody was added to a repository for one afternoon of debugging. A contractor got a Slack channel for a launch that finished in March. A person changed teams inside the agency and kept everything from the old one, because removing things is a task with no deadline attached.

None of this is visible anywhere. Each provider knows its own half of the story, and no provider knows the thing you actually care about, which is which client's work each person can reach. You can audit it, and auditing it means five admin panels, a spreadsheet and an hour you will not spend twice.

Organise access around the project

The fix is to stop thinking in providers and start thinking in projects, because the project is the unit the work actually has.

A person is added to the projects they work on. From that, the access they need is derivable rather than remembered: this project's repositories, this project's channels, this project's servers. Adding someone to a project provisions exactly that. Removing them from it takes exactly that back. Someone who works on two of your forty clients ends up with access to two of your forty clients, without anyone having to be careful.

Offboarding stops being a memory exercise, because it is the same operation with the sign flipped.

What Unolia does with this

Unolia manages access through the providers where the model fits: GitHub and GitLab for repositories, Slack for channels, Cloudflare for account members, and Laravel Forge for team members and the servers shared with them. That is the current list, and it is deliberately a list rather than a promise. Providers not on it are unaffected, and the rest of your stack keeps being managed the way it is today.

For the ones it covers, you choose how far to go per connection. It can stay out of the way entirely, or read what exists so you can see the picture without it changing anything, or actually apply what the project says. Reading first is the honest default, because the first thing most teams find is a surplus rather than a gap.

Unolia compares what your projects say a person should reach against what each provider reports they can reach, and shows you the difference: the accounts that exist remotely and match nobody, the access that outlived the work it was granted for, the person who should have something and does not. You review that list and decide. Nothing is revoked behind your back.

Why it is worth the setup

An afternoon per hire is annoying, not expensive. The case for this sits at the other end.

When someone leaves an agency, the gap between their last day and the day their last access actually disappears is usually weeks, sometimes forever, and nobody can state the number with any confidence. That gap is the risk, and it is entirely made of things nobody wrote down.

When a client asks who at your agency can reach their site, that should be a question with an answer rather than the start of an audit.