# Setting up Okta SCIM

Last updated 9 days ago

### Who can use this feature

- Supported on any **Enterprise** plans with SCIM included in their package
- Anyone with an org admin role can access and edit SCIM settings

This article shows how to retrieve key pieces of information from Okta to complete the SCIM provisioning process. For the rest of the SCIM setup process, see our article [Setting up SCIM provisioning](https://support.writer.com/article/88-setting-up-scim-provisioning).

## Before you begin

- [Set up SAML SSO](https://support.writer.com/article/43-setting-up-saml-sso) before you begin SCIM provisioning.
- Collect key data from WRITER to share with Okta, as explained [here](https://support.writer.com/article/88-setting-up-scim-provisioning#Set-up-SAML-SSO-between-Writer-and-your-IdP-maqBv).

## Configure SCIM in Okta

Go to the **WRITER application** \> **General** tab in Okta and **enable SCIM provisioning**:

Go to **Provisioning** > **Integration** and configure SCIM using your details from [step 1](https://support.writer.com/article/88-setting-up-scim-provisioning#Step-by-step-configuration-instructions-iJSb-) of our setup instructions. WRITER's custom application uses `SAML 2.0` authentication.

We don’t support the following provisioning actions: `import new users and profile updates`, `import groups`.

**Note:** The `Push Groups` provisioning action is only required when a) you have multiple teams set up in WRITER, and b) you want to assign unique Okta groups to **different** WRITER teams.

### Configure role attribute in Okta

You can add a custom attribute to assign `team member` and `org admin` roles to WRITER team members. To get started, visit **Provisioning** > **Go to Profile Editor**:

Select **Add Attribute** to set up the WRITER Role attribute and match the field values to the below screenshot. Our external namespace is `urn:custom:params:scim:schemas:extension:writer:2.0`

You can now use this attribute to assign WRITER roles to Okta users and groups 🥳:

The member role equates to a standard WRITER team member, while admin makes the user a WRITER org admin.

- **Admin** will make a user into a WRITER org admin
- **Member** will make a user into a WRITER team member

See more about WRITER roles [here](https://support.writer.com/article/67-enterprise-plan-roles-and-permissions).

### Push users and groups to WRITER (optional)

If you have multiple WRITER teams, and want to sync specific Okta groups to these different teams, you can link your Okta group to your app group (WRITER team).

Go to **Push Groups** and select the ⚙ gear icon.

Disable the checkbox for renaming app groups.

Select **Refresh App Groups** > **Find groups by name** to link your Okta Group and WRITER Team.

**Note:** Linking Okta Groups and WRITER Teams requires your Okta group name and WRITER team name to be **identical**. Once the initial link is complete, you can change the name of the Okta group, if desired.

One last step! Go to **Assignments** and assign the group to the WRITER application. You can also `Assign to People` instead, if you're provisioning individual users.

## Finish the SCIM provisioning process

Return to [Setting up SCIM provisioning](https://support.writer.com/article/88-setting-up-scim-provisioning#Choose-default-team-in-Writer-Z_6VF) to complete this process.

## FAQs

### Can SCIM activate/deactivate Writer accounts?

Yes

### When deactivated in Okta, is the Writer account deactivated or deleted?

This is dependent on the IdP and method invoked (we have both a delete endpoint and an update endpoint, but I believe by default Okta sends a request to update which will "deactivate" and unassign that user from the organization on our backend)

### What happens to deactivated user's content/history?

Any documents tied to that user should be re-assigned to the OrgAdmin

### If reactivated in Okta, does Writer auto-restore with previous settings, or treat as new user?

Their content/history will not be re-assigned but I wouldn't call it a new user either as the userId would be the same (if deactivated).

Beyond Admin/Member, can we manage granular permissions via Okta?

By combining SCIM IdP group mappings, you can control permissions via Okta and group pushing from Okta ( [https://support.writer.com/article/291-how-to-use-the-new-scim-endpoint](https://support.writer.com/article/291-how-to-use-the-new-scim-endpoint))

### If roles set in both Okta and Writer, which wins?

Depends if manual override is enabled. If disabled, Okta is the source of truth for roles and permissions. If enabled, OrgAdmin can supercede Okta roles and permissions.

### What does it mean that WRITER does not support "import new users and profile updates"

This means the user flow is one way from Okta -> WRITER. We do not send new users / user updates from WRITER back into Okta. Okta is the system of record.