Skip to main content

Work Management use case

Access request management and automation

Access request management is the work of sending a request for application or data access to the approvers that resource requires, and recording what was granted. Kinetic gives employees one catalog for those requests. Each resource has its own approval workflow, and approved access is provisioned in Okta, Active Directory or the application itself.

Works with Okta, Active Directory, Entra ID and the applications themselves, which stay the record of who has access.

From catalog request to provisioned access

  1. Experience layer

    A catalog where employees pick the application and access level they need, see what they already have, and follow each request to completion.

  2. Workflow layer

    Each resource carries its own approval rules. Approvers act in parallel, approved access is provisioned through APIs, stalled approvals go to a delegate, and temporary access is removed on its end date.

  3. Integration layer

    Reads the requester's role from the HR record and current groups from Active Directory, then assigns groups, Okta apps and Salesforce permission sets through their APIs and updates the ServiceNow record.

    • Okta
    • Active Directory
    • Microsoft Entra ID
    • ServiceNow
    • Salesforce

AI in access request automation

AI doesn't grant access or pick approvers. The resource's policy decides who signs off, and only an approval releases provisioning.

What AI does

  • Summarizes the requester's current access and the risk of the new grant for the approver
  • Matches a free-text request to the right catalog entitlement
  • Flags requests that fall outside the requester's role

Decided by people, not by AI

  • Privileged roles and sensitive data
  • Requests outside the employee's standard role
  • Extensions to temporary access

Where access requests go today

A claims analyst needs read access to the Salesforce service console and to a shared drive her team moved to last month. She emails her manager, who forwards it to the help desk. The help desk opens a ServiceNow ticket, notices the drive belongs to a data owner in finance, and emails him. He replies “approved” from his phone two days later. Someone adds her to an Active Directory group, assigns the Salesforce permission set by hand and closes the ticket.

None of that is unusual. None of it is recorded in a form an auditor can use, either. The approval lives in a reply thread, and the ticket says “done” without saying what was granted. When the quarterly access review arrives, someone rebuilds the history from email.

The same request in Kinetic

The analyst picks “Salesforce service console, read only” and the drive from a catalog. The form shows only the access levels that exist for those resources, and asks for an end date where the resource’s policy requires one.

The workflow reads her role from the HR record and her current groups from Active Directory, then decides who signs off. Her manager approves both items; the drive also goes to its data owner at the same time. Each approver sees what she already has next to what she is asking for.

Once both approve, Kinetic adds the AD group, assigns the Okta application and sets the Salesforce permission set through their APIs, then updates the ServiceNow record if you keep one there. An approver who sits on a request past the deadline you set is skipped in favor of their delegate.

The record it leaves

Each request closes with one record: who asked and why, each approval with its timestamp, and each change made in each system, including any step that failed and was retried. SOX and HIPAA access reviews ask for exactly that, and here it comes out of the work itself instead of a spreadsheet assembled afterward.

Where teams start

Not with every application. Most start with the applications that generate the most access tickets, connect those first, and leave the long tail on a generic “other access” form that a person routes. As new connections are added, items move from the generic form into the catalog.

Access also has to change when people change jobs. Role change automation reuses the same catalog and approval rules for transfers, and the workflow layer page covers how deadlines, delegates and retries run.

Access requests are often the first category in an IT service catalog. They can also sit among the IT services in an employee self-service portal.

Questions about access request automation

Answered by Kinetic Data. Last updated .

  • What is access request management?

    Access request management is the handling of a request for application or data access, from the ask through the approval to the record of what was granted. Employees use one catalog, and each resource carries the approval rules for that grant. Kinetic runs those rules and provisions the result in Okta, Active Directory or the application, which stays the record of who has access.

  • What should an access request management system include?

    It includes a catalog of applications and access levels, approval rules that can differ by resource, and provisioning into Okta, Active Directory or the application. It also keeps one record of who asked, each approval with its timestamp, and each change in each system, including access removed on its end date. Privileged roles, sensitive data and requests outside the employee's standard role stay with a person to approve.

  • How does an access request workflow run?

    The employee picks the application and access level from the catalog, and the form asks for an end date when the policy requires one. Kinetic reads the requester's role from the HR record and current groups from Active Directory, then sends the request to the approvers that resource names. An approver who misses the deadline is skipped in favor of a delegate, and on approval the workflow assigns the Active Directory group, the Okta application or the permission in the target application, then removes temporary access on its end date.

  • Does Kinetic replace our identity governance tool?

    No. If you run SailPoint, Saviynt or a similar tool for certifications and role mining, keep it. Kinetic gives people a place to ask and runs the approvals, then provisions through the identity and governance systems that remain the record of who has access.

  • How does Kinetic decide who approves a request?

    Each catalog item has its own rules: manager only, manager plus data owner, or an added security review for privileged roles. The rules can read the requester's department, role and current access, so a contractor asking for production access takes a different path from an employee asking for a reporting tool.

  • Can access be granted for a limited time?

    Yes. Resources that require it ask for an end date on the request form. The employee and manager get a reminder before it expires, and on the date the workflow removes the access and records the removal.

  • What happens if provisioning fails in one system?

    That step stops and the error is logged against the request, while the other approved items continue. The system owner gets a task to fix the cause, and the step is retried from the workflow, so the requester never sees a ticket marked complete with access still missing.

Bring one process. Leave with a plan to build it.

Two hours with our team, at no cost. Bring one process that crosses your systems. We map it with you, show what Kinetic would build, and send you a written plan afterward.