IT Joiner-Mover-Leaver and Security Desk Official

When a people event arrives it reads the person from the HR system, applies the role matrix, and writes the plan: one Access Plan row per system with the group or role and the action. For a joiner it drafts the welcome note for the manager. It never creates, changes or removes an account; the plan waits for approval.

1. 01Event "{{event}}": {{event_type}} for {{person}}, effective {{effective_date}}, department {{department}}, new role {{new_role}}. Read the person in the HR system and, for a mover or leaver, their current groups in the identity provider. Read the role matrix. Output: The person's details, current access where relevant, and the matrix rows that apply, plain text.
2. 02Write the plan into Plan and create one Access Plan row per system (Item "<person>: <system>", Event, Person, System, Action, Group or Role, Status Planned). Joiner: every system the role gets, the device, what NOT to create. Mover: additions now, removals after 14 days. Leaver: the playbook's removal order at 17:00 on the last day, the forwarding address to confirm, the 90-day no-delete rule. Set the event's Status to Planned. For a joiner add the welcome note for the manager at the end of Plan. Plain text. Output: The plan and the rows created, plain text.

When a leaver event is set to In progress it takes each Approved Access Plan row and performs it in the connected system: deactivate the identity account, remove vault access, reassign seats, retire the device. Every step is held for approval by policy, and the system's response is written as evidence. Nothing is deleted.

1. 01Leaver event "{{event}}" for {{person}}, effective {{effective_date}}. Read the Access Plan rows for this event with Status Approved, in the playbook's order. Skip anything not Approved and say so. Output: The approved steps in order, plain text.
2. 02Perform each approved step in the connected system (each call waits for a person). After each: write Done At and the system's response into Evidence, set Status Done or Failed. Then write the whole evidence trail into the event's Evidence, set the person's Status to Left, and the event's Status to Done if every step is Done. Plain text. Output: The evidence trail, plain text.

Every morning it reads every managed device from the device tool, updates encryption, OS and last check-in, and for anything out of compliance drafts a short note to the person with their manager copied. After 7 days it raises a ticket. Never locks or wipes a device.

1. 01Read every managed device from the device tool. Create or update the Devices rows. Mark Compliant and Issue per the playbook (encryption, OS within one major version, check-in within {{days}} days, default 14). Output: The devices updated and the ones out of compliance, plain text.
2. 02For each device out of compliance write the Note: what is wrong, the exact steps from the how-to, and that the manager is copied. Send it with Turtle Notify (waits for a person) and set Status Chasing. For a device Chasing for 7 or more days create a Tickets row (Category Device). Plain text. Output: The notes drafted and any tickets raised, plain text.

Every hour it reads new findings from the compliance or cloud security tool, keeps medium and above, closes duplicates against open tickets, picks the owner from the asset, and drafts the ticket with what to do and the evidence needed. Creating the ticket waits for a person; Critical findings alert the IT lead immediately.

1. 01Read findings new in the last {{hours}} hours (default 1) from the security tool, Medium and above. For each, check Findings and the service desk for an open ticket on the same asset and problem. Output: The new findings and which are duplicates, plain text.
2. 02For each non-duplicate create or update the Findings row (Finding, Severity, Asset, Source Tool, First Seen, Owner) and write the Ticket Draft: title with severity, asset, what was found and the control, what to do, evidence needed, owner. Create the ticket (waits for a person), put the link on the row, set Status Ticketed. Mark duplicates Duplicate with the existing ticket link. For a Critical finding alert the IT lead with Turtle Notify. Plain text. Output: The rows written, tickets drafted and alerts sent, plain text.

Every Monday it reads seat usage from the identity provider's application assignments and the last-login data, counts seats unused for 60 days per product, lists renewals within 45 days, and drafts the reclaim or renew note for the licence owner. Never removes a seat.

1. 01For each Licences row read the product's assigned users and last sign-in from the identity provider. Count seats unused for {{idle_days}} days (default 60), including people who have Left. Update Used and Unused 60 Days. Output: Per product, seats bought, used, unused, plain text.
2. 02For products with unused seats write the reclaim Note (who, how many, the saving at renewal) and set Status "Reclaim seats". For renewals within 45 days write the renew-or-reduce Note and set Status "Renewal due". Plain text. Output: The notes written, plain text.

For each system due a review it lists every user with their last login and manager from the identity provider, recommends removal for leavers and 90-day-idle accounts, writes the package, and emails it to the reviewer. Decisions are recorded by the reviewer; removals go through the executor behind approval.

1. 01Quarter {{quarter}} (default the current one). For each Access Reviews row with Status Prepared, read the system's users, last sign-in and manager from the identity provider. Cross-check People for leavers. Output: Per system, the users with last login and manager, plain text.
2. 02Write the Package: one line per user, a recommendation for each leaver and each account idle 90 days, the count. Set Users. Email it to the Reviewer with Turtle Notify. Set Status Sent. Plain text. Output: The packages sent, plain text.

When a ticket arrives it categorises it, drafts the reply from the IT how-to articles, and marks anything that needs a person: access requests (checked against the role matrix), password or MFA resets, security matters. Never resets anything, never grants access.

1. 01Ticket {{ticket}} from {{requester}}: {{subject}}. Message: {{message}}. Set Category. Decide whether a person must handle it (access request, password or MFA, lost device, security). For an access request read the role matrix and any pending people event for the requester. Output: The category, whether a person must handle it and why, plain text.
2. 02If a person must handle it write "NEEDS A PERSON: <reason and what the matrix says>" into Drafted Reply and set Status "Needs a person". Otherwise draft the reply from the how-to in plain steps citing the article, set Status Drafted, and where a service desk is connected add it as an internal note. Plain text. Output: The draft or the NEEDS A PERSON line, plain text.