We help IT replace manual provisioning of access request tickets and employee onboarding checklists for Google Workspace groups and Okta apps with automated, least privilege, audit-ready policy-based access control.
2 Minute Walkthrough of Provisionr CLI
How we fit
How many access request tickets have you submitted to IT or Security? Why don't they know what you should have access to?
Provisionr is back office software for Identity Governance, IT, and Security teams using Google Workspace or Okta with 100 to 20,000 users. We focus on group membership policies that grant access across most resources in Google and all of your SSO applications in Okta. Our directory adds the granular user profile attributes and metadata that your HRIS and IdP lack. Our policy engine reduces access request tickets and automates provisioning and deprovisioning for onboarding and job role changes, ensuring least privilege access to applications, data, and systems for employees, contractors, and third-party collaborators.
We are a team of auditors, IT/TechOps sysadmins, Identity Governance, and Security engineers that built the platform we wish existed.
Microsoft Entra already serves Active Directory environments well, with mature identity governance built in for the organizations that live in that world. Identity governance did not stop at Active Directory, though. The 9+ million Google Workspace organizations and 18,000+ Okta customers running modern identity stacks were largely left to fend for themselves.
We are not for everyone, and we would rather say so up front. If you need a sprawling enterprise governance suite spanning hundreds of integrations and you have the Identity Governance headcount and the $50k to $300k a year budget to run it, the big platforms exist for good reason. We are for the organizations in between, using Google Workspace or Okta, who outgrew the scripts and most of their access is federated through Google or Okta.
Google Workspace organizations worldwide
9M+
Okta customers needing policy automation
18K+
For HR Operations
Onboarding starts in your systems, so access should too. Provisionr turns the attributes HR already maintains (job role, department, location) into the entitlements a new hire receives, automatically and on time. The handoff that used to mean a checklist and a string of tickets becomes a policy that runs on its own, which means fewer mornings spent chasing IT for access that should already have been there.
For Identity Engineers
You have written the scripts, and you know exactly where they break. Provisionr replaces fragile string matching and one-off automation with a real policy engine and proper database relationships, so access reflects organizational structure instead of guessing at it from text. Declarative rules you can reason about, version, and trust, in place of a maintenance burden that grows with every reorg.
For IT Helpdesk
The access request queue is where the helpdesk team spends more time than they want to admit. Provisionr automates baseline provisioning so the predictable requests, the ones that follow directly from role and department, stop reaching the desk at all. What is left is the judgment calls for genuine exceptions, not the rubber-stamping of requests a policy should have handled.
For Corporate Security
Least privilege is easy to state and hard to prove. Provisionr enforces it by granting only the access a person's attributes justify and removing it the moment those attributes change. Every grant, change, and revocation lands in a complete audit trail, so when a review or an auditor asks who can do what and why, the answer is already written down rather than reconstructed by hand.
The Problem We Solve
Manual provisioning does not fail loudly. It fails slowly, an hour at a time, until a real share of the IT team's week is spent moving people in and out of groups by hand. Checklists drift out of date. String-matching rules break the moment a team gets renamed. The work scales with headcount, so it only ever gets heavier.
Eliminate Endless Access Request Tickets
IT teams lose hours every single week to routine access requests, and most don't require judgment. A new hire needs their role's standard toolset. A mover needs the access their new team already has. The right answer is knowable in advance from attributes the organization already tracks, yet each request still gets opened, triaged, and clicked through by hand. The knowledge is already there. Only the automation is missing.
Delayed Onboarding and Day 1 Productivity
A new employee's first week sets the tone for everything that follows, and it is usually spent waiting for IT. Days or weeks pass before they have access, while tickets crawl through a queue and the new hire sits idle on the projects they were hired for. The cost lands on everyone at once: lost productivity for the company, a poor start for the employee, and a manager fielding the same status question every morning.
Replace Brittle Provisioning Scripts
Homegrown automation almost always works on the day it ships. Then a team gets renamed, the org structure shifts, an acquisition lands, or an edge case nobody anticipated walks in, and the script quietly produces the wrong result. Because string matching has no concept of intent, every organizational change becomes a maintenance task, and maintaining the automation slowly turns into a job of its own.
The patterns we hear on every customer call
Identity data is scattered across four systems
Okta knows who has an account. Workday knows who still works here. The ticketing system knows who was granted what, and when, and by whom. None of these systems talk to each other. So every access decision starts the same way: open four tabs, reconcile four versions of the truth, and hope the freshest one is the one you happened to check.
The access request queue is the process
Thirty-plus tickets land in the queue every Monday morning, and most of them are entirely predictable. New hires need their role's default access. Movers need a different set of defaults. The IT team already knows what each person should have before the ticket is even filed. The queue exists only to convert that knowledge into clicks, one console at a time.
The Okta group rules nobody understands
Different administrators wrote different rules over five years, and not one of them left a comment explaining why. One rule is almost certainly wrong, but nobody can say which without breaking something to find out. Quarterly review season is painful for exactly this reason: the rules have no readable history, so every review starts from archaeology instead of intent.
External partner access governed by Slack DMs
A new partner relationship starts, and someone DMs IT to ask for access. IT adds the domain and moves on. Nobody records the start date, the contract reference, the scope, or when it should end. Six months later the partnership is over, the access is not, and the only record it ever existed is a Slack thread nobody can find.
New hires lose their week to IT tickets
Monday at eight in the morning, the new hire arrives, eager and ready to contribute. By eleven, the fourth access ticket is filed. By Friday, they still cannot reach the staging environment they needed for the project that was due Monday. The first week, the one that sets the tone for everything after, gets spent waiting on a queue.
Post-termination access that never gets revoked
The team ran the offboarding checklist line by line and signed off. Then the annual audit goes looking and finds what the checklist missed: a GitLab project the employee still belongs to, a Salesforce read role nobody revoked, an active AWS console login, and an SSH key sitting on a jump box everyone forgot existed. The checklist was complete. The access was not.
Access reviews are a burden on the reviewers
Eight thousand rows. Forty managers. Two weeks to certify all of it. Faced with that volume, most reviewers did the only rational thing and approved everything without reading a line, because the workflow asked far more than anyone could give. The control gets marked complete, the audit is satisfied, and the actual access state ends the quarter exactly where it started.
Answering "what could this account do?" takes hours
An incident escalates, and someone senior asks the question that should be simple: what could this account actually reach? The honest answer is that nobody knows yet. Producing it means hours of manual reconstruction, tracing nested groups and inherited entitlements across systems by hand, while the incident clock keeps running and everyone waits on a map that should already exist.
Do these pain points sound familiar?
Deeper essays on why traditional access management is broken. Here's why manual
processes, periodic reviews, and disconnected systems create risk and inefficiency.
Drowning in a Flood of Access Requests?
Monday morning. Forty-three emails in the inbox, thirty-one of them access requests. Click, click, click. IT already knows what each person needs before the ticket is opened; the request just turns that knowledge into manual click-ops, one console at a time. The uncomfortable truth sitting underneath the whole queue is that most of these requests should never have needed to exist.
Learn More
The Baseline Entitlements Spreadsheet
Forty-seven tabs in a spreadsheet, color-coded by department, with columns for every system, every group, and every permission a new hire might conceivably need. The real institutional knowledge lives in the margins: "Check with Sarah first," "Only for senior engineers," "This might be outdated." The baseline that should be policy is instead a document one person maintains and everyone quietly distrusts.
Learn More
Hidden Costs of Employee Role Changes
Sarah got promoted from SDR to Account Executive. HR updated her title the same day, and that was the end of the automation. She kept every permission from her old role and had to track down the new ones herself, asking around until something worked. This is the mover problem, and it remains identity management's largest and most quietly expensive blind spot.
Learn More
Why Sales Team Structure Breaks Access Automation
A case study in why string-matching rules fall apart in practice. Sales teams consistently rank as the hardest population to automate, and not because salespeople are difficult to work with. It is because sales organizations reorganize constantly: territories shift, pods reform, titles change mid-quarter. Rules written against last quarter's structure are already wrong by the time anyone notices they broke.
Learn More
When IdP Group Rules Become Unmanageable
An organization has forty-seven Okta group rules running in production. The current IT administrator wrote twelve of them. Their predecessor wrote another twenty. Nobody knows who wrote the remaining fifteen, or why, or whether they still serve any purpose. One of the forty-seven is definitely wrong, everyone agrees on that much, and not one person can tell you which.
Learn More
HRIS Lacks the Granularity Teams Actually Need
Workday says she is in Engineering. Great. Which of the forty-seven engineering teams, on which of the three concurrent projects, reporting through which of the two managers? Your HRIS tracks departments because departments are what payroll needs. Real access decisions need team, project, and function, and the system you trust as your source of truth records none of them.
Learn More
Identity Governance Forgot About the IT Admin
Six IGA vendor demos in a row. Impressive dashboards, polished compliance scores, executive-friendly reporting. Then you asked the only question that matters to the person doing the work: how does it actually automate group membership? Awkward pause. The honest answer is that IGA was built to reassure auditors, not to help the IT admin who has to provision access every single day.
Learn More
The evolution of the solution
Policy-based automation replaces manual processes with declarative rules.
Access is derived from attributes, not accumulated through requests.
Access Reviews Have Become Audit Theater
Access review season arrives. Eight thousand rows, forty managers, a two-week deadline. Two weeks later the verdict is in: most managers approved everything without reading it, because that was the only way to finish on time. Zero entitlements were removed. Zero security posture improved. The box is checked and the audit is satisfied, but nothing about who can touch what actually changed.
Learn More
The RBAC Drift Problem Nobody Plans For
You implemented RBAC, and on day one it was elegant. Six months later you have one hundred forty-seven roles, nobody can explain what half of them grant, and the average user belongs to eight at once. The theory of role-based access is genuinely beautiful. The lived reality is a tangled, ever-growing mess that drifts a little further from the model every week.
Learn More
Cross-System Access Is Where It Breaks Down
You built the onboarding automation, and for one system it worked beautifully. Then reality arrived: Google, Okta, AWS, GitLab, and Slack each have their own permission model, their own API, their own idea of what a "group" even is. Now you maintain eight brittle scripts, three auth methods, and a growing pile of manual fallbacks for the cases the scripts cannot reach.
Learn More
Why Policy-First Beats System-by-System
Most companies manage access one system at a time: ten admin consoles, ten separate sets of rules, and no unified view of who can do what. Policy-first inverts the whole arrangement. You define once what a person in a given role should have, and that definition is enforced everywhere, automatically, the moment their attributes change. The console stops being where access lives.
Learn More
The Vision of Fully Automated Provisioning
Friday, 3:00pm: the offer is accepted. Friday, 3:30pm: the laptop is ordered, the accounts are created, and access is provisioned across all twelve systems before anyone goes home for the weekend. Monday, 8:00am: the new hire opens the laptop, logs in, and finds everything already working. No tickets filed. No waiting. The first day gets spent on the actual job.
Learn More
Making Exceptions First-Class, Not Forgotten
Policy handles ninety percent of access cleanly, and then real work intrudes: someone needs temporary reach into another team's systems for a cross-functional project that ends in six weeks. Exceptions like this cannot be afterthoughts or sticky notes. They have to be first-class objects with a written justification, a named approver, a hard expiration date, and automatic revocation when the clock runs out.
Learn More
Preserving Access During Graceful Role Changes
Sarah got promoted, and the policy engine did exactly what it was told: it revoked her Salesforce access the instant her title changed. The problem is she was mid-handoff on three open deals, and that clean revocation just broke all of them. Role changes are transitions, not switches. Deprecated access with a defined grace period keeps the work moving while the cleanup still happens.
Learn More
Continuous Compliance vs. Quarterly Reviews
The auditor asks for evidence that access is appropriate. You have two ways to answer. You can hand over a spreadsheet exported last week and hope the questions stay shallow. Or you can show them a policy engine, continuous validation, and a complete audit trail that explains every grant. One of these answers ends the conversation. The other one starts a much longer one.
Learn More
Our Vision for Your Organization
Here is what we think a healthy access program looks like, stated plainly. Provisioning measured in minutes, not days. New people productive on their first morning. Access that changes when the person does. None of this is exotic. It is what you get when policy, rather than a ticket queue, is the source of truth.
Fewer Access Requests
90%
This is not easy or free, and we will not pretend otherwise. It takes real work to model your groups the way your organization should actually implement least privilege. But once that foundation is in place, the routine requests stop arriving, because the access was already correct before anyone thought to ask. The drop is dramatic, and the requests that remain are the ones that genuinely deserved a human's attention.
Ready to Work
Day 1
Access waiting when the laptop opens is the whole point, and it is achievable, but only if the policy work is done up front. We would rather be straight about that than promise magic. Get the foundation right and a new hire's first day goes to the job and the team they joined, not to a stack of tickets and a week of waiting. Let's measure Day 1 readiness and initial productivity during their first week, not IT onboarding ticket SLAs and MTRs.
Access That Changes
Same Day
Access should change as soon as the person's role does, not months later when a review finally catches it. We built the engine to revoke in real time as the org evolves. But transitions are messy, so we model grace periods where a mover keeps overlapping access just long enough to hand off cleanly. String matching could only cut people off at once, because it never knew who had what, for how long, or why.