Turn JML Runbooks into Parameterized Workflows

Tier: Core · Workflow area: Identity, endpoint & patch · ~35 minutes

This playbook takes an existing joiner/mover/leaver runbook and turns it into a parameterized PowerShell/Graph script plus an Entra lifecycle workflow (or ITSM workflow), with AI doing the drafting and you doing the two things AI reliably fumbles: deciding who approves what, and handling the humans who do not fit the happy path. (UC-30)

When to use

• The runbook exists but execution variesonboarding takes 40 minutes or 4 hours depending on who does it, and leavers occasionally keep mailbox access for a week. Variance is the signal.
• Volume justifies parametersmore than a handful of JML events a month, across a small set of role templates (sales hire, engineer hire, contractor, intern).
• You are adopting Entra lifecycle workflows anywaythe license includes them; this playbook is how you feed them logic that matches your org instead of the defaults.

When NOT to use

• No written runbook yetAI parameterizing tribal knowledge produces confident automation of a process nobody agreed on. Write the prose version first, even if it is ugly.
• Exotic one-offsthe acquired subsidiary with its own domain, the exec with bespoke access: handle manually and annotate. Automating the exception costs more than it saves.
• Leaver termination for causeurgent, security-sensitive offboarding follows the incident process with a human at every step, not the scheduled workflow.

The recipe

1. 1.

   Extract parameters from the prose. Paste the runbook and ask:

   Copy

   Here is our new-starter runbook: [paste]. Extract every point where
   the procedure varies by person or role, and propose a parameter table:
   parameter name, type, allowed values, default, and which runbook step
   consumes it. Flag any step where the runbook is ambiguous or where
   two steps contradict each other. Do not write any code yet.
   

   Expect parameters like roleTemplate, department, employmentType (FTE/contractor), startDate, manager, licensingTier, deviceType. The contradictions list is often the most valuable output — runbooks accumulate them for years.

2. 2.

   Decide the approval matrix yourself — before any code exists. For each parameter combination, write down who approves: manager for standard access, app owner for privileged groups, HR for early-access starts, security for admin-role templates. This is policy, not scripting; a model asked to invent it will produce something plausible and unauthorized.

3. 3.

   Have AI draft the parameterized joiner script.

   Copy

   Write a PowerShell function New-Starter using Microsoft Graph SDK.
   Parameters: [paste your table]. Behavior:
   - Create the user from a naming-convention helper (I will supply)
   - Group membership comes ONLY from a role-template lookup table
     defined at the top of the file — no ad-hoc group adds
   - License assignment via group-based licensing, not direct
   - employmentType 'Contractor' forces accountExpirationDate = end date
     (mandatory parameter for contractors) and the contractor UPN suffix
   - Every action writes one line to a CSV audit log: timestamp, actor,
     action, target, parameters
   - -WhatIf support on every mutating call
   Output the role-template table as data I can review separately.
   

4. 4.

   Dry-run against the last five real joiners. Run with -WhatIf using the actual parameters from your last five onboardings and diff the proposed actions against what was really done. Every mismatch is either a script bug or an undocumented runbook step — both are findings worth having before go-live.

5. 5.

   Encode the leaver and mover flows with their sharp edges. Repeat steps 1–4 for leavers (disable, revoke sessions with Revoke-MgUserSignInSession, remove from groups, convert mailbox, set manager access — in an order you specify) and movers (the dangerous one: additive access without removal is how privilege creep happens; require the script to emit an access diff — gained and lost — for manager sign-off).

6. 6.

   Handle rehires explicitly. Ask AI: "Given this joiner script, what breaks if the person previously existed as a user? Cover: soft-deleted objects in Entra, UPN collisions, restored mailbox contents, prior group memberships resurfacing, and stale attributes." Then encode the answer you choose — most orgs want a fresh object with a link to the old identity, not a restore — as an explicit -Rehire code path, never an accident.

7. 7.

   Lift the happy path into Entra lifecycle workflows or your ITSM builder. Scheduled joiner tasks (enable on start date, send welcome, add to template groups) and leaver tasks (disable on last day, remove licenses after N days) move into Entra ID Governance > Lifecycle workflows; the parameterized script remains the tool for everything the workflow engine cannot express — and the two must consume the same role-template table, not two divergent copies.

Make it yours

• Entra-native shopdrive employmentType, department and dates from HR-sourced attributes via inbound provisioning; lifecycle workflows trigger on employeeHireDate/employeeLeaveDateTime, and your script handles day-one exceptions.
• Hybrid AD shopthe script targets on-prem AD (New-ADUser) with Entra Connect sync as the bridge; AI must be told sync latency exists or it will draft scripts that immediately query cloud objects that do not exist yet.
• ITSM-workflow shop (ServiceNow/Freshservice)the catalog form collects the parameters, the workflow enforces the approval matrix from step 2, and the script runs as the fulfillment step via MID server or orchestration — approvals live in the ITSM tool where auditors can see them.

Quality check

• No group membership outside the template table. Ad-hoc adds are the death of role-based access; the script should refuse groups not in the table rather than accept a free-text list.
• Contractors cannot be created without an end date. Make the parameter mandatory and validated, not defaulted.
• The audit log answers "who got what, when, decided by whom". If a mover's access diff was not signed off, the workflow is not done.
• Quarterly runbook-to-code reconciliation. The wiki page and the script drift; diff them with AI's help every quarter and update whichever is wrong.