Projects · Developer workbook
Building Ticket-to-Machine
A developer workbook for the Ticket-to-Machine loop on ServiceNow and SailPoint
A developer workbook for the Ticket-to-Machine loop on ServiceNow and SailPoint
All nine chapters are written. This page was approved in the owner’s review of the November 2, 2026 packet, and an approved page that changes goes back on the weekly source watch issue’s list. Chapters 01 to 08 have narrated tours, recorded on November 1, 2026; Chapter 09 has none. Every vendor fact was checked against ServiceNow’s, SailPoint’s or Microsoft’s own documentation, or the FedRAMP Marketplace, on November 1, 2026 (Chapter 09 on November 2, 2026) and carries a note, and each chapter keeps its verification log in the repository. The code is illustrative. Its tests pass against fixtures and mocked responses, but it has not been run against a live ServiceNow instance or SailPoint tenant, and nobody has yet followed Chapter 09’s deployment runbook on one.
Book 13’s Ticket-to-Machine loop is vendor-neutral on purpose. This workbook builds it on two named products, ServiceNow and SailPoint Identity Security Cloud (ISC), because the program’s example guide and kit use them. Other products can fill the same slots, and naming these is not a recommendation by any agency.
Book 13, Chapter 10 argues that a ticket should authorize a machine, not send a person to a console, and that a finding closes only when a re-read proves the result. Appendix B gives the loop, the five-clause request chain, the lanes, the tempo and the evidence record. The example guide Ticket-to-Machine on ServiceNow and SailPoint walks that loop through two products and finds four gaps between them and the loop. The implementation example Integrating ServiceNow and SailPoint (Pass 1) explains a kit of scripts, examples/servicenow-sailpoint, that has three builds covering four of the loop’s five steps. Those say what the loop must do and what the kit does. They don’t teach a developer to extend, test and ship that code.
This workbook does. It is code first. Each chapter starts from the code already in the kit, adds what the chapter needs, with tests, and runs a lab on a laptop against the kit’s fixtures with no tenant at all. Then it gives the smallest step in a ServiceNow Personal Developer Instance or a SailPoint sandbox tenant, with a way to back it out. Each lists the vendor facts the code depends on (endpoints, authentication, the least-privileged role or scope, FedRAMP status), footnoted to the vendor’s own page with the date it was read, then what the chapter’s output proves and for whom, the dangers and a checklist.
The estate is a FedRAMP Moderate civilian one: ServiceNow’s Government Community Cloud (FedRAMP High) as the front door and the record, SailPoint ISC (FedRAMP Moderate) for identity governance,1 and Microsoft 365 GCC for the directory, which uses the worldwide endpoints login.microsoftonline.com and graph.microsoft.com.2 Every chapter says where an endpoint or a feature’s availability matters.
The pieces and how they connect
| Piece | What it is | Where |
|---|---|---|
| Book chapters | The vendor-neutral design: the tempo, the qualifying change classes, the actuation ladder and the five-clause chain, the lanes and the evidence record | Book 13, Chapter 10 and Appendix B; the drift classes in Book 03, Chapter 11 |
| Example guide | The loop on ServiceNow and SailPoint, the four gaps, and each product’s federal status | Ticket-to-Machine on ServiceNow and SailPoint |
| Implementation example | Pass 1 of the kit: drift to a typed task, the re-read rule, the drift reconciliation; and what Pass 2 plans | Integrating ServiceNow and SailPoint (Pass 1) |
| Developer workbook | This workbook: nine chapters, eight building on the kit with labs and tests and a deployment runbook for a test environment and production | Chapters below |
| Code | The kit: ISC workflows, the ServiceNow Scripted REST resource and business rule, Python and PowerShell clients, fixtures and tests, and this workbook’s additions | examples/servicenow-sailpoint on GitHub |
| Decks and videos | The narrated deck for Book 13’s Appendix B, the narrated research deck for the example guide, and the guide’s two-part implementation series | Presentations · Implementation series · ▶ Watch the example guide’s deck |
| Story deck | One narrated deck, about 21 minutes, that follows one fictional person’s drifted department through every chapter, with the kit’s own fixtures, a “Try it” command and a one-question check per scene | One Drift Case, End to End: Deck · Narrated deck (about 21 minutes, captions) · ▶ Watch · MP4 |
| Training | A learning path built from the example guide, the decks and this workbook’s labs: seven modules with exercises and knowledge checks | Learning path: Ticket-to-Machine on ServiceNow and SailPoint |
| Word edition | This workbook as one document | building-ticket-to-machine-bundle.docx |
How they connect: the book chapters set what the loop must prove. The example guide says where the two products fall short of it. The implementation example says what the kit builds to close the gap. This workbook builds on the kit, chapter by chapter, and every chapter’s lab runs the kit’s own code. The decks present the book and the guide; the training path links this workbook’s labs rather than repeating them.
How each chapter is built
| Section | What it holds |
|---|---|
| Goal and audience | What you will build, and who should read it |
| The code | What exists in the kit, what this chapter adds, and the tests |
| Lab 1: fixtures, no tenant | Commands that run on a laptop against the kit’s fixtures, with the expected output. Every one was run before it was written down |
| Lab 2: a test instance | The smallest step in a ServiceNow Personal Developer Instance or a SailPoint sandbox, and how to back it out. Not run by the authors |
| The verified facts | Endpoints, authentication, the least-privileged role or scope, FedRAMP status, each footnoted to the vendor’s page |
| Federal requirements and evidence | What the chapter’s output proves, for which control or requirement, and who keeps it |
| Dangers | What breaks in production, and the guard the code has for it |
| Checklist | What a reviewer checks before the code ships |
Design guidance marks the program’s own positions; (inference) marks a mapping the vendor doesn’t state. Where a vendor’s documentation doesn’t settle a point, the chapter says so under “What couldn’t be verified” and the kit’s README keeps it on the verify list.
Chapters
The arc follows the loop’s five steps and the kit’s three builds. Chapter 01 sets the record every other chapter writes or reads. Chapters 02 and 03 build the two clients and fix their least privilege before any call is made. Chapters 04 to 06 are the kit’s Builds 1 to 3. Chapter 07 turns closed findings into the evidence an ISSO reads, and Chapter 08 builds the one Pass 2 check that runs offline today. Chapter 09 is the runbook that takes the kit from a developer instance to a test environment and then to production.
| # | Chapter | Loop step | Builds on | What you build | Status |
|---|---|---|---|---|---|
| 01 | The loop and the typed task | 3 Raise a typed task | The data contract in the kit’s README and the Scripted REST script | finding_contract.py: the contract checked before posting, mirrored from the script by a test; the de-duplication key and the tempo |
Written |
| 02 | The ServiceNow client and least privilege | 3, 5 | kit_common.py (tokens, paging, retries) |
config/calls.json, every call with its task and least privilege; kit_calls.py; a test that fails on any undeclared call; the ServiceNow roles split by task |
Written |
| 03 | The SailPoint client and its scopes | 1, 2, 5 | kit_common.py’s ISC token, search and list paging |
The ISC and Graph rows of the call list, and a comparison of an API client’s granted scopes with what each task needs | Written |
| 04 | Drift to a typed task | 2, 3 (Build 1) | The ISC workflows and the Scripted REST resource | workflow_payload.py: each workflow’s body resolved against a sample event and checked; two fixes, multivalued changes reverted and the attribute in the de-duplication key |
Written |
| 05 | The re-read rule | 5 (Build 2, Gap 1) | The business rule and reread_verification.py |
An offline mode over saved records and reads, and a guard that never verifies an intended state with nothing to check | Written |
| 06 | Drift reconciliation | 1, 2 (Build 3) | identity_drift.py |
drift_compare.py: run over run, new, persisting and resolved, refusing runs that computed different classes |
Written |
| 07 | Evidence records for Book 13 and the ISSO | 5, clause 5 | The re-read client’s evidence and Book 13’s record shape | evidence_export.py: one record per closed finding, integrity and window checks, a manifest and a hash chain, and a verifier |
Written |
| 08 | One writer per attribute | Pass 2, gap 4 | The kit page’s plan for Pass 2 | writer_check.py: Entra inbound provisioning’s mappings and SailPoint’s provisioning policies compared, offline |
Written |
| 09 | Deploying to test and production | 1, 2, 3 and 5, gates G1, G3, G4, G6 and G7 | Chapters 01 to 08 and the guide’s gates and rollback | The runbook, and deploy/: one settings file per environment, a pre-flight check, the workflows rendered per environment, a synthetic-worker smoke test, a rollback plan and check |
Written; not run live |
Pass 2’s other items, one approver per authority class, change records on demand, the SailPoint half of the evidence export and email intake, need a live instance or product internals the documentation doesn’t give, so no chapter builds them yet.
Narrated chapter tours
Chapters 01 to 08 each have a narrated tour: a deck in Why, What, Who and How order, a self-running edition with captions, and a video. The tours were recorded on November 1, 2026 from the approved chapters, and a tour is re-recorded when its chapter changes. All of them are also on the Watch page.
| # | Chapter | Watch | Length | Deck | Narrated deck |
|---|---|---|---|---|---|
| 01 | The Loop and the Typed Task | ▶ Watch · MP4 | 10 min | DW_TTM_01_Loop_Typed_Task.pptx | Narrated |
| 02 | The ServiceNow Client and Least Privilege | ▶ Watch · MP4 | 9 min | DW_TTM_02_ServiceNow_Least_Privilege.pptx | Narrated |
| 03 | The SailPoint Client and Its Scopes | ▶ Watch · MP4 | 10 min | DW_TTM_03_SailPoint_Scopes.pptx | Narrated |
| 04 | Drift to a Typed Task | ▶ Watch · MP4 | 10 min | DW_TTM_04_Drift_Typed_Task.pptx | Narrated |
| 05 | The Re-read Rule | ▶ Watch · MP4 | 9 min | DW_TTM_05_Reread_Rule.pptx | Narrated |
| 06 | Drift Reconciliation | ▶ Watch · MP4 | 9 min | DW_TTM_06_Drift_Reconciliation.pptx | Narrated |
| 07 | Evidence Records for Book 13 and the ISSO | ▶ Watch · MP4 | 9 min | DW_TTM_07_Evidence_Records.pptx | Narrated |
| 08 | One Writer per Attribute | ▶ Watch · MP4 | 9 min | DW_TTM_08_One_Writer_Per_Attribute.pptx | Narrated |
Reading paths
- Developers new to the loop: Book 13, Appendix B for the loop and the evidence record, then Chapter 01.
- Developers building the ServiceNow side: Chapters 01, 02, 04 and 05, in that order.
- Identity engineers on the SailPoint side: Chapters 03, 04 and 06, then 08.
- ISSOs and reviewers of the code: Chapter 07, then the checklist and the federal requirements section of every chapter.
- Deployers and change managers: Chapter 09, after Chapters 02 and 03 for the integration identities.
Where this workbook sits
This is one of the developer workbooks under Projects in the Federal Modernization Workbook. Its design is Book 13, Chapter 10 and Appendix B; its drift classes are Book 03, Chapter 11’s; its intake and authority split are Book 15, Chapter 03’s. The loop’s actuation ceiling for each pilot class is decision D-M4 in the Continuous Monitoring project plan. Where an agency has no identity governance product, Book 15, Chapter 13 describes building the ServiceNow side in house; this workbook’s ServiceNow chapters apply there too.
Chapters
| Title | Description |
|---|---|
| Chapter 01 — The Loop and the Typed Task | Where the kit sits in Book 13’s five-step loop, and the one record every step writes or reads: the typed identity finding. Check the data contract on a laptop before anything reaches ServiceNow, with the drift classes, severities, systems, subject rules, tempo and de-duplication key mirrored from the Scripted REST script by a test, and a warning when an intended state gives the re-read nothing to check; with labs against fixtures and a ServiceNow developer instance. |
| Chapter 02 — The ServiceNow Client and Least Privilege | The ServiceNow half of the kit’s shared client: OAuth client-credentials tokens at oauth_token.do, Table API paging, the Attachment API and retries on 429 and 503. Declare every HTTP call the clients make, with the task that makes it and its least privilege, in one reviewed file; fail a test when a client makes a call that isn’t declared; and split the ServiceNow roles by task so the evidence reader can’t close a finding; with labs against fixtures and a ServiceNow developer instance. |
| Chapter 03 — The SailPoint Client and Its Scopes | The SailPoint half of the kit’s shared client: ISC tokens by client credentials or a personal access token, Search with searchAfter paging, the Accounts API with limit and offset, and the Microsoft Graph reads the re-read and drift clients make. Declare the ISC and Graph calls with their least-privileged scope or permission, compare an API client’s granted scopes with what each task needs, and keep the workflow-creation scope off the clients that read; with labs against fixtures and a SailPoint sandbox tenant. |
| Chapter 04 — Drift to a Typed Task | Build 1 of the kit: SailPoint event triggers start ISC workflows whose HTTP Request step posts a typed identity finding to the ServiceNow Scripted REST resource. Resolve each workflow’s request body against a sample trigger input on a laptop, derive the intended state the script will store, check it against the data contract, and list the input fields the workflow drops. Two fixes follow from it: multivalued attribute changes are now reverted like any other, and the attribute is part of the de-duplication key; with labs against fixtures and a SailPoint sandbox. |
| Chapter 05 — The Re-read Rule | Build 2 of the kit and its answer to Gap 1: a ServiceNow business rule turns any close into Awaiting verification, and a client re-reads the account, identity or user from its system of record and closes the finding only with the evidence, or reopens it. Run the same decisions offline from saved records and saved reads, judge ISC’s aggregation lag against a fixed clock, and add the guard that an intended state naming nothing a re-read can check is skipped, never verified; with labs against fixtures and a ServiceNow developer instance. |
| Chapter 06 — Drift Reconciliation | Build 3 of the kit: a read-only client joins the HR extract, Microsoft Graph and SailPoint ISC on employeeId and reports Book 03’s drift classes with stable finding IDs. Run it twice, a day apart, and compare the runs by finding ID into new, persisting and resolved findings, refusing to compare runs that computed different classes, so a class one run skipped can’t look fixed; resolved findings are leads for the re-read, not closures; with labs against fixtures and a test tenant. |
| Chapter 07 — Evidence Records for Book 13 and the ISSO | The ServiceNow half of Pass 2’s evidence export: read closed and cancelled identity findings and write one record per finding in Book 13’s evidence shape (origin, owner and clock, approval, executing identity, what ran, result, closure), with the Pass 1 gaps written as null and the reason, never invented. Check each record’s evidence against its hash, its closure against the business rule, and its finish against its response window, and package the period with a manifest and a hash chain an ISSO can verify; with labs against fixtures and a ServiceNow developer instance. |
| Chapter 08 — One Writer per Attribute | Gap 4 of the Ticket-to-Machine example and an item planned for the kit’s Pass 2: if Entra inbound provisioning from HR and SailPoint’s Entra source both write the same user attribute, each overwrites the other and drift never settles. Compare the inbound provisioning job’s synchronization schema from Microsoft Graph with the ISC source’s provisioning policies, offline, and report every attribute with two writers by how each writes it, update or create only; with labs against fixtures and exports from a test tenant and a SailPoint sandbox. |
| Chapter 09 — Deploying to Test and Production | The deployment runbook: take the kit from a developer instance to a ServiceNow sub-production instance and a SailPoint sandbox tenant, then to the production instance in ServiceNow’s Government Community Cloud and the production ISC tenant. One settings file per environment and no secret in it; pre-flight checks for Gate 1, OAuth client credentials and least privilege; the application installed by the vendor’s documented method; the ISC workflows created disabled, test-run and enabled in stages; a smoke test with a synthetic worker and the expected result of each step; promotion criteria, first-week monitoring and rollback; and for each step the federal requirement it serves, the FedRAMP 20x KSI it aligns to, and the hash-chained evidence record the scripts write for the ISSO. Every step is a command or an exact menu path, and nobody has yet run it against a live tenant. |
Version and revision history
Version 2.0, in edition 2026.11.5 (November 8, 2026). Every edition is kept on the Archive page; every change between editions is in the commit history.
| Version | Edition | Date | Changes |
|---|---|---|---|
| 2.0 | 2026.11.5 | 2026-11-08 | Release 2.0, the baseline: checked against every other book; Draft becomes Baseline; Edition 2026.11.4: record the edition and point deck links at it (#362); Review gate ignores the edition tag in deck links; four decks build again (#363); Reword the evidence export summary: closed, not closed on a re-read (#384); Workbooks HR and ticket-to-machine: fix confirmed crosswalk errors (pre-flight order, test evidence, VK-HR-06 limit, JW rule count, ISC clients) (#409); Apply the open-choice decisions: text, plans, training, reference, register (#416); HR-driven identity and Ticket-to-Machine workbooks: fix inconsistency findings (#449); Approve 116 gated pages (Nov 7); fix RMF map stale-review test (#457); and 1 more (all changes) |
| 1.4 | 2026.11.4 | 2026-11-05 | Approve ten pages on Mike’s word, and drop two names from the briefs (#360) |
| 1.3 | 2026.11.3 | 2026-11-05 | Review gate: Mike’s approval of the 53 pages in the November 2 review packet (#334) |
| 1.2 | 2026.11.2 | 2026-11-02 | Ticket-to-Machine: real kit output in the labs and on the tours’ Lab 1 slides (#288); HR-Driven Identity labs: exact commands for every step, real output, commands lists (#293); Ticket-to-Machine: federal requirements, KSIs and evidence for every scripted kit action (#301); Building Ticket-to-Machine, Chapter 09: deploying to test and production (#302) |
| 1.1 | 2026.11.1 | 2026-11-01 | Edition 2026.11: record the edition, and publish the four gate-level decks and videos (#282); Building Ticket-to-Machine: a narrated story deck and eight chapter tours (sources) (#283) |
| 1.0 | 2026.11 | 2026-11-01 | Building Ticket-to-Machine: a developer workbook with labs (#275); Learning path: Ticket-to-Machine on ServiceNow and SailPoint (#277); Learning path: HR-Driven Identity in Microsoft Entra ID (#278); Gate-level deck series for HR-Driven Identity and Ticket-to-Machine (sources) (#280) |
Footnotes
FedRAMP Marketplace data, https://www.fedramp.gov/marketplace/products.json (last change November 1, 2026): ServiceNow Government Community Cloud (F1305072116), FedRAMP Certified, High, JAB, authorized August 12, 2019; SailPoint Identity Security Cloud (FR2001938710A), FedRAMP Certified, Moderate, agency path, authorized June 5, 2024 (read November 1, 2026).↩︎
Microsoft Learn, “Microsoft Graph national cloud deployments,” service root endpoints, https://learn.microsoft.com/graph/deployments (read November 1, 2026).↩︎