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.
Tables are read in place through the Table API with the integration user's access control lists, so the app sees exactly the records that user may see. The rows stay in ServiceNow.
| Object | Read from | Fields the app uses | Freshness |
|---|---|---|---|
| Service request | sc_request · sc_req_item · sc_task | sc_req_item.cat_item (item) · sc_req_item.approval (approval) · sc_req_item.number (number) · sc_request.requested_for (requested for) | live through the API |
| Employee | sys_user · sys_user_grmember · sys_user_group | sys_user.employee_number (id) · sys_user.name (name) · sys_user.department (org unit) · sys_user.title (position) | live through the API |
| Configuration item | cmdb_ci · cmdb_ci_server · cmdb_rel_ci | cmdb_ci.sys_id (id) · cmdb_ci.name (name) · cmdb_ci.sys_class_name (class) · cmdb_ci.owned_by (owner) | live through the API |
In plain words: 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.
The criterion runs in ServiceNow through the data handler, so only the matching rows return. The editor shows the rows it selects, and their count, as it is written.
# start criterion in ServiceNow fields sc_req_item.cat_item = 'application access' and sc_req_item.approval = 'requested' # the same criterion in canonical fields {request.item} = 'application access' and {request.approval} = 'requested'
Writes go through the Table API (POST and PATCH). Each call returns the sys_id and number of the record, and the app records both beside the decision. Approvals raised from the app appear in the ServiceNow approval list, so people can act in either place.
| Object | What changes | Interface |
|---|---|---|
| Service request | approval recorded on the approver record; request item closed with the provisioning result | POST table/sc_request · PATCH sc_req_item |
| Employee | group membership added on approval or removed at review | PATCH table/sys_user · POST sys_user_grmember |
Each write stores the identifier ServiceNow returns beside the decision, the person and the time, so the log answers who changed what, and the reconciliation shows it arrived.
Groups and roles are mapped to Lima access policies once. A change manager sees the same change requests in the app that they see in ServiceNow.
The screens read through handlers that leave the rows in ServiceNow. History the app needs at scale is landed in the lake by the Backbone, which is the exception by design.
The prerequisites above: an integration identity with read rights on the objects listed and write rights on the interfaces named, connectivity, and the scopes agreed with the process owner.
Yes. The screens, criteria and roles stay; the handlers are re-bound to the other system's objects, and the app's other system pages show them.
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.
