Runs a new hire's onboarding as one case: HR, the manager, IT and facilities complete their tasks by day, so the hire arrives to a working laptop, access and badge.
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 |
|---|---|---|---|
| HR case | sn_hr_core_case · sn_hr_core_task | sn_hr_core_case.hr_service (type) · sn_hr_core_case.state (state) · sn_hr_core_case.number (number) · sn_hr_core_case.subject_person (subject) | live through the API |
| Service request | sc_request · sc_req_item · sc_task | sc_req_item.number (number) · sc_req_item.cat_item (item) · sc_request.requested_for (requested for) · sc_req_item.state (state) | live through the API |
| IT asset | alm_asset · alm_hardware | alm_asset.asset_tag (id) · alm_asset.model (model) · alm_asset.assigned_to (assigned) · alm_asset.install_status (state) | 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 |
In plain words: A new onboarding case appears in ServiceNow, created when the hire is confirmed in the HR system, with a start date within 30 days.
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 sn_hr_core_case.hr_service = 'onboarding' and sn_hr_core_case.state = 'new' # the same criterion in canonical fields {hr_case.type} = 'onboarding' and {hr_case.state} = 'new'
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 | catalog requests created for the laptop, the access bundle and the badge; closed when fulfilled | POST table/sc_request · PATCH sc_req_item |
| IT asset | laptop assigned to the new hire with the state set to in use | PATCH table/alm_asset |
| HR case | case tasks completed and the case closed after the first-week review | POST table/sn_hr_core_case |
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.
