“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. Ravenna also keeps a record of all access as an entitlement (both active and expired), which admins can view and take immediate manual action to revoke or extend the access as needed.
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.
How to automate software access requests with Ravenna
Think of access in Ravenna as a stack of four simple blocks that build on one another:
Inside Ravenna, an Application is just a container for your different Access Levels, like Viewer or Admin. Each of those levels uses an Access Policy to set the ground rules: who can ask for it, how long they can keep it, and if they need to explain why. Those policies then point to an Approval Template, which tells the system exactly whose eyes need to be on the request before it’s a "go."
While it makes sense to read this list from top to bottom, the best way to actually build it is to work backward. It’s much easier to start with your approval templates, then move to policies and access levels, and save the request form and agent setup for the very end.
Step 1: Set up/import your applications
First, head over to Settings > Integrations to connect your identity provider. If you're using Okta or Microsoft Entra ID, Ravenna will automatically pull in your app catalog, so your tools and groups will sync up without you having to lift a finger.
Google Workspace works a little differently, so don't worry if things don't appear instantly. Since Google doesn’t have a standard app catalog API, you’ll just need to add those apps yourself under Settings > Applications > Add Application. You’ll just need to plug in the basics like the name, domain, and approver. Your groups will still sync on their own, but the "containers" for the apps just need a quick manual head-start.
Regardless of which provider you use, the goal is the same: make sure the software your team relies on is recognized by the system before you start setting up the rules.
Step 2: Create your approval templates
Now, go to Settings > Approval Templates and hit New Template. Give it a clear Name, pick your Workspaces, and start setting up your approval rounds. For every round, you're just deciding two things:
Policy: Determine if a single signature suffices ("Any can approve") or if a consensus is mandatory.
Approvers: Assign specific individuals, entire groups, or utilize dynamic roles like the requester's manager.
You don’t need a custom template for every single tool. Most teams can get by with just three: a simple Manager approval for everyday requests, a Team lead and IT setup for department apps, and a more formal Security access review for sensitive admin tiers.
A pro tip here: try to avoid using specific names. If you use the requester's manager role, your logic will stay current even when people change teams. If you name a specific person, the whole process might stall the moment they move to a new department. If you really need a specific set of eyes, point the round at a group so the workflow doesn’t break when someone leaves the company.
Step 3: Configure your access policies
Next, go back to Settings > Applications, find your application, and click into the Policies tab to create a New Policy. This is where you set the actual rules for how someone gets access:
Name and Description: Clear labels help your future self and teammates understand the policy's intent.
Eligible groups: Define exactly which users are permitted to file a request.
Ineligible groups: Use this to exclude specific cohorts, like contractors, without needing to create complex secondary logic.
Approval template: Select a template from Step 2. If left empty, requests will be automatically approved.
Access Duration: Choose between a fixed window, requester choice, or indefinite access.
Business Justification: A simple switch to require a written explanation for the request.
You can usually cover most of your apps with two basic setups. Use a Standard access policy for common tools with manager approval and a set duration. Then, use a Privileged access review for more sensitive items that needs security oversight and a written explanation.
The auto-approval feature is great for cutting down on busywork. For something like read-only access, which is low-risk but high-volume, you can just gate it by eligibility and let it approve itself. That way, your team can focus on the requests that actually need a human decision.
When configuring duration, the system accepts short-form time syntax like 10m, 1h, or 1d. It is highly recommended to use fixed durations for privileged access. Allowing users to choose their own duration often leads to "forever" requests, which defeats the purpose of Just-In-Time access. Use short windows, such as 8h, for project-based work, and reserve permanent access for foundational tools like your primary email or internal wiki.
Step 4: Define the access levels
Go to Settings > Applications, open the Access Levels tab, and hit Add Access Level. Give each one a Name and Description, link it to the Access Policy you just made, and pick your Provisioning Method.
This is where the actual permissions come together. You can set up a Viewer and Editor level on a standard policy, and save an Admin level for a more privileged one. When you map these out, the agent makes sure users only see the options they’re allowed to request.
The provisioning method you select dictates the automation logic:
Group automates access by inserting the user into a specific group within your identity provider. This is the gold standard for removing manual friction, ensuring that grants and revocations sync perfectly while keeping your IdP as the definitive source of truth.
Application performs a direct assignment to the user, intended for platforms that do not utilize group-based permissioning.
Manual generates a fulfillment task for your team, handling those legacy tools lacking modern APIs or SSO integrations. While the middle step remains human-dependent, you still benefit from automated intake, approval routing, and the critical expiry timer.
Workflow triggers custom logic to manage edge cases that fall outside standard methods.
A big perk here is that it stops people from filing redundant requests. If someone already has Viewer access, the agent will realize it and suggest an upgrade instead of starting from scratch. For this to work, just make sure you’re modeling these as distinct levels rather than one big "access" button.
Step 5: Build and publish the request form
Now it's time to build your form. Go to Forms and start a new one. You only need four fields to get this working:
Application Select
Access Level Select: Ensure this is mapped to depend on your Application Select choice.
Business Justification (set as a text area)
Duration
Once you're done, make sure to save and then hit publish. It’s a step that’s easy to overlook, but the system needs it to be "live" before the logic can start running.
The best part is that you only build this form once for the whole org, not for every single app. It checks eligibility on the fly as it loads, so users only see what they're allowed to have. This saves them from the headache of filling out a request just to get an instant "no."
By centralizing everything here, you don’t need a traditional service catalog anymore. There are no separate pages to maintain—when you add a new app in Step 1, it just shows up here automatically.
Step 6: Switch on agent-assisted requests
This is the moment where all your work pays off. After all, even a perfect form won't help if your team has to go hunting for it.
Head to Agents, select your deployment, and click the Identity tab. In Advanced Settings, just toggle Software Access Requests to "on." Set your agent rules to cover typical requests and you're ready to let it loose in Slack.
Just a quick heads-up: the agent gets its instructions from the form you published in Step 5. If that form isn't live yet, the toggle won't have anything to do.
Once this is live, an employee can just type "can I get access to (X)" in Slack and trigger the whole flow. The agent handles the eligibility check, routes the approval, and manages the expiry without the user ever having to log into a portal or wait for you to handle it manually.
Try focusing your agent rules on the tricky stuff first. While standard requests are easy, the real value is in handling the "off-menu" apps or ineligible requests automatically. A clear, instant answer stops people from getting frustrated and DMing you directly.
Step 7: Test it before your users do
Before you roll it out to everyone, give it a real test run. Don't just look at the settings—submit a request exactly like an employee would.
Try it out in the form and in Slack. Make sure the approval alert goes to the right person and that your policy actually blocks someone who shouldn't have access. Once it's approved, check the source, like your identity provider. to make sure it actually went through. Finally, peek at the Entitlements tab for that app to confirm the grant and expiry date are there.
If you set up any manual provisioning, test that flow too. Since there’s still a human step involved, this is usually the most likely spot for things to get stuck.
There you go….
By following these seven steps, you can eliminate manual access provisioning workflows in a single afternoon. Book a demo with our team to see it first hand.
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.
