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.