A sales rep moves from the new-accounts team to renewals on a Monday. Her mail starts forwarding to the new team that afternoon. Her manager updates her role in the CRM the next day. Nobody remembers to tell the agent that has been drafting her call notes for three months, because nobody ever told it anything about her role in the first place — it has simply been reading whatever she could read, and until Monday that included a pricing sheet meant only for new accounts.
Two weeks later it is still reading that sheet. Nobody decided she should keep seeing it after the move, and nobody decided the agent should either. It is just what was left over when a person changed roles faster than the systems around her caught up, and a draft that writes itself does not pause to ask whether what it is allowed to read is still correct.
Why we build it this way
The instinct is to make each system better at this on its own — a stricter review inside the CRM, an access audit on the drive once a quarter. Both would help a little, and neither touches the real problem. Who may see what gets decided five times over, once inside each tool, on whatever schedule its own administrator works to. A role change has to land correctly in all five before it is correct in any of them.
Add an agent and the gap gets more expensive, not just more repetitive. An agent drafting on somebody's behalf answers the old, half-updated question at the speed of software, not the speed of a person noticing. If the answer was already wrong in one system, the agent now acts on that mistake continuously.
An agent reading on your behalf does not ask a new question about what it may see. It answers the old, half-updated one — only faster than a person ever would have.
So we do not sell five access panels and hope they agree with each other. We define who may see what in one place — a person, a role, a team — and every module, and anything acting for a person inside that module, checks the same list before it answers anything. A role change made once takes effect everywhere at once, because there was only ever the one place it was made.
How it works, roughly
The identity model holds one thing per person: what they may read, and under what role. Everything the core serves checks against that same list:
- A question asked directly, by that person, in Workspace, Happen or Converse
- A question an agent asks on their behalf, within whatever scope it was given to act for them
- A request from a different person entirely, which the same list allows or declines on its own terms
When a role changes, it is changed in the one place, and every module narrows or widens on the very next question asked — not whenever each admin gets around to their corner of it. If someone's scope genuinely does not cover what their job now needs, they ask whoever owns that boundary for an exception. The grant or the refusal is kept with the record, so the next audit shows who decided, not just what happened afterward.
A year in, what a person — or an agent speaking for them — can see matches what their job actually is today, not what it used to be two roles ago. Nobody is relying on memory to keep five systems in step, because there has only ever been the one list to change.
See how VarahiOne defines access once →