Bulk User Offboarding
Design a protected administrator flow for removing many departing users while transferring ownership and preserving required records.
The brief
Understand the problem
Background
A restructuring or vendor change may require dozens of account removals. Disabling login is only one step because files, approvals, API credentials, legal holds, and shared ownership may remain.
User context
Administrator Howard must offboard forty contractors on Friday. Five own active projects, two are under legal hold, and several service credentials are linked to personal accounts.
Product problem
Bulk offboarding needs to expose user-specific dependencies and exceptions before an irreversible action affects business continuity or retention duties.
Objective
Create user selection, dependency review, per-user resolution, scheduled execution, and outcome reporting for a bulk offboarding event.
What to design
Define the experience
Required experience
- Import or select the exact user cohort
- Review access, ownership, credentials, and preservation dependencies
- Resolve exceptions with per-user actions
- Schedule execution and verify every outcome
Screens and states
- Offboarding cohort
- Dependency matrix
- Exception resolution
- Execution report
Core user flow
Follow the critical path
- 01
Howard imports the forty contractor identifiers and reviews matches
- 02
The matrix flags project owners, personal credentials, and legal holds
- 03
He assigns replacement owners and preserves held records
- 04
At the scheduled time accounts disable and three exceptions remain visibly unresolved
Product rules
Requirements and constraints
Requirements
- Provide a reversible cohort preview before any changes
- Separate account disablement, access removal, ownership transfer, credential rotation, and data disposition
- Require explicit handling for each blocking dependency
- Produce item-level outcomes and a retry path
Constraints
- Legal holds override normal deletion
- The administrator cannot transfer resources they cannot access
- Bulk execution must be idempotent
Reality check
States worth considering
Ready-to-use content
Mock data
Use this content to test hierarchy and realistic data states. You can expand it when the concept needs more depth.
Cohort summary
- 40 matched users
- 5 resource owners
- 2 legal holds
- 7 personal credentials
- 3 unresolved blockers
Finish line
What to deliver
- Four desktop screens with dependency and partial-failure states
Optional direction
Visual resources
Use these as a starting constraint if you want one. They are not part of the required solution.