Account Termination Workflow

A step-by-step guide to building an HR/security-triggered workflow that revokes a departing employee's access role and disables their Active Directory account after manager approval. Approval denials end the run silently (no notification to the employee). Provisioning failures notify the approving manager instead of failing silently.

This matches the Account Termination starter in the New Workflow gallery. You can instantiate that starter and skip to Step 6 — Publish, or rebuild it by hand below.

Prerequisites

1. A configured Active Directory connector (or the built-in test-activedirectory mock connector for a dry run without a real directory).
2. A role the departing employee currently holds (the role this workflow will revoke), created under People → Roles.
3. The workflow:create, workflow:update, workflow:publish, and workflow:read permissions on your admin account (the Workflows tab and GET /api/workflows are gated on workflow:read), and template:read if you instantiate the starter from the gallery. Starting a verification run (Step 6) also requires workflow:start.

Security model — read this before publishing

• Denials are silent on purpose. The only contact parameter is the manager who just denied the request. Notifying them of their own denial is circular; notifying the employee that a termination was considered-but-denied would leak an internal HR/security deliberation. The approval step's error transition goes straight to a denied end node with no notification step.
• Look the directory account up by email, not by username. The test-activedirectory disableAccount command keys users on sAMAccountName. Passing {{targetUser.email}} as username looks up the email string as a map key and fails with User not found for every real directory account (for example jdoe / jdoe@corp.example.com). Pass userEmail: "{{targetUser.email}}" so the connector's ensureUsernameFromEmail hook can resolve the canonical username.
• Do not claim an archive ran. This starter has no storage connector. archiveBucketId is instantiate-time metadata for the operator (where they expect archived data to live). Interpolating it into the success email either asserts an archive that never happened or, if the optional parameter is left blank, leaves a literal {{ARCHIVE_BUCKET_ID}} in the manager's inbox.

Overview

flowchart TD
  Start[Start]
  Approve["Manager approval"]
  Revoke["Revoke access role"]
  Disable["Disable AD account"]
  NotifyOk[Notify manager — complete]
  NotifyFail[Notify manager — failed]
  Success[End: Success]
  Failure[End: Failure]
  Denied[End: Denied]

  Start --> Approve
  Approve -->|success| Revoke
  Approve -->|error| Denied
  Revoke -->|success| Disable
  Revoke -->|error| NotifyFail
  Disable -->|success| NotifyOk
  Disable -->|error| NotifyFail
  NotifyOk --> Success
  NotifyFail --> Failure

Step 1 — Create the workflow

Navigate to Design in the sidebar (opens /workflows), open the Workflows tab, and click New Workflow:

Field	Value
Name	Account Termination
Description	Revoke access and disable the AD account after manager approval
Category	user
Subject Variable	targetUser
Error Strategy	stop
Trigger	manual

Category is user (not user_self_service): this is an admin-initiated offboarding flow, so targetUser is declared explicitly rather than bound to the person who starts the run.

Step 2 — Variables

Name	Type	Required	Description
targetUser	user	yes	Employee being offboarded (the subject).

Step 3 — Build the graph

1. Manager approval (approval) — approvers is the manager who must sign off. success → revoke; error → the denied end node (no notification).
2. Revoke access role (role_revoke) — roleDefinitionId is the role to take away; userId is {{targetUser.id}}. error → shared failure notification.
3. Disable Active Directory account (connector) —

Config key	Value
connector	test-activedirectory
command	disableAccount
userEmail	{{targetUser.email}}

Do not set username to the email. error → shared failure notification.

1. Notify manager of successful termination (notification) — internal recipient, the same manager. The body should report that the role was revoked and the directory account disabled. Do not mention an archive location unless a real archive step exists.
2. Notify manager of termination failure (notification) — same recipient; include {{lastStepError.stepId}} and {{lastStepError.message}}.
3. Three end nodes: success, failure, and denied.

Step 4 — Parameters (if you save this as a template)

Parameter	Required	Purpose
managerUserId	yes	Approver, and the recipient of success/failure notices.
accessRoleId	yes	Role definition revoked from the departing employee.
archiveBucketId	no	Operator metadata only. Not interpolated into any step.

Step 5 — Connectors

Point the disable step at a real Active Directory connector before production use. The starter uses test-activedirectory so the graph runs in a dry environment.

Step 6 — Publish

Save, then Publish. Start a run with a test user whose directory mail attribute matches targetUser.email and confirm the AD account is disabled after the role revoke succeeds.