Summary and recommendation
Workday user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Workday is the system of record for HR data in most enterprise environments, meaning it drives identity and access for every app downstream - not just its own UI.
User accounts are a byproduct of HR business processes: employees are created via the Hire workflow, not a standalone user-creation screen.
Access is controlled through a layered security group model combining role-based, user-based, and intersection groups tied to domain and business process policies.
Quick facts
| Admin console path | Workday Home → Search 'Maintain Workday Accounts' or navigate via Menu → Security Administration |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| System Administrator (ISU / Integration System User) | Full administrative access to tenant configuration, security policy management, business process setup, and integration management. Can create and assign all security groups. | Cannot bypass audit logging; all actions are tracked. Cannot self-approve certain business processes if approval chains are configured. | ISU accounts are non-human service accounts used for integrations; they require their own security group assignments and should not be used for human administrator access. | ||
| HR Administrator / HR Partner | Can initiate and complete HR business processes (hire, terminate, change job), manage worker data within their supervisory organization scope, and run HR reports. | Cannot modify tenant-level security policies or domain security configurations without additional security group membership. | Access is scoped by supervisory organization hierarchy; an HR Partner only sees workers in their assigned organizations unless additional role-based access is granted. | ||
| Manager (Self-Service) | Can view and take actions on direct reports (approve time off, initiate job changes, view team data) within their supervisory organization. | Cannot access workers outside their direct reporting chain. Cannot modify security configurations. | Manager access is dynamically assigned based on the supervisory organization structure in Workday, not manually granted per user. | ||
| Employee (Self-Service) | Can view and update personal information, submit time-off requests, view pay slips, enroll in benefits, and complete assigned tasks. | Cannot view other workers' data. Cannot initiate administrative business processes. | Employee self-service access is automatically provisioned when a worker record is created via the Hire business process. | ||
| Workday-Owned Security Group Member (e.g., Payroll Administrator, Benefits Administrator) | Pre-built role with domain and business process security policies scoped to a functional area (payroll, benefits, recruiting, etc.). | Workday-owned security groups cannot be modified by tenant administrators; only tenant-created copies can be customized. | Workday periodically updates Workday-owned security groups during weekly service updates; tenant admins must review release notes to understand permission changes. |
Permission model
- Model type: hybrid
- Description: Workday uses a security group model combining role-based access (Role-Based Security Groups tied to positions or job profiles), user-based groups (User-Based Security Groups for named individuals), and intersection security groups (combining role and user membership). Permissions are granted by assigning security groups to Domain Security Policies and Business Process Security Policies. Tenant administrators can create custom security groups and policies.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Domain-level (controls access to data domains such as 'Worker Data: Personal Information') and Business Process step-level (controls who can initiate, approve, or view each step of a business process). Segmented Security Groups can further restrict access to subsets of workers (e.g., by location or pay group).
How to add users
- To create a worker-linked account: Initiate the 'Hire' business process via Search > 'Hire Employee' or 'Hire Contingent Worker'. Complete all required staffing and personal data fields. Upon completion, Workday automatically creates a Workday account for the worker.
- To create a standalone (non-worker) account: Search for 'Create Workday Account' task. Enter the account name, password settings, and assign applicable security groups.
- Assign the user to the appropriate security groups: Search 'Maintain User-Based Security Group' or edit the relevant Role-Based Security Group to include the new worker's position.
- Activate the account if it was created in an inactive state: Search 'Maintain Workday Accounts', locate the user, and set account status to Active.
- Notify the user of their login credentials or configure SSO so they authenticate via the identity provider.
Required fields: Legal first and last name, Hire date, Worker type (Employee or Contingent Worker), Position or job profile, Supervisory organization, Primary work location, Account username (for standalone accounts)
Watch out for:
- Worker accounts are created as a byproduct of the Hire business process; there is no standalone 'create user' button for employees - the HR record must exist first.
- The Hire business process may require multiple approvals before the account is active, depending on tenant configuration.
- Security group membership for role-based groups is driven by the worker's position/job profile, not manually assigned per user - changing access requires changing the position or the security group policy.
- SSO configuration must be completed at the tenant level before users can authenticate via an identity provider; individual user SSO cannot be toggled independently.
- Workday usernames must be unique across the tenant and cannot be reused after a worker is terminated.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | Workday supports bulk hire via EIB (Enterprise Interface Builder): Search 'Load Data' or 'Create EIB' > select 'Worker' template > upload spreadsheet. Also available via PECI/PICOF integration for payroll providers. |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (requires SSO configuration; Workday supports inbound provisioning via SCIM for Strategic Sourcing module; for core HCM, Workday typically acts as the authoritative source pushing to downstream apps rather than receiving provisioning from an IdP) |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: Workday does not delete worker records or Workday accounts. Terminating a worker via the 'Terminate Employee' business process deactivates their Workday account and removes active security group memberships, but the worker record and all associated historical data are retained permanently for audit and reporting purposes. Standalone (non-worker) accounts can be deactivated via 'Maintain Workday Accounts' but are not deleted.
- To terminate a worker: Search 'Terminate Employee' (or 'End Contingent Worker Contract'). Select the worker.
- Enter the termination date, reason code, and any required details (e.g., regrettable/non-regrettable, eligible for rehire).
- Complete any required approval steps in the Terminate business process chain.
- Upon business process completion, Workday automatically deactivates the worker's Workday account on the termination date.
- To immediately deactivate a standalone account: Search 'Maintain Workday Accounts', locate the account, edit and set status to 'Inactive'.
| Data impact | Behavior |
|---|---|
| Owned records | All worker data, transactions, and history are retained indefinitely in the Workday tenant after termination. The worker record moves to 'Terminated' status but remains fully accessible to authorized administrators. |
| Shared content | Reports, dashboards, and custom objects created by the terminated worker remain in the system. Ownership transfer is not an automatic process; administrators must manually reassign or archive as needed. |
| Integrations | Active integrations (e.g., payroll, benefits) that reference the worker will receive termination event data on the next integration run. ISU/service account deactivation must be handled separately and will break any integrations using that account. |
| License freed | Workday pricing is based on total employee headcount under contract, not concurrent active users. Terminating a worker does not automatically reduce the contracted seat count; license adjustments are handled at contract renewal or via a formal amendment with Workday. |
Watch out for:
- The termination date in Workday controls when the account is deactivated; if a future date is entered, the worker retains access until that date.
- Terminated workers can be rehired; their historical record is preserved and linked to the new hire event.
- Deactivating an ISU (Integration System User) account will immediately break all integrations using that account's credentials - coordinate with integration owners before deactivating.
- Security group memberships tied to the worker's position are removed upon termination, but any manually added User-Based Security Group memberships may need to be removed separately depending on tenant configuration.
- Workday does not send automatic notifications to the terminated worker or their manager when account access is revoked - this must be handled via a separate offboarding process.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Full Platform User (HCM, Financials, etc.) | Access to all licensed Workday modules for that worker (HCM, Payroll, Financials, Planning, etc.) based on contracted modules. | Custom enterprise pricing; typically quoted as a per-employee-per-year rate ($100–$200/employee/year range based on market data, subject to contract). |
| Limited User / Self-Service User | Employee and manager self-service capabilities only (personal data, time off, benefits, pay). No administrative or configuration access. | Typically included in the per-employee headcount pricing; not separately itemized in most contracts. |
- Where to check usage: Search 'Workday Account Usage' report or navigate to Security Administration > Workday Accounts to view active account counts and last login data. Tenant administrators can also run the 'All Workday Accounts' report.
- How to identify unused seats: Run the 'Workday Account Usage' or 'User Activity' audit report filtered by last login date to identify accounts with no recent activity. Workday does not have a built-in automated unused-seat alert; this requires manual report review or a custom scheduled report.
- Billing notes: Workday licenses are sold on an annual subscription basis with pricing based on total employee headcount at contract signing, not active users. Module-based pricing means each functional area (HCM, Payroll, Financials, Recruiting, etc.) is licensed separately. Headcount-based pricing means terminated workers do not reduce the current contract cost; adjustments occur at renewal. All pricing requires a direct quote from Workday sales.
The cost of manual management
Workday licenses are priced on total employee headcount at contract signing, not active users. That means terminated employees do not reduce your current contract cost - adjustments happen only at renewal. Each functional module (HCM, Payroll, Financials, Recruiting) is licensed separately, so your actual spend depends on which modules are active across your org.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Workday is the right choice as an HR source of truth when you need a single authoritative record that propagates identity changes to every app in your stack. The business process model enforces approval chains and audit trails by design, which is an advantage in regulated environments.
The tradeoff is operational overhead. Ad-hoc access grants are difficult because role-based security is tied to position and job profile structures, not individual users. If your team lacks dedicated Workday security expertise, plan for a meaningful ramp-up period before the permission model is under confident control.
Bottom line
Workday's value as an identity source scales with how consistently it is kept current - stale org structures or delayed terminations create access gaps across every app that depends on it.
The security group model is powerful but unforgiving: misconfigured domain policies or overlooked User-Based Security Group memberships after termination are the most common sources of over-provisioned access.
Organizations that invest in clean supervisory org hierarchies and scheduled account-usage report reviews get the most reliable access hygiene from the platform.
Automate Workday workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
