Training module · Draft
Learning path: Ticket-to-Machine on ServiceNow and SailPoint
Seven modules that teach you to build, test and evidence Book 13’s Ticket-to-Machine loop on ServiceNow and SailPoint Identity Security Cloud, gate by gate, with labs on fixtures and in your own test instance
Status — Draft
This page is still being written. Expect gaps and changes; it is not part of the workbook's production guidance. Last reviewed 2026-11-07.
In this learning path, you build the identity half of Book 13’s Ticket-to-Machine loop on two named products: ServiceNow as the front door and the record, and SailPoint Identity Security Cloud (ISC) for identity governance. You learn it in the order the example implementation guide builds it, one or two gates per module, and you prove each step with the developer workbook’s tested code.
The path doesn’t repeat the guide, workbook or book pages. Each module frames the work, sets your objectives, sends you to the exact guide, workbook and book sections that teach it, carries the workbook’s Lab 1 in full as an exercise (Lab 2 is a short pointer), and checks what you learned.
The loop is vendor-neutral. This path uses ServiceNow and SailPoint because the example guide and the developer workbook do. Naming them isn’t a recommendation by the program or any agency.
About this path
| Level | Intermediate |
| Roles | Developer, identity governance (IGA) engineer, ITSM (ServiceNow) engineer, ISSO reviewer |
| Products | ServiceNow (a Personal Developer Instance for Lab 2), SailPoint Identity Security Cloud (a sandbox tenant for Lab 2), Microsoft Graph (read only) |
| Scope | A FedRAMP Moderate civilian estate, as the guide’s audience note describes |
| Modules | 7 |
| Time | About 5 hours 40 minutes, not counting the optional Lab 2 exercises |
What you’ll be able to do
When you finish this path, you’ll be able to:
- Explain the loop’s five steps, and name the kit file for each step that has one and the step that has none.
- Validate an identity finding payload on a laptop and predict what ServiceNow will do with it.
- Configure and verify least privilege for every ServiceNow role, ISC scope and Graph permission the kit uses.
- Detect an attribute with two writers before it causes drift that never settles.
- Measure identity drift run over run, and explain why a run that skipped a class can’t be compared.
- Predict the finding an ISC event produces, and test a workflow change before you import it.
- Verify that a finding closes only on a re-read, never on a ticket status.
- Produce and verify the evidence package an ISSO keeps for the period.
Prerequisites
- The design. Read Book 13, Chapter 10 for why a ticket should authorize a machine, and skim Appendix B for the loop, the request chain and the evidence record.
- Microsoft Graph, for the modules that read it. Modules 2, 3, 4 and 6 involve Microsoft Graph permissions or reads. If you haven’t scripted Graph before, work through Microsoft Automation, Module 1 first: the clouds and endpoints, signing in as a workload and permissions.
- Code. You can read Python and JSON, run commands in a terminal, and read a little JavaScript. PowerShell is optional: the kit has a PowerShell client and Pester tests, but the labs here use the Python tools.
Watch first (optional)
- The workbook’s story deck, One Drift Case, End to End: one fictional person’s drifted department followed through every module’s gate, with the Lab 1 command and a knowledge check for each scene, about 21 minutes: Deck · Narrated deck (about 21 minutes, captions) · ▶ Watch · MP4.
- The two-part narrated deck series for the implementation guide (Parts 1 and 2) is listed in the example guide.
- The narrated deck for the example guide: ▶ Watch, about 10 minutes.
- The narrated deck for Book 13’s Appendix B: Presentations.
Modules
Work through the modules in order. Each one builds on the one before, and the times are estimates for the reading, the Lab 1 exercise and the knowledge check.
| # | Module | Guide gates | Workbook chapters | Time |
|---|---|---|---|---|
| 1 | The loop and the typed task | G4 | 01 | 50 min |
| 2 | The boundary and least privilege | G1 | 02, 03 | 60 min |
| 3 | One writer per attribute | G2 | 08 | 40 min |
| 4 | Sources and the starting drift | G3 | 06 | 45 min |
| 5 | Drift to a typed task | G3, G4 | 04 | 45 min |
| 6 | Actuation and the re-read rule | G5, G6 | 05 | 55 min |
| 7 | Evidence for the ISSO | G7 | 07 | 45 min |
Module 1 starts at Gate 4 because every other gate writes or reads the record that gate defines. From Module 2 on, the modules follow the guide’s gate order.
If you’re an ISSO reviewer, you can read each module’s introduction, its federal requirement and its summary, and skip the labs. Module 7 is yours in full. The workbook’s reading paths suggest an order for each role.
What you need for the labs
Every module has two exercises.
Lab 1: fixtures, no tenant. Every Lab 1 runs on a laptop against the kit’s fictional fixtures. You need:
- a copy of the repository, so you can work in
examples/servicenow-sailpoint; - Python 3.10 or later, with
pytestandrequests; - Node.js 18 or later, for the steps that run the ServiceNow scripts’ tests;
- a Bash-compatible shell for the commands as written. PowerShell 7 with Pester 5 is needed only for the kit’s PowerShell tests, which these labs don’t run.
Run every command from examples/servicenow-sailpoint. The labs write to an out folder there; delete it after each module.
Lab 2: your test instance. Each Lab 2 is a short pointer to the workbook chapter’s Lab 2. The authors haven’t run them, and the workbook has no hosted sandbox: you bring your own. Depending on the module, you need:
- a ServiceNow Personal Developer Instance, never production (Chapter 01, Lab 2);
- a SailPoint ISC sandbox tenant. How an agency gets one is between it and SailPoint (Chapter 03, Lab 2);
- for Modules 3, 4 and 6, a test Entra tenant in the worldwide or GCC cloud for learning, with synthetic data (before a gate passes, rehearse once in your agency’s own cloud, as Book 16 describes).
Every Lab 2 ends with a back-out step, but later modules reuse some of what an earlier back-out deletes. Back out after the last module that uses the objects, or at the end of the path, and keep these until then: Module 1’s scoped application (Module 2 builds its roles in it), Module 2’s workflow client (Module 5) and verifier user (Module 6), and the finding you close in Module 6’s Lab 2 (Module 7). Back out everything else at the end of each module.
Where this path sits
This path is the fourth of the guide’s four pieces: the example guide, its narrated deck series (Parts 1 and 2, listed in the guide), the developer workbook and this path. The kit and its Pass 1 scope are explained in Integrating ServiceNow and SailPoint (Pass 1). Federal sources are in the federal framework crosswalk.
Status and review
Draft. The path and its knowledge checks are new writing; every fact they rely on is on a linked page and carries that page’s verification. Each module’s Lab 1 commands were run against the kit on November 1, 2026, and the expected output shown is what they printed. To move this path to In review, a reviewer works through it end to end and confirms each knowledge-check answer against the linked section. What each status means is in Status labels.