FAQ: Single Sign-On (SSO) in Contract Management and Document Intelligence

Can an administrator set a default single sign-on (SSO) role for all users and pass through specific role attributes for individual users?
What happens when a user is manually deactivated in Contract Management and Document Intelligence but is still active through SSO?
Does mapping the Department attribute through SSO create departments in Contract Management and Document Intelligence?
Can an administrator edit user attributes that were mapped through SSO (example: Job Title, Role, or Department)?
When a user's SSO access to Contract Management and Document Intelligence is removed through their identity provider (IdP), is that user account also automatically deactivated in Contract Management and Document Intelligence?
Can 1 client support multiple concurrent SSO configurations?
When a user is manually added and then deleted, does Contract Management and Document Intelligence provision them on their first login?
When and what does Contract Management and Document Intelligence provision when a user first logs in?
Does Contract Management and Document Intelligence support Single Logout through SSO?

Can an administrator set a default single sign-on (SSO) role for all users and pass through specific role attributes for individual users?

Yes, this is possible using the Integrated User Provisioning (Advanced SSO) feature included in Advanced Administration.

When you map the Role attribute at the client level and pass through a role attribute value at the user level, the user's role attribute value overrides the default SSO role.

When you map the Role attribute at the client level but don’t pass through a value at the user level, the user is reassigned to the default SSO role the next time they log in. This applies to both new and existing users.

When you map the Role attribute at the client level but don’t pass through a value at the user level and don’t configure a default SSO role, all users are reassigned to the Power User role on their next login.

When you don’t map the Role attribute at the client level, all existing users maintain their current role when logging in through SSO.

What happens when a user is manually deactivated in Contract Management and Document Intelligence but is still active through SSO?

When you manually deactivate a user in Contract Management and Document Intelligence and they still have access through their IdP, they can still log in using the URL, which creates a new user in the instance. When you manually deactivate a user account in Contract Management and Document Intelligence, we recommend that you also revoke their access to the app in the IdP.

Does mapping the Department attribute through SSO create departments in Contract Management and Document Intelligence?

Mapping the Department attribute through SSO doesn't automatically create departments. Users leveraging the Integrated User Provisioning (Advanced SSO) feature need to manually create the same departments directly in Contract Management and Document Intelligence so that there's an exact match between the value being passed through and the value in Contract Management and Document Intelligence.

Can an administrator edit user attributes that were mapped through SSO (example: Job Title, Role, or Department)?

Yes, an administrator can manually edit user attributes directly in Contract Management and Document Intelligence.

If these attributes are mapped through the Advanced SSO configuration, any manual updates made in Contract Management and Document Intelligence are automatically overwritten the next time the modified user logs in. This ensures that the customer's IdP remains the primary data source.

When a user's SSO access to Contract Management and Document Intelligence is removed through their identity provider (IdP), is that user account also automatically deactivated in Contract Management and Document Intelligence?

No, the user account remains active until it's manually deactivated in Contract Management and Document Intelligence by an administrator. However, they won't be able to log in if that SSO is enforced for all users.

Can 1 client support multiple concurrent SSO configurations?

A single client can't support multiple SSO configurations at one time. However, it is possible to configure multiple active directories to the same IdP (example: Azure AD multitenant clients to Okta) and then configure a single SSO integration through Okta.

When a user is manually added and then deleted, does Contract Management and Document Intelligence provision them on their first login?

No. If a user tries to log in through SSO for the first time and they receive a login error, they were most likely added and then deleted in the workspace. We don't provision a user when they were deleted from the system through SSO; in this case, an administrator needs to add them to Contract Management and Document Intelligence.

When and what does Contract Management and Document Intelligence provision when a user first logs in?

When a user first logs in to Contract Management and Document Intelligence, our SSO integration fetches user data only: email, first name, and last name. However, using the Integrated User Provisioning (Advanced SSO) feature included in Advanced Administration, Contract Management and Document Intelligence retrieves user data on every login and updates attributes (such as Role or Department) as modified in the IdP.

Does Contract Management and Document Intelligence support Single Logout through SSO?

We don't currently support Single Logout through SSO.

Mutiple Departments in SSO Configuration

After changing my SSO configuration to support department synchronization, users can't sign in. How do I fix this?

Ensure that the custom attribute mapping in your Identity Provider is correct. We still require first name, last name, and email claims to be sent with the department.
Secondly, check that the department names in your Identity Provider match exactly as they are spelled in Contract Management and Document Intelligence.
If the issue persists, send the specific error message to Workday Support to receive additional troubleshooting guidance.

Which Identity Providers (IdP) support multiple departments?

This feature is supported by any SAML 2.0-compliant Identity Provider capable of sending a comma-separated string array. Azure, Okta, and Ping Identity all support this array format.

Are departments in Contract Management and Document Intelligence always overwritten with the values from the IdP?

Yes. When departments are explicitly mapped in the SSO configuration, the Identity Provider always serves as the source of truth.

This table illustrates the synchronization behavior for different values received from the IdP, assuming all departments exist in Contract Management and Document Intelligence.

Field Value in IdP	Is this supported?	What happens in Contract Management?
"Department 1"	Yes. This is our current behavior for a single department, maintained for backwards compatibility.	The user signs in. Workday assigns the user to Department 1.
""	Yes. This is our current behavior for a single department, maintained for backwards compatibility.	The user signs in. Workday removes the user from all departments because the string is empty.
["Department 1", "Department 2"]	Yes. This is the new format we support.	The user signs in. Workday assigns the user to Department 1 and Department 2.
["Department 1"]	Yes. This is the new format we support.	The user signs in. Workday assigns the user to Department 1.
[]	Yes. This is the new format we support.	The user signs in. Workday removes the user from all departments because the string array is empty.
Any other format not provided above	No. This is not using the correct syntax.	The user can't sign in.