Ceridian Dayforce User Management Guide

• Model type: role-based
• Description: Dayforce uses a role-based access control (RBAC) model called Security Roles. Each Security Role is a named collection of feature-level entitlements (read, write, execute) across Dayforce modules. Users are assigned one or more Security Roles. Roles can be scoped by org unit, pay group, or other dimensions to restrict data visibility. Administrators can create custom Security Roles by selecting specific entitlements from a granular list of features within each module.
• Custom roles: Yes
• Custom roles plan: Available on all Dayforce HCM plans; configuration is done by the customer's system administrator or Dayforce implementation consultant.
• Granularity: Feature-level entitlements within each module (e.g., view payroll, edit schedules, approve time-off). Entitlements can be further scoped by organizational hierarchy, pay group, and employment type.

1. Navigate to Main Menu > System Admin > Security > Users.
2. Click 'Add' to create a new user record.
3. Enter required fields: Username, Employee link (if applicable), and assign at least one Security Role.
4. Set authentication method (Dayforce native login or SSO/SAML).
5. Configure org unit access and any additional role scoping.
6. Save the user record; the user receives an activation email if native authentication is used.

Required fields: Username, Security Role (at least one), Authentication type (native or SSO), Employee record link (required for employee-type users)

Watch out for:

• Users must be linked to an active employee record to access employee-facing features; system-only admin accounts may not require an employee link.
• SSO users must have their username match the identity provider's NameID/email attribute exactly; mismatches cause login failures.
• Security Roles must be configured before user creation; assigning an incomplete role can result in users seeing blank screens or access errors.
• New users created outside of the HR hire workflow may not automatically inherit the correct org unit scoping.

• Can delete users: No
• Delete/deactivate behavior: Dayforce does not support permanent deletion of user or employee records due to payroll audit trail and compliance requirements. Users are deactivated (terminated in the HR record or disabled in the security user record), which removes login access while preserving all historical data. The user record and associated transactions remain in the system for reporting and audit purposes.

1. To disable login access only: Navigate to Main Menu > System Admin > Security > Users, locate the user, and set their status to Inactive or remove all Security Role assignments.
2. To fully terminate an employee: Process a termination action through Main Menu > HR > Employee > Employment > Termination, entering the termination date and reason.
3. Verify the employee's Dayforce login is disabled by confirming the user record status is Inactive.
4. If SSO is in use, also disable or deprovision the user in the identity provider to prevent JIT re-provisioning on next login attempt.

Watch out for:

• Deactivating the security user record alone does not process a termination in the HR system; both actions may be required depending on the use case.
• If SSO/JIT provisioning is active, a deactivated Dayforce user can be re-activated automatically if the IdP session is still valid and JIT is not blocked at the IdP level.
• Rehired employees require careful handling; creating a duplicate employee record instead of reactivating the original causes data integrity issues.
• Payroll must be finalized for the termination period before the employee record is fully closed; open pay periods can block termination processing.

• Where to check usage: Active employee headcount can be reviewed via Main Menu > HR > Reports or through the Dayforce Analytics module. Specific license usage reporting is typically reviewed with a Dayforce account manager or via the customer portal.
• How to identify unused seats: Administrators can run user activity reports or audit login history via Main Menu > System Admin > Security > User Audit to identify accounts with no recent login activity. Dayforce does not provide a native 'unused license' dashboard; this requires custom reporting.
• Billing notes: Dayforce pricing is per-employee-per-month (PEPM) based on active headcount. Implementation fees are typically 50–60% of first-year software costs and are billed separately. Module-specific licensing (e.g., adding WFM or Benefits) is negotiated at contract level. Billing adjustments for headcount changes are typically reconciled monthly or quarterly per contract terms.

Manual administration in Dayforce is high-friction by design. Creating a user requires pre-configured Security Roles, a linked employee record, and correct org unit scoping-any gap produces blank screens or access errors rather than a clear failure message.

Offboarding requires two separate actions: disabling the security user record and processing an HR termination. Skipping either step leaves partial access in place.

If SSO with JIT provisioning is active, a deactivated Dayforce account can be silently re-activated on the next IdP login-meaning every app downstream may regain access to an employee who has been terminated.

Dayforce provides no native inactive-user or unused-license dashboard. Identifying dormant accounts requires building custom reports against login audit logs, adding recurring administrative overhead with no guaranteed cadence.

Practitioners consistently flag SSO configuration as the highest-friction area: SAML assertion requirements are complex, self-service documentation is limited, and most organizations require Dayforce support or an implementation consultant to complete the setup.

Security Role configuration is a recurring pain point. Out-of-box roles rarely match organizational needs, and the entitlement list is granular enough that misconfiguration is common-resulting in users seeing blank module screens or inadvertently accessing records outside their org unit.

The absence of SCIM is the most structurally significant gap. Teams using Okta, Entra ID, or OneLogin for provisioning must bridge to Dayforce's proprietary REST API via middleware (e.g., Okta Workflows, MuleSoft), which adds implementation cost and ongoing maintenance.

Common complaints:

• Complex SAML assertion requirements make SSO configuration difficult without Dayforce support involvement.
• Requires Dayforce support team or implementation consultant for SSO and IdP configuration; self-service documentation is limited.
• Not natively supported in Azure AD (Entra ID) HR-driven provisioning; SCIM is not available, requiring custom API or manual workflows.
• Security Role configuration is complex and time-consuming; out-of-box roles often require significant customization.
• JIT provisioning via SAML can inadvertently re-activate deactivated users if the IdP is not also updated.
• No native 'unused license' or inactive user dashboard; identifying dormant accounts requires custom report building.
• Bulk user management via import templates is not well-documented and often requires consultant assistance.
• Termination workflows require coordination between the HR record and the security user record; missing one step leaves login access open.
• Role entitlement lists are extensive and poorly documented, making it difficult to audit what a given Security Role actually permits.

Dayforce is appropriate for organizations that have already committed to the platform as their system of record for HR and payroll and need to manage access within its native RBAC model. It is not a fit for teams expecting plug-and-play IdP provisioning or SCIM-based automation without additional middleware investment.

Key decision factors:

• No native SCIM: every app that needs automated provisioning requires a custom integration or middleware layer.
• SSO requires Enterprise tier and support involvement; budget for implementation time.
• JIT re-provisioning risk is real and must be mitigated at the IdP level, not in Dayforce.
• Security Role design should be completed before any user creation begins; retrofitting roles to existing users is time-consuming.

Bottom line

Dayforce gives enterprise HR teams a deeply configurable RBAC model and a single system of record for the full employee lifecycle, but it trades ease of administration for that depth.

There is no SCIM, no native inactive-user dashboard, and no automated bridge to IdP provisioning-meaning every app connected to your identity stack requires deliberate, manual coordination with Dayforce's HR and security workflows.

Organizations that invest in role design upfront and establish clear offboarding runbooks (covering both the security user record and the HR termination action) will get reliable access control; those that don't will accumulate access drift and audit risk over time.