“Hey, quick question, could you get me into Figma (replace with any platform name here?), my manager said yes on Slack but the ticket hasn’t moved”
If you run IT in your org, you’ve probably seen some version of this message multiple times over the last week, and the question (it seems) almost always lands right about when you’re about to head home.
This is the exact same problem IT teams across all companies face, and the thing is software access requests are not some insanely complex asks for the IT teams to resolve, it’s just that there are so many of them. In fact, more than half of all IT support requests are software access requests, and every last one follows the same flow; a user submits a ticket, you verify their eligibility and license status, track down manager approvals, manually assign them to the correct group, and set reminders for revocation. Except, the process rarely goes according to script.
That’s why I want to break down how you can automate this once and for all using Ravenna, so you and your team can focus on improving efficiency and support tickets that actually deserve more of your time.
Where the portal-plus-workflow model breaks
When anyone submits a support ticket for software access requests, the standard fix for the last 15 years has been the service portal. You build a service catalog, wire up workflows, and declare the form to be the front door, but employees don’t use the catalog, and they sure as hell don’t want to log into the portal.
They’d rather DM the person (you) with the admin button, because filling out a form to ask a question feels like mailing a letter to the guy across the hall. The process behind the scenes, or the portal in this case, is even worse, because it’s either someone doing the provisioning by hand, or it’s a rule-based deterministic workflows that are so brittle that they break the moment someone’s role changes, or someone requests access to something that’s not set up in the rules. Fast-forward six months: the person who built the workflow is gone, ownership is non-existent, and requests just sit there, in the portal that no one is monitoring.
And then there’s revocation; want access to expire? Build that yourself; a scheduler, some scripts, a quarterly audit. And maintain it forever, where “forever” means until the person who wrote it leaves. After that, revocation is a spreadsheet.
Standing access is what piles up in those gaps, and it gets expensive very quickly. Verizon’s 2025 DBIR found stolen credentials were the way in for 22% of breaches. IBM’s latest Cost of a Data Breach report puts the average incident at $4.4 million, with 241 days on average to find and contain it, eight months of someone wandering your systems with a login nobody switched off. Meanwhile CyberArk’s 2025 numbers say machine identities now outnumber humans 82 to 1, nearly half of them privileged. Every one of those is a credential that somebody, at some point, has to remember to revoke, and people are pretty bad at remembering.
Speeding up approvals touches none of this. A faster broken process is still a broken process.
How do you fix this?
The fix, certainly, is not a workflow builder, it’s actually no workflow builder.
In Ravenna, access management runs through agents. You connect Okta, Google Workspace, or Microsoft Entra ID and your applications and groups sync in automatically. Then, in plain language, you tell the system four things about each app: what access levels exist, who’s allowed to request them, who approves, and how long access lasts before it expires.
That’s it. There’s no canvas to drag boxes onto, no catalog pages to design, because there’s nothing to build. You declare the policy. The agents read it and run.
How does this work in the backend?
Let’s look at a common ticket. An employee types “Can I get access to figma” in Slack. Before anyone blinks, the agent already knows whether Figma is requestable (i.e. does the user have eligibility to request figma access + do we have licenses), which tiers they can have, who signs off, and when the access expires. It routes the approval to the right person and nags them if they sit on it. If approved, the user is added to the correct Okta group. All of this happens without the employee ever leaving the thread and IT touching anything.
This works because Ravenna keeps the full process where people already work, Slack or Teams, not just as a channel, but as the interface itself. Controls that add friction get routed around; by keeping the ask, approval, provisioning, and expiry in one thread, you ensure the official path is the easiest path. This approach implements what security teams call Just-In-Time (JIT) access and Zero Standing Privileges (ZSP). Permissions are minted only at request time and deleted automatically at expiry, rather than toggled on and off from a dormant account waiting to be abused.
Why is revocation so important to get right?
If you ask any IT lead about access revocation and they have a very conflicted reaction, because, most of the time, there’s nobody monitoring the revocation in the legacy access request process.
The engineer who got prod database access for the April migration still has it in July, although the migration finished in May. Multiply that by every contractor, every project, every “temporary” grant, and you get the standing-access pile from earlier.
In Ravenna, expiry isn’t something you build manually and you certainly don’t need someone monitoring it as their full-time job. It’s just a field on the policy. Every grant goes out with a timestamp on it, and when the timer runs out the entitlement is gone, and if the user wants to extend access, they can do so in the thread. Admins get a live view of every active entitlement across the org, and can extend or revoke any of them without filing a ticket to themselves.
The benefit of handling everything through one interface (Slack or Teams) is that it becomes easy to record audit trails and evidence for an SOC 2 audit. Instead of stitching together Slack messages, ticket queues, and IdP logs, you get a structured record of exactly who asked, who approved, and when access ended.
Frequently Asked Questions
Why is configuration better than workflows for access requests?
Workflows mean someone builds, maintains, and debugs every path, and they break each time an approver leaves or an app gets added. Configuration means you state the rules once and every request runs against them. There’s nothing to break.
How does Ravenna handle offboarding?
Ravenna holds context on every active entitlement a user has, so one action revokes all of it and locks them out. IT doesn’t have to reconstruct which apps that person could access.
Which identity providers does Ravenna work with?
Okta, Google Workspace, and Microsoft Entra ID. Apps and groups sync in automatically, and group membership is what the agent changes when a request gets approved.
What if someone requests access they already have?
The agent catches it and offers the next tier up instead. That’s usually what the person wanted. They just didn’t know what it was called.
