---
title: "Managing Users and Readers with SCIM in Okta"
slug: "scim-with-okta"
description: "Streamline user management with SCIM integration between Okta and Document360, ensuring real-time updates and accurate role provisioning effortlessly."
updated: 2026-06-03T11:11:53Z
published: 2026-06-03T11:11:53Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.document360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing Users and Readers with SCIM in Okta

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

1. In the Okta Admin Console, expand the **Applications**dropdown and select **Applications**.
2. Select the application you want to configure and navigate to the **Provisioning**tab.
3. Scroll down to **Attribute Mappings** and click **Go to Profile Editor**.
4. 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 |

![Adding a boolean attribute named 'Team Account' in the Okta Profile Editor interface.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/add attribute boolean(1).png)

1. 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**

1. In the Okta Admin Console, go to **Applications**and select your SCIM application.
2. Navigate to the **Provisioning**tab and click **To App**tab under **Settings**.
3. Scroll down to **Attribute Mappings** and click the **Edit**icon next to the `isTeamAccount` attribute.

![Okta Admin Console displaying user attributes and mapping options for applications.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/edit icon.png)

1. In the dialog, set the **Attribute value**dropdown to **Expression**.
2. Enter your expression in the text box provided.
3. 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.
4. 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.
5. Click **Save**.

![Admin console showing SCIM settings with highlighted expression and options for user roles.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/expression.png)

> [!NOTE]
> ******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](https://developer.okta.com/docs/reference/okta-expression-language/).

**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:

```plaintext
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]
> ******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:

```plaintext
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]
> ******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,

1. In the left navigation bar, expand **Applications**dropdown and click **Applications**.
2. Select your SCIM application and navigate to **Provisioning**tab.
3. Click **Edit**under **Provisioning to App** and select the following checkboxes:
  1. **Create Users**
  2. **Update User Attributes**
  3. **Deactivate Users**

![Okta Admin Console showing provisioning settings for user management and application integration.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/enable integration.png)

**Create a User**

### Create a User

1. In the Okta Admin Console, expand the **Directory**dropdown and select **People**.
2. 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.

![Okta Admin Console displaying user directory with options to add or reset passwords.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/add people(1).png)

1. Select the newly created user and click **Assign Applications** to link them to an application.
2. 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]
> **********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**
> 
> 1. Provision users from Okta through SCIM as usual. They will sync to Document360 with the default role, such as **Contributor**or **Admin**.
> 2. After the users are synced, manually change the role of the required users to **Reviewer**in Document360.
> 3. 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:
> 
> 1. First, provision 10 users through SCIM.
> 2. Then, change the required users to Reviewers in Document360.
> 3. Those users will move to the Reviewer quota, freeing User slots for additional users.

**Create a Reader**

### Create a Reader

To add a new reader in Document360 using Okta with SCIM, follow the steps below.

1. In the Okta Admin Console, expand the **Directory**dropdown and select **People**.
2. 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).

![Okta Admin Console displaying user directory with options to add or reset passwords.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/add people(1).png)

Once the Reader is provisioned, Document360 automatically assigns the role based on the rule configured in the Expression Builder.

1. To integrate the user with Document360, select the newly created reader and click **Assign Applications**.
2. In the **Assign Application** dialog, select the project you want to assign the reader to, then click**Assign**> **Save and Go Back**> **Done**.

![](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/assign application to reader(1).gif)

1. The newly created reader will be automatically synced with Document360. To verify this, go to Document360 and navigate to **Settings**> **Users & permissions**> **Readers & groups**.

![User management interface displaying reader accounts and their access statuses.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/reader added.png)

The reader will be added with the default content access that were applied during SSO setup.

**Create a group**

### Create group in Okta

To create a group in Okta,

1. In the Okta Admin Console, expand the **Directory**dropdown and select **Groups**.
2. Click **Add Group**, enter the desired group name, and click **Save**.

![Okta Admin Console displaying group management options and user statistics.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/add group(1).png)

#### Assign application to group

To assign the group to an application,

1. Expand the **Applications**dropdown and select **Applications**.
2. Select the desired application, navigate to the **Assignments**tab, and click **Assign**> **Assign to Groups**.
3. Click **Assign**next to the created group, then click **Save**to complete the assignment.

![](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/assign group to app.gif)

#### Push groups

Unlike users, groups are not automatically synced to Document360 and must be pushed manually. To do that,

1. After assigning the group to the application, navigate to the **Push Groups** tab and click **Push Groups**.
2. Select **Find groups by name**and enter the group name.
3. Select the group from the results and click **Save**to successfully push the group to Document360.

![](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/push group.gif)

1. To verify, navigate to **Document360**> **Settings**> **Users & permissions** > **Readers & groups** > **Reader groups**.

![User permissions management interface showing reader groups and access settings.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/reader grp in doc360.png)

The newly created reader group should appear in your portal.

> [!NOTE]
> ******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**

1. Open Document360 and locate the user account.
2. Manually update the user’s role to match the role you want to provision.
3. 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.

1. In the Okta Admin Console, expand the **Directory**dropdown and select **People**.
2. Navigate to the **Groups**tab, search for the group you want to add the user/reader to in the **Groups**field, and select it.

![Okta Admin Console showing user details and group management options for Jane Doe.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/add reader to group.png)

1. The user/reader will be successfully added to the selected group.
2. To confirm, navigate to Document360 and select the relevant user/reader group. The added reader should appear within the group.

![User permissions interface showing associated reader accounts and content access details.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/confirm reader.png)

> [!NOTE]
> ******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.

![Overview of reader management settings and user details in Document360 interface.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/badge.png)

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.

1. To manage content access, select the desired reader and click **Manage Content Access**.
2. Choose the desired access level from the dropdown and click **Update**.

![](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/manage content access.gif)

---

## Deactivate Users/Readers

> [!NOTE]
> ******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,

1. Expand **Directory**dropdown, and select **People**.
2. Select the user you want to deactivate to navigate to its user profile.
3. Click **More Actions** and select **Deactivate**.

![Admin console showing user details and options to deactivate or manage applications.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/deactivate(1).png)

The user will be deactivated successfully. Once deactivated, the user’s status in Document360 will change from **Active**to **Inactive**.

![List of readers with their statuses, highlighting one inactive account for review.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/inactive.png)

---

### Delete user/reader

To permanently remove a user/ reader profile from Okta,

1. In Okta, click **Delete**in the user/reader profile.
2. A confirmation dialog will appear, click **Delete**.

![Confirmation dialog for deleting user Mark Jacobs with warning message displayed.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/delete(3).png)

The profile will be permanently deleted from Okta.

> [!NOTE]
> ******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.

![Configuring the Identity Provider settings for SSO in Okta Admin Dashboard.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/child.png)

> [!NOTE]
> **** 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.

![SCIM provisioning settings with a warning about inherited configurations from the parent project.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/scim inherited.png)

### 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.

![SCIM provisioning settings in Okta with project details and configuration instructions displayed.](https://cdn.document360.io/860f9f88-412e-4570-8222-d5bf2f4b7dd1/Images/Documentation/parent.png)

- 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.

---

## FAQ

****How does the**`isTeamAccount`**attribute work in SCIM provisioning?****

The `isTeamAccount` attribute determines the role assigned to a user when they are provisioned in Document360.

- When `isTeamAccount` is set to **True**, the user is provisioned as a **User**.
- When `isTeamAccount` is set to **False**or **Left unset**, the user is provisioned as a **Reader**.