What is identity and access automation?
Identity and access automation connects employee and contractor lifecycle events to approved permissions, account provisioning, temporary access expiration, and verified revocation. It replaces disconnected IT tasks with a controlled process that records what was requested, authorized, executed, and confirmed in each system.
This blueprint builds three connected workflows:
- Employee IT provisioning: validate an approved hire, resolve an existing identity, apply the correct permission profile, and verify accounts and authentication requirements.
- Contractor access request routing: obtain explicit approvals for a limited access package, enforce an end date, and verify actual permissions.
- Access revocation on offboarding: disable the departing identity, remove downstream and privileged access, transfer ownership, and verify removal.
The core rules are: no access without approval, no privilege without policy, no temporary access without expiration, no offboarding without verification, and no identity change without an audit trail.
Use this guide for IT, HR, security, and operations teams managing joiners, movers, and leavers across multiple applications. It is an implementation blueprint, not a ready-to-import workflow. Verify connector capabilities, licenses, API permissions, and company policies before deployment.
Architecture and sources of truth
Approved HR event or access request
→ Validate → Identity lookup → Resolve policy and approval
→ Provision, modify, or revoke → Verify actual access
→ Record audit → Notify accountable owners
Active identity → Periodic access reconciliation
Contractor expiry or departure → Revocation → Verification
Failed action → Controlled retry → Remediation and escalation
| Layer | Responsibility |
|---|---|
| HRIS or contractor registry | Employment type, active status, manager, start and end dates, approved departure events |
| Identity registry and identity provider | Stable identity links, primary authentication, directory account, lifecycle state |
| Application registry | System ownership, risk, contractor eligibility, integration and verification methods |
| Permission registry | Versioned role profiles, allowed permissions, approval requirements, exceptions |
| Approval service or ITSM | Authorized decisions for a specific identity and access package |
| Automation engine | Event normalization, scheduling, routing, durable run progress, retries |
| Target applications | Actual account, group, role, session, and entitlement state |
| Vault and audit store | Protected integration credentials and tamper-resistant lifecycle evidence |
Google Workspace, Microsoft 365, Slack, Teams, CRM, project management, GitHub, and other applications are possible targets. Provisioning, revocation, and session controls vary by platform; document unavailable controls rather than assuming every connector supports them.
Shared identity record and workflow states
| Group | Fields |
|---|---|
| Identity | user_id, employee_id, first_name, last_name, work_email, restricted personal_email when necessary |
| Employment | employment_type, department, job_title, manager, manager_email, start_date, end_date, termination_date |
| Access | user_role, access_level, systems_required[], permission_profile, profile version, special_access_requested[], external account IDs |
| Approval | approval_owner, approval_owner_email, approval_status, approval_timestamp, approval_reference, approved package version |
| Expiration | access_expiration_date, timezone, extension approval reference |
| Operations | request_id, workflow_type, request_source, submitted_by, created_at, last_updated_at, workflow_status, run and workflow versions |
Store separate per-system execution and verification results. A single success flag cannot represent a partially provisioned identity or an application that failed revocation.
| Lifecycle | States |
|---|---|
| Employee provisioning | REQUESTED, VALIDATING, PENDING_APPROVAL, APPROVED, PROVISIONING, PARTIALLY_PROVISIONED, PROVISIONED, PROVISIONING_FAILED |
| Contractor access | REQUESTED, PENDING_INFORMATION, PENDING_APPROVAL, APPROVED, ACTIVE, EXPIRING, EXPIRED, REVOKED |
| Offboarding | SCHEDULED, REVOCATION_STARTED, IDENTITY_DISABLED, ACCESS_REMOVAL_IN_PROGRESS, REVOCATION_EXCEPTION, OFFBOARDING_COMPLETE |
| Exceptions | BLOCKED_MISSING_INFORMATION, BLOCKED_DUPLICATE_IDENTITY, manual review with a recorded reason |
EXPIRED describes the access deadline passing; REVOKED requires verified removal. An expired contractor can still be a revocation exception if an application remains accessible.
Role profiles, access levels, and approval ownership
Maintain permission profiles centrally instead of repeating application-specific rules inside every workflow. Resolve profiles from role, department, employment type, and applicable entity. For example, ROLE_SALES_STANDARD could include standard email, collaboration, CRM, knowledge-base, and meeting access. The profile specifies the exact permission in each system, not just the application name.
| Access level | Example scope | Approval requirement |
|---|---|---|
| Level 1: Basic | Email, calendar, collaboration, knowledge base | Valid standard-access authorization under company policy |
| Level 2: Functional | CRM, CMS, analytics, project management | Role profile and configured owner approval |
| Level 3: Sensitive | Finance, HR, production data, customer exports | Additional approval from accountable owners |
| Level 4: Privileged | Identity administration, cloud administration, security systems | Additional privileged-access approval and security controls |
This classification is an example company model. Resolve the actual risk from data exposure and permission scope; even a collaboration platform can contain sensitive information.
The approval engine calculates the chain from system, permission, employment type, risk, and policy. Do not assume the direct manager can authorize every system. Record all required decisions, validate approver authority, and apply separation-of-duties rules. Required approvals must cover the exact access package and current version before execution.
Workflow 1: Employee IT provisioning
Trigger and load approved employee context
Prefer an authenticated New Employee Approved event from the HRIS. Alternatives include an approved onboarding form, hiring request, webhook, or scheduled lookup for upcoming starters.
Capture employee ID, name, role, department, manager, start date, and requested systems. Generate a stable request ID such as PROV-2026-000147. Load workspace configuration: domain, timezone, provisioning window, default applications, role mappings, approval rules, and notification routes.
Validate the source and required data before retrieving execution credentials or calling target systems. Missing name, employee ID, role, department, manager, or start date sets BLOCKED_MISSING_INFORMATION, creates a remediation task, and notifies HR, the hiring manager, and IT. Create no accounts while blocked.
Validate timing and resolve the existing identity
Reject malformed dates and inactive employee records. A configurable window might prepare accounts three business days before the start date. Store the business calendar and activation time explicitly; a calendar date alone can produce early activation in another timezone.
Search first by stable employee and external identity IDs, then corporate email. Personal email or name plus department may support review but must not be treated as proof of a match.
If an identity exists, classify it as a returning employee, duplicate HR record, pre-created account, or contractor converting to employee. Route uncertain cases to BLOCKED_DUPLICATE_IDENTITY. Do not create another account or reactivate an old one without policy-authorized identity resolution.
Resolve role permissions and additional approvals
Load the versioned permission profile. Sales may need CRM; marketing may need CMS and analytics; engineering may need GitHub and development tools; finance may need approved financial applications.
Standard permissions can rely on the hiring approval only when the policy explicitly authorizes that package. Sensitive and privileged permissions require additional approvals. If an elevated request is rejected, exclude it and continue standard onboarding only when permitted by policy and application dependencies.
Re-fetch employment and request state before execution. A postponed start, canceled hire, or superseded profile must not activate the old access package.
Create the core identity and configure authentication
Create the directory account with the approved username and work email. Use a staged or disabled state until the activation time where supported. Where staging is unavailable, enforce an equivalent activation control and verify it.
Apply company authentication policy: MFA enrollment, first-login setup or password reset where relevant, and conditional access where supported. Track enrollment and enforcement separately. An enrollment instruction sent by email does not prove MFA is active. Never send plaintext passwords or service credentials in email or chat; use the approved secure setup mechanism.
Provision applications and verify the result
Execute application actions individually: email, collaboration, CRM, project management, GitHub, and groups. Persist the external account ID, requested roles, API result, retry state, and verification evidence per target.
Verify that each expected account exists, maps to the correct person, has the approved groups and permissions, and follows activation and authentication policy. Account existence alone does not establish correct access. Allow bounded readback retries for eventual consistency; an accepted API request is not verified success.
| Outcome | Required behavior |
|---|---|
| All required actions verified | Set PROVISIONED and record any separate pending employee setup |
| Partial success | Set PARTIALLY_PROVISIONED, identify missing systems, and create owner-assigned remediation tasks |
| No required provisioning succeeds | Set PROVISIONING_FAILED and escalate to IT |
Send manager and IT a consolidated summary containing role, start date, accounts created, verification results, outstanding tasks, and pending elevated access. Employee communication contains only permitted login and setup instructions. Audit approvals, profile versions, actions, failures, and operator interventions.
Workflow 2: Contractor access request routing
Capture a time-bound access request
Accept requests from an authenticated form, ITSM ticket, approved collaboration workflow, HR, or procurement system. Require contractor identity and company, sponsor, email, project, systems, exact permission levels, business justification, start date, and end date.
Missing information sets PENDING_INFORMATION. An absent or invalid end date blocks provisioning. Require the end to follow the start and remain within the company's maximum access duration.
Search for an existing contractor identity by stable ID and verified email, with vendor and project context. Expired or previously disabled identities require review before reactivation; a familiar email must not bypass authorization.
Resolve applications and route risk-specific approvals
The application registry states the system owner, contractor eligibility, allowed roles, risk, required approvals, and provisioning method. Resolve the requested access against both application and contractor policy.
An illustrative risk router is:
| Risk | Example approval chain |
|---|---|
| Low | Sponsor or manager |
| Medium | Sponsor or manager and system owner |
| High or privileged | Sponsor or manager, system owner, and Security |
Send the complete package: contractor, project, system, permission, justification, and access dates. Approvers authorize those specific entitlements. If approval is missing, no access is granted. A configurable 24–48-hour approval SLA can initiate reminders and then escalation without treating silence as consent.
If ADMIN is requested but contractor policy permits only EDITOR, block automatic execution. An exception needs the authorized policy-exception process; extra approval does not override a non-overridable prohibition.
Assign limited permissions and register expiration
Create or reactivate the reviewed identity with employment_type = CONTRACTOR. Assign only the approved application roles. Do not inherit employee department groups automatically.
Store the exact expiration timestamp and register an independent revocation event. Use native application expiration where available plus an independent monitor so expiration survives a failed original workflow. Verify the actual effective permissions, including inherited grants, against the approved package.
Notify the sponsor, IT, and required system owners with granted systems, roles, and expiration. Audit authorization, policy decisions, execution, verification, and exceptions.
Monitor expiration and approve extensions explicitly
Notify the sponsor seven days before expiration and request extension confirmation three days before, if configured. Revoke at the expiration timestamp unless a valid extension has already been approved. A daily digest can report upcoming expiry, but a daily-only revocation check can leave access active past the deadline; use a scheduler and fallback monitor that meet the stated revocation SLA.
An extension must record the new access package, end time, approvers, and version. Do not silently extend access because the project remains active or a sponsor has not replied.
Workflow 3: Access revocation on offboarding
Resolve departure type and effective time
Trigger from an authenticated HR termination event, contractor expiration, authorized immediate revocation request, or security incident process. Load the complete identity and discover applications, groups, licenses, privileged roles, user token references, and active sessions where available.
| Event | Route |
|---|---|
| Standard departure | Revoke at the authorized effective departure time |
| Contractor expiry | Revoke at the approved expiration timestamp |
| Immediate termination | Execute the authorized immediate revocation path without normal waiting periods |
| Internal role transfer | Reassess permissions; retain the identity and remove obsolete access |
Approval of onboarding and approval of termination are separate authorities. An authorized urgent revocation must not wait for an ordinary new-access approval queue.
Disable authentication and remove downstream access
At the effective time, disable the primary identity and revoke active sessions and applicable authentication artifacts, such as app passwords and user tokens, using supported controls. Disabling the identity provider alone may not invalidate every application's session or local password.
Remove SaaS accounts or access, CRM roles, GitHub organization membership, CMS access, cloud roles, VPN access, and project management permissions according to the application's revocation method. Include direct grants, inherited groups, local accounts, and independently issued credentials in the removal inventory.
Review privileged access and shared credentials
Search for administration roles, production and cloud access, SSH keys, deployment credentials, service-account ownership, and shared secrets the person could access.
Remove individual grants and revoke user-bound keys. Rotate exposed shared credentials through the approved dependency-aware process, with accountable service owners and verification, so remaining services receive the replacement credentials. Do not indiscriminately delete shared service identities used by other systems. A failed privileged revocation requires immediate Security escalation.
Transfer ownership and reclaim licenses
Before destructive account deletion, transfer company assets such as documents, storage, dashboards, CRM records, repositories, and project boards to an approved owner or archive account. Transfer must not delay urgent access disabling; use an administrative transfer mechanism where possible.
Apply company retention and preservation requirements before deletion or license removal. Reclaim licenses only when doing so will not remove required retained data or block the handover. Record verified reclaimed seats and estimated cost recovery separately.
Verify every removal and handle exceptions
Read back account state, membership, effective permissions, session revocation results, and privileged entitlements using the registry's verification method. Confirm removal in every required target, with timestamps and evidence. An API success response alone is insufficient.
Only verified removal across the required inventory permits OFFBOARDING_COMPLETE. Unsupported verification or a remaining active account records REVOCATION_EXCEPTION with the unresolved risk and accountable owner.
Retry failed operations within bounded limits, for example three attempts with controlled backoff. Create a critical IT ticket containing identity, system, requested removal, sanitized error, and latest verification state when removal cannot be confirmed. Escalate privileged failures to Security immediately rather than waiting for retries to finish.
Audit the initiating source, effective departure time, identity disable time, session and application removals, privileged actions, ownership transfers, license recovery, failed actions, and resolution status. Notify HR, the manager, and accountable IT owners with a verified summary.
Application and permission registries
| Registry | Suggested fields |
|---|---|
| Application | application_id, name, category, system owner, risk, contractor eligibility, default role, maximum contractor role |
| Integration | Required approvals, provisioning method, revocation method, verification method, session controls, connector capability limits |
| Permission profile | Profile ID and version, employment type, role, department, exact application permissions, sensitive-access conditions |
For example, ROLE_MARKETING_STANDARD may resolve to Microsoft 365 standard access, Slack member, HubSpot marketing user, analytics viewer, and CMS editor. These are illustrative mappings to review against company policy. Registry changes should create a traceable version and reconciliation decision, not silently rewrite active approvals.
Periodic access reconciliation
Run a weekly or monthly access review, with more frequent checks for high-risk or temporary access where required. Fetch active identities and actual application permissions, resolve expected access from current employment and approved exceptions, and compare effective grants.
Expected = actual → Record verified match
Excess access → Authorized removal or owner review
Missing access → Revalidate policy and approvals before adding
Expired or inactive identity → Revocation and verification
Ambiguous identity → Manual resolution
Look for former employees still active, expired contractors, unexpected administrators, missing required access, duplicate identities, and orphaned accounts. Discover application access beyond the last provisioning run; untracked grants must not escape offboarding merely because the automation did not create them.
Reliability and lifecycle exceptions
| Exception | Required handling |
|---|---|
| Missing approval | Block access execution, notify its owner, and audit the attempt |
| Duplicate or ambiguous identity | Manual identity resolution; no automatic second account |
| Start date postponed | Delay activation and re-check already assigned access |
| Employee never starts | Disable staged access and reclaim licenses through policy |
| Department or role changes | Recalculate expected permissions and approve new sensitive access |
| Contractor becomes employee | Convert the reviewed identity instead of leaving two active accounts |
| Manager changes | Reassign pending approval ownership under policy |
| Application API unavailable | Queue the same operation with bounded retry and an owner |
| Company retires a system | Update its registry and complete any required revocation or migration |
Use durable event and per-action idempotency keys, external IDs, and atomic identity creation guards. Reconcile uncertain API results before retrying creation. Serialize competing lifecycle changes per identity or use version checks so an old provisioning run cannot restore access after a newer departure event.
An immediate revocation takes precedence over pending provisioning. Cancel obsolete scheduled actions and re-fetch current employment, approval, and lifecycle state before changes. Track partial progress so retrying one failed application does not recreate accounts elsewhere.
Vault, audit, and notification architecture
Fetch short-lived or scoped integration credentials from the encrypted platform store or a vault such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or 1Password Secrets Automation where supported. Never embed passwords, API keys, OAuth tokens, or database credentials in workflow definitions, audit records, approval forms, or chat notifications.
Use narrowly scoped service identities and validate incoming event authenticity. Keep audit data in an append-only or tamper-resistant store with explicit access and retention controls. Record identity and token references rather than secret values.
An audit event includes audit_id, request_id, workflow_type, user_id, event type, system, action, previous state, requested state, actual state, approval reference, execution time, result, sanitized error code, workflow run, and policy version. Failed and blocked actions need records as well as successful changes.
Notify people at meaningful milestones. Managers receive approval requests, completion summaries, and expiry warnings. IT receives duplicate identities, partial provisioning, API failures, and revocation exceptions. Security receives privileged requests, policy violations, and failed privileged removals. HR receives employee-data blocks, canceled onboarding, and verified offboarding outcomes.
Dashboard and success metrics
Show pending onboarding, contractor approvals, scheduled departures, missing approvals, duplicates, provisioning failures, and revocation exceptions. Include temporary access, privileged accounts, expired accounts still active, policy exceptions, and verified recovered licenses.
Measure provisioning time, readiness before start date, failed actions, manual interventions, duplicate identities prevented, contractors nearing expiry, expired access still active, mean revocation time, SLA breaches, privileged removal failures, excessive permissions, and orphaned accounts. Separate the time to disable primary authentication from the time to verify all downstream removals.
Implementation checklist
- Identify authoritative employment records and trusted event sources.
- Build versioned identity, application, permission, approval, and audit registries.
- Define activation windows, risk levels, approver authority, expiry timestamps, and revocation SLAs.
- Implement employee validation, identity resolution, staged provisioning, and effective-permission verification.
- Implement contractor-specific approvals, least-privilege assignment, and independent expiration enforcement.
- Build offboarding with immediate authentication controls, downstream removal, privileged review, handover, and verification.
- Add idempotency, conflict handling, bounded retries, remediation queues, and recurring reconciliation.
- Test missing approval, ambiguous identity, canceled hire, start-date changes, contractor extension, partial API failure, surviving sessions, inherited privileges, simultaneous provisioning and departure, and failed revocation.
Begin with a small approved application set. Document manual verification paths for systems that cannot yet expose their actual permissions through an API, and retain explicit exceptions until an accountable reviewer confirms resolution.
Frequently asked questions
Is employee onboarding approval enough for privileged access?
No. Standard role access can use an existing hiring authorization only when company policy permits it. Sensitive and privileged access require the additional approvals specified for those permissions.
Can contractor access be granted without an end date?
Not in this blueprint. A valid end date and explicit access package are mandatory. Extensions require new authorization and an updated expiration record.
Does disabling the identity provider remove all application access?
Not necessarily. Applications may retain independent sessions, local credentials, or direct grants. The workflow removes and verifies access in each required target system.
What happens if provisioning succeeds in only some systems?
Record PARTIALLY_PROVISIONED, retain verified per-system results, and create remediation tasks. Retry only failed operations against the existing identity.
What happens if access removal cannot be confirmed?
Keep REVOCATION_EXCEPTION, retry within the configured limits, and escalate with the unresolved system and evidence. Privileged failures alert Security immediately. Do not report offboarding complete while required removal remains unverified.
How are internal role transfers handled?
Retain the identity, compare actual permissions with the new approved profile, remove obsolete access, and authorize required additions. A role transfer is access reconciliation rather than full account deletion.
Related automation blueprints
Connect identity onboarding to the internal operations request and compliance blueprint for equipment requests and policy acknowledgments. Use the commercial-to-delivery handoff blueprint to resolve project ownership and context without bypassing access approval.
Explore the automation blueprint library, browse workflow templates, or request an implementation consultation to adapt this lifecycle to your company's applications and policies.