Handles access requests with the manager's and the system owner's approval, provisions the group in ServiceNow, and runs the quarterly review of every access granted.
Today access is requested by ticket, approved by whoever answers first, and provisioned by hand from a screenshot. The quarterly review is a spreadsheet of 4,000 rows sent to 60 managers, and leavers keep their access until someone notices.
An employee asks for access to an application on the portal screen, with the role and the business reason, or the request arrives as a catalog request in ServiceNow. The app reads the application's configuration item to find its owner, checks the requester's existing groups for conflicts, and routes the approval to the manager and then the system owner; both approvals appear in the ServiceNow approval list, so people can act in either place. On approval the app adds the group membership through the ServiceNow table API and closes the request with the record. Each quarter the app opens a review for every manager and system owner with the access their people hold, and each line is kept or removed, with the removal written back the same day.
| Lane | Does |
|---|---|
| Requester | asks for access with the role and the reason on the portal screen |
| Manager | confirms the need for the requester's job |
| System owner | approves the role on the application; certifies access each quarter |
| Access administrator | handles the exceptions the automatic provisioning returns |
Every screen renders for desktop and mobile; portal screens are the same screens delivered to an outside login.
| Screen | What is on it |
|---|---|
| S01 Request access | portal screen: application picker from the configuration items, role, reason, duration; conflicts shown before submit |
| S02 Approval | request, requester's current groups, conflict check, the application's owner; approve or reject with a note; mobile |
| S03 Provisioning | group to add, result of the table API call, exceptions for the administrator; retry |
| S04 Quarterly review | grid of access held by the reviewer's people or on the reviewer's applications; keep or remove per line; reason; submit |
| S05 Access board | requests by stage and age, approvals within 2 days, review completion by manager, removals this quarter |
The first object is the main one; each system page shows the real table or resource behind every handler.
| Object | Why the app reads it | See it on |
|---|---|---|
| Service request | the access request, its item, requester, approval and state | ServiceNow |
| Employee | the requester, the manager and the groups held | ServiceNow |
| Configuration item | the application, its class and its owner | ServiceNow |
| Object | What changes |
|---|---|
| Service request | approval recorded on the approver record; request item closed with the provisioning result |
| Employee | group membership added on approval or removed at review |
Start: An access request submitted on S01 or as a catalog request in ServiceNow; the review cycle starts on the first working day of each quarter.
# start criterion, in canonical fields; each system page shows it in that system's fields
{request.item} = 'application access' and {request.approval} = 'requested'| Step | Moves when |
|---|---|
| Request received | application matched to its configuration item; owner found; conflict check run |
| Manager approved | manager confirms within 2 working days; a conflict shows its reason to both approvers |
| Owner approved | system owner approves the role; both approvals visible in ServiceNow |
| Provisioned | group membership added; request item closed with the record; requester told |
| Reviewed | each quarter every line is kept or removed; removals applied the same day |
| Component | Trigger → action → outcome |
|---|---|
| dd_application | on change → read the configuration item and the requester's groups → show the owner and any conflict before submit |
| btn_approve | on click → update the approval record in ServiceNow → move the request to the next approver or to provisioning |
| job_provision | on final approval → add the group membership through the table API → close the request item, store the sys_id, notify the requester |
| btn_submit_review | on click → remove the memberships marked remove → record the certification, update S05 |
| Step | Time limit and escalation |
|---|---|
| Approval | 2 working days per approver, then the approver is reminded and the request escalates to the approver's manager |
| Quarterly review | 15 working days, then open reviews are shown to the CIO's office and access still waiting for review is flagged for removal |
Names, places and figures are illustrative; the pattern is the catalogue's.
At 10:15 Priyanka, an analyst in Pune, asked for the planner role in the demand planning application, and the app showed the owner and a clean conflict check before she pressed submit. Her manager approved from his phone at 10:40, the system owner in Dublin approved at 09:05 her time the next morning, and the group membership was in place at 09:06 with the request closed. In the October review the same owner saw 212 lines, removed 19 for people who had changed jobs, and the removals ran before 17:00 the same day.
The objects with their real names, the criteria in that system's fields, the write interface and what to set up first.
Other systems connect through the same handlers; see how SmartApps connect.
About 30 minutes to a first running screen on your live rows, and 4 working days to the production-grade version described here, most of it spent agreeing screens and criteria with the process owner.
Any of ServiceNow, with the objects read in place; the pages above show the objects and the write path for each. Two systems at once is one handler per object per system.
Roles on portal screens see only the rows the access policy allows, and their steps are logged like everyone else's.
Every step, value, decision, notification and write-back acknowledgement of every instance, with the version of the app, append-only.
Bring the process and the systems it touches. In the first session we register the data handlers, draw the levels or the lanes and run the first screen on your live rows.