SCIM integration with Okta allows administrators to manage Document360 users and groups directly from Okta in an automated and centrally controlled manner.
When a new user is added in Okta, their Document360 account is provisioned automatically. Any updates to their role or group membership are synced in real time, and when a user is deactivated or removed in Okta, the same is reflected in Document360 without any manual intervention. This eliminates the need for separate account management in Document360 and ensures that user data remains accurate and up to date across both platforms.
Assign User attribute mapping
In the Okta Admin Console, expand the Applications dropdown and select Applications.
Select the application you want to configure and navigate to the Provisioning tab.
Scroll down to Attribute Mappings and click Go to Profile Editor.
Under the Attributes section, click Add Attribute and fill in the details as specified in the table below.
Add Attribute | Value |
|---|---|
Data type | boolean |
Display name | Team Account |
Variable name | isTeamAccount |
External name | isTeamAccount |
External namespace | urn:ietf:params:scim:schemas:extension:document360:2.0:User |
.png)
Once done, click Save.
Best practices for Attribute mapping
When configuring the isTeamAccount attribute in your Identity Provider (IdP), always set it at the User level, not the Group level.
If the attribute is set at the group level, users who belong to multiple groups with different values may get incorrect roles in Document360. For example, one group may set isTeamAccount to True while another sets it to False, creating a conflict during provisioning.
Setting the attribute at the user level ensures each user has one clear value, making SCIM provisioning more reliable and consistent.
Using Expression builder to map roles
Instead of manually setting the isTeamAccount attribute for each user, you can use Okta's Expression Builder to automatically determine whether a user is provisioned as a User or Reader in Document360, based on an existing attribute in their Okta profile, such as Job Title, Department, or any other attribute common across your users.
How it works
The expression evaluates each user's Okta profile attribute and returns True or False, which maps directly to their role in Document360:
isTeamAccount=True→ provisioned as a User.isTeamAccount=False→ provisioned as a Reader.
Once provisioned, users are automatically added to the respective User groups or Reader groups in Document360.
Steps to configure
In the Okta Admin Console, go to Applications and select your SCIM application.
Navigate to the Provisioning tab and click To App tab under Settings.
Scroll down to Attribute Mappings and click the Edit icon next to the
isTeamAccountattribute.
In the dialog, set the Attribute value dropdown to Expression.
Enter your expression in the text box provided.
To verify the expression, enter a user's name in the Preview field. The result is instantly evaluated and displayed in the green bar below the text box, showing whether the user will be provisioned as a User (
true) or a Reader (false) based on the expression.Under Apply on, select Create or Create and update depending on whether you want the expression applied only during user creation or on updates as well.
Click Save.
NOTE
Click Expression Language Reference below the expression box to explore all available functions, operators, and syntax supported in Okta's expression language. For more information, refer to Okta's Expression Language overview guide.
Example
Suppose your organization wants to provision users as Users or Readers based on their Job Title or Group membership in Okta. You can use either of the following expressions depending on what best fits your setup.
Based on Job Title
If your users have a Job Title attribute in their Okta profile, you can map roles based on their title:
user.title == "Manager" || user.title == "Senior Manager" || user.title == "Team Lead" ? "True" : "False"Users with the title: Manager, Senior Manager, or Team Lead are provisioned as Users. All other titles are provisioned as Readers.
NOTE
The attribute variable name (e.g.,
user.title) must match the exact variable name defined in your Okta user profile. You can verify this in Directory > Profile Editor.
Based on Group Membership
If your users are organized into Okta groups, you can map roles based on the groups they belong to:
isMemberOfGroupName("Managers") || isMemberOfGroupName("TeamLead") || isMemberOfGroupName("Directors") ? "True" : "False"Users who are members of the Managers, TeamLead, or Directors groups are provisioned as Users. Users who do not belong to any of these groups are provisioned as Readers.
NOTE
You can combine or extend either expression to include additional job titles or group names based on your organization's needs.
Provision Okta to Document360
To link user creation, changes and deactivating in Okta with Document360,
In the left navigation bar, expand Applications dropdown and click Applications.
Select your SCIM application and navigate to Provisioning tab.
Click Edit under Provisioning to App and select the following checkboxes:
Create Users
Update User Attributes
Deactivate Users
Create a Reader
To add a new reader in Document360 using Okta with SCIM, follow the steps below.
In the Okta Admin Console, expand the Directory dropdown and select People.
On the People page, click Add Person, fill in the required reader details, and click Save. This confirms that the reader has been successfully added to the Identity Provider (Okta).
.png)
Once the Reader is provisioned, Document360 automatically assigns the role based on the rule configured in the Expression Builder.
To integrate the user with Document360, select the newly created reader and click Assign Applications.
In the Assign Application dialog, select the project you want to assign the reader to, then click Assign > Save and Go Back > Done.
.gif)
The newly created reader will be automatically synced with Document360. To verify this, go to Document360 and navigate to Settings > Users & permissions > Readers & groups.
The reader will be added with the default content access that were applied during SSO setup.
Create a User
In the Okta Admin Console, expand the Directory dropdown and select People.
Click Add Person, fill in the required user details, and click Save. Once the User is provisioned, Document360 automatically assigns the role based on the rule configured in the Expression Builder.
Select the newly created user and click Assign Applications to link them to an application.
Choose the application you want to assign the user to and click Apply. The User is successfully created.
To verify, go to Document360 and navigate to Settings > Users & permissions > Users & groups. The newly created user should appear in the list.
NOTE
The number of users you can add to Document360 through Okta depends on your subscription plan.
All users provisioned through SCIM are initially counted under the User quota. If the User limit is reached, SCIM cannot provision additional users, even if some of them are intended to be Reviewers.
Workaround
Provision users from Okta through SCIM as usual. They will sync to Document360 with the default role, such as Contributor or Admin.
After the users are synced, manually change the role of the required users to Reviewer in Document360.
Once a user is changed to Reviewer, they are counted under the Reviewer quota instead of the User quota. This frees up a User slot.
Example: If your project allows 10 Users and 10 Reviewers and you want to add more users through SCIM after reaching the User limit:
First, provision 10 users through SCIM.
Then, change the required users to Reviewers in Document360.
Those users will move to the Reviewer quota, freeing User slots for additional users.
Create group in Okta
To create a group in Okta,
In the Okta Admin Console, expand the Directory dropdown and select Groups.
Click Add Group, enter the desired group name, and click Save.
.png)
Assign application to group
To assign the group to an application,
Expand the Applications dropdown and select Applications.
Select the desired application, navigate to the Assignments tab, and click Assign > Assign to Groups.
Click Assign next to the created group, then click Save to complete the assignment.
Push groups
Unlike users, groups are not automatically synced to Document360 and must be pushed manually. To do that,
After assigning the group to the application, navigate to the Push Groups tab and click Push Groups.
Select Find groups by name and enter the group name.
Select the group from the results and click Save to successfully push the group to Document360.
To verify, navigate to Document360 > Settings > Users & permissions > Readers & groups > Reader groups.
The newly created reader group should appear in your portal.
NOTE
When Okta pushes a group through SCIM, Document360 always creates a new group instead of linking it to an existing group.
This helps prevent issues when the same group is connected to multiple SSO providers.
For example, if one provider removes users from the group, it could accidentally impact users managed by another provider. Creating separate groups avoids this conflict.
Because of this, always manage SCIM groups and group members from Okta, not directly in Document360.
Managing existing users during SCIM provisioning
If a person already has an account in Document360, SCIM will not change their existing role during the first sync. This is a safety measure to prevent accidental role changes.
Example
A user already exists in Document360 as a Reader.
If SCIM tries to provision the same user as a User (isTeamAccount = True), the request may fail because the existing role does not match.
How to Resolve Role Conflicts
Open Document360 and locate the user account.
Manually update the user’s role to match the role you want to provision.
Retry the SCIM sync.
Once the user has been successfully linked and provisioned through SCIM, future role changes can be managed using the isTeamAccount attribute.
Add User/Reader to Group
Once you have created a group, follow the steps below to add readers to the group.
In the Okta Admin Console, expand the Directory dropdown and select People.
Navigate to the Groups tab, search for the group you want to add the user/reader to in the Groups field, and select it.
The user/reader will be successfully added to the selected group.
To confirm, navigate to Document360 and select the relevant user/reader group. The added reader should appear within the group.
NOTE
If a group contains both users and readers, it will appear under both the user groups and reader groups in Document360.
Managing User, Readers and Groups in Document360
When SCIM is enabled, editing a user's name or deleting a user directly in Document360 is disabled, as these actions must be managed through Okta to keep both platforms in sync. You can only manage the content access from Document360.
The SSO-SCIM badge depicts whether the user has SCIM enabled or not.
Manage content access of Readers, Users and Groups
The default content role assigned to any new user, reader, or group is based on what was configured during SCIM provisioning setup. Permissions will be set to None by default but can be updated at any time.
To manage content access, select the desired reader and click Manage Content Access.
Choose the desired access level from the dropdown and click Update.
Deactivate Users/Readers
NOTE
Deactivating a user in Okta does not remove their profile from Document360. The user will be marked as inactive and will lose the ability to sign in to Okta and access their applications. You can reactivate the account at any time, though the user will be required to reset their password upon reactivation.
To deactivate users or readers from Okta,
Expand Directory dropdown, and select People.
Select the user you want to deactivate to navigate to its user profile.
Click More Actions and select Deactivate.
.png)
The user will be deactivated successfully. Once deactivated, the user’s status in Document360 will change from Active to Inactive.
Delete user/reader
To permanently remove a user/ reader profile from Okta,
In Okta, click Delete in the user/reader profile.
A confirmation dialog will appear, click Delete.
.png)
The profile will be permanently deleted from Okta.
NOTE
Deleting a profile in Okta does not remove it from Document360, the profile will remain with an Inactive status.
Inherit from another application
When creating a new SSO configuration in Document360, you can inherit SCIM settings from an existing SSO connection. This approach simplifies the setup process, avoids repeating configuration steps, and helps administrators save time while ensuring consistency across integrations.
Child Inherited SSO configuration
On the Configure Identity Provider (IdP) page, select the Configure an existing connection field and choose the parent SSO SCIM-enabled application you want to inherit from. Selecting this option will designate the current project as the child project, inheriting all relevant properties from the parent.
NOTE
Once the SSO configuration is created, the SCIM provisioning settings will be inherited from the parent application and cannot be modified in the child application.
Parent Inherited SSO Configuration
The parent application will display a list of all projects that have inherited its configuration. Any changes made to the parent application will automatically be reflected in the child application.
If SCIM is enabled in the parent project after child projects have already inherited it, the users and groups will be automatically provisioned to all child projects in the background.
Enabling inheritance makes it easier to manage multiple SSO configurations with SCIM enabled, as all settings are controlled from one parent application. This saves time and reduces the effort required to manage each configuration individually.
Troubleshooting
Sync failed due to a SCIM server error.
When adding new users from Okta, this error indicates that one or more users could not be synced to Document360. This may be caused by:
Duplicate users provisioning
User limit reached based on your current subscription plan
Other validation or processing errors.
Click View details to see which users failed to sync.
User already available in the project
If SCIM returns a "user already available in the project" error, it means the email address is already registered as a User in Document360. If your intent is to convert them to a Reader, follow these steps:
In your IdP, locate the user's profile and navigate to the
isTeamAccountattribute.Set
isTeamAccount = True, this lets the system recognize the existing email as a User.Save the changes and allow the sync to complete. Once synced, go back to the user's profile in your IdP.
Set
isTeamAccount = False, this converts them to a Reader automatically.Save the changes and allow the sync to complete.
To verify, navigate to Document360 > Settings > Users & permissions > Readers & groups and confirm the user now appears as a Reader.
What to do when a SCIM group is manually deleted in Document360?
If a SCIM-provisioned group is manually deleted in Document360, re-pushing the same group from your IdP will fail because the group no longer exists on the application side.
To resolve this:
Remove or unlink the affected group from your IdP.
Sync the group again from the IdP to create it fresh in Document360.
Avoid deleting SCIM-managed groups directly in Document360. Always manage SCIM groups from your IdP to avoid sync issues.
Disabling and re-enabling SCIM does not automatically restore groups that were previously synced. If any SCIM-managed groups were deleted while SCIM was disabled, you must push those groups again from your IdP.
NOTE
If your user license limit has already been reached, re-syncing or re-pushing groups may fail because group linking depends on successful user provisioning. Before re-syncing groups, make sure your user limit has available capacity.
FAQ
How does the isTeamAccount attribute work in SCIM provisioning?
isTeamAccount attribute work in SCIM provisioning?The isTeamAccount attribute determines the role assigned to a user when they are provisioned in Document360.
When
isTeamAccountis set to True, the user is provisioned as a User.When
isTeamAccountis set to False or Left unset, the user is provisioned as a Reader.