Skip to main content
Set up SCIM

Sync your awork users automatically via an identity provider and update permissions, teams and basic info centrally.

Lucas Bauche avatar
Written by Lucas Bauche
Updated this week

SCIM is an enterprise feature and is currently in a pilot state. Contact us for more information.

What is SCIM?

System for Cross-domain Identity Management, short SCIM, makes user management easier by allowing you to move users from and to different apps using a standard protocol. This way, you can have one application of truth where you manage your users, like Azure AD, OneLogin or Okta, and import users to or deactivate users from awork. Changes to the user information, like name, timezone or user role, are then automatically imported to awork.

This integration supports the current SCIM 2.0 version.

Why should I use SCIM with awork?

Using SCIM with awork has many advantages. First, you don’t need to worry about importing users to awork. When configuring SCIM, you choose which information should be synced to awork. The minimal setup only includes the first name, last name and email. On top of this information you can also add your preferred language, timezone, awork user roles, awork teams and more.

Second, SCIM works best with using single-sign on (SSO). This way, employees only need to worry about one login to all their apps, don’t need to setup potentially insecure passwords and can use additional safety mechanisms like multi-factor authentication (MFA). If you only have internal users in your workspace that are managed by your identity provider, you can only allow SSO and deactivate all other login options. If you also have external users in your awork workspace, you still need to allow login via password.

How does the SCIM sync work?

The SCIM sync is a one-way flow. Information only gets pushed into awork, not back from awork into your identity provider. Usually, you configure an app in your identity provider. In this app, you setup a configuration that decides what fields get synced and when. Consequentially, if you change information in awork for a user that is synced via SCIM, these changes won’t get synced back. These manual changes will get overridden in awork once the user is updated the next time from your identity provider.

You also have control over which users should be synced to awork. This is done by adding user groups or individual users to the SCIM app in your identity provider.

Supported features

  • Create users

  • Update users

  • Deactivate users

  • Get awork user roles via /Groups feature

  • Update awork user role assignments via /Groups feature

  • Update awork team assignments via SCIM /User schema extension


SCIM provisioning with awork requires:

  • An active enterprise subscription

  • A configured SSO (OpenID Connect) integration

Note: For OneLogin we have a preconfigured app that integrates SCIM and SSO (OpenID Connect) into a single app. Apps for Okta and Azure AD are coming soon!

What happens to existing users in awork?

Once you activate SCIM in your identity provider, usually the existing users are fetched from awork. Then they get matched to your existing users in your SCIM app via their email.

☝️ Hint: We use the account email of the user that can be changed only by the user via his/her profile, not the primary work email which can be configured in the user details.

Existing users that are matched will be updated in awork, users which don’t exist yet in awork will be imported, and existing users will not be updated. Therefore, you can only use SCIM for a subset of users and existing external users will not be affected.

When importing new users to awork, they won’t receive an invitation to awork. You need to send them the link to your workspace once you are finished with your setup, so the users can login with SSO. You also need to make sure that you have enough unused user licenses in awork so the user can be activated.

☝️ Hint: If a user is reactivated by the admin, this person will receive an e-mail informing them of the reactivation.

☝️ Hint: Currently there is no flag in awork that indicates which user is synced via SCIM, so you need to check the sync status in your identity provider.

Set up SCIM for awork

The setup of SCIM includes three steps:

  1. Preparing awork for SCIM

  2. Setting up awork in your identity provider

  3. Configuring the mapping

1. Preparing awork for SCIM

This section will guide you through the setup steps in awork.

  1. Login into your awork workspace

  2. Setup SSO for your workspace (if not done already)

  3. Go to the Settings > Integrations

  4. Click Open integration library to open the library

  5. In the SCIM section, select the provider you want to connect.
    If you don’t find your provider in the list, you can choose the generic SCIM integration. If you need help with this setup, please feel free to contact our support.

  6. Confirm and set up the integration.

  7. A popup will appear with a Bearer token. Copy this to your clip-board. You'll will need it to grant your identity provider access to awork.

8. You should now see the new SCIM integration in the integrations list and a new client application in the list below named API access.
The client application is used to authenticate the SCIM client and can be used to regenerate the Bearer token, if you need to copy it again. Please do not edit or delete this client application!

2. Setting up awork in your identity provider

For OneLogin, Okta and Azure AD we provide additional information that walk you through the setup flow. Jump to the section of your provider for the next steps.

For OneLogin we provide a predefined awork app which includes convenient defaults and that can also be used as a SSO app, so you only need a single app for SSO and SCIM. Apps for Okta and Azure AD are coming soon!


(awork app coming soon to Okta app store)

  1. Go to the Menu > Applications > Applications

  2. Click on Browse App Catalogue

  3. Search for SCIM 2.0

  4. Select SCIM 2.0 Test App (OAuth Bearer Token)

  5. Click on Add Integration

  6. Set an application label, like awork SCIM integration and click on Next

  7. Skip the Sign-on methods (as we don’t support SAML for SSO)

  8. In the Credentials Details select Email in the dropdown

  9. Click on Done

  10. Go to the Provisioning tab and click on Configure API Integration

  11. Check Enable API Integration

  12. Enter in the SCIM 2.0 Base Url field

  13. Copy the client secret from your awork SCIM integration into the OAuth Bearer Token field

  14. Click on Save


  1. Go to your OneLogin administration area and open Applications -> Applications

  2. Click on "Add App" in the top right corner

  3. Search for awork in the search field

  4. Click on the app and hit Click in the top right corner

    1. After the save, you can see some basic configuration that we already set up for you. You can edit this configuration to fit your personal use-case.

  5. On the left, open the Configuration tab

    1. In the field Login Url you can put either "" or the link directly to your subdomain, so "" (preferred).

    2. In the field subdomain you need to put the link to your workspace before the, so for, it needs to be precious-asteroid

    3. In the section API Status, you can simply click on Enable

    4. In the section SCIM Bearer Token you can now paste the token you got when creating the SCIM integration in awork

    5. In the field SCIM JSON Template you can define which information from OneLogin gets synced to awork. The default config only syncs the email, first and last name and looks like this:

      "schemas": [
      "userName": "{$parameters.scimusername}",
      "name": {
      "givenName": "{$parameters.firstname}",
      "familyName": "{$parameters.lastname}"
      "emails": [
      "value": "{$}",
      "primary": true,
      "type": "work"

    6. You can extend this config to map additional user fields. You can find the available fields in the Mappings section. For every field you need to create a parameter in the Parameters tab on the left and map the value to some value from OneLogin. Contact us for more information.

  6. Next, go to the Provisioning tab on the left

    1. Under Workflow, you can enable the provisioning.

    2. You can also decide, if you want to require admin approval before specific actions are done. We recommend only leaving these checked for initial setup/testing purposes.

    3. In the Entitlements section click on Refresh to fetch the user roles from awork. Note: The guest roles does not get returned here as this one can only be used for external users.

  7. If you want to configure default user roles for your users in awork, you can go to the Rules tab on the left

    1. Click on Add Rule to add a new rule

    2. Enter a name and add a condition for your rule, f.e. user is in group Admin

    3. Now you can add actions, like set the group in awork. It's important that you did the entitlements refresh before to get all the user roles. You also need to select "From Existing" because you can only create/update user roles directly in awork. After selecting a role, do not forget to click on the Add button, else the group is not added. You should also only add a single group, as in awork you can only be in one user role at a time.

    4. Click on Save

    5. Repeat these steps for all your awork user roles.

  8. Finalise your configuration by clicking on the Save button on the top right corner.

  9. Attention: You made all the configurations to finally add users to your app. If you want to test the configuration to make sure all your fields get mapped correctly, we recommend adding a test user to the app, which can be done in the user details under Users -> Users -> select your test user -> Applications

  10. In the last step you can finally add your users to the app. This is either done individually for each user or via policies (recommended).

    1. For Policy based access to the app go to the Access tab on the left

      1. Select the roles that should be added to the app.

    2. For individual user assignments, simply go to the user details and the Application tab. Here you can add a new app by clicking the plus button on the top right

  11. You can check your provisioning history under Users -> Provisioning

  12. You can also find all events of the awork app under Activity -> Events

Azure AD

  1. Go to Azure Active Directory

  2. Go to Enterprise Applications

    1. Create a new Application

    2. In the Azure AD Gallery, click on "Create your own Application"

    3. Set a name, like awork SCIM

    4. Check "Integrate any other application you didn't find in the gallery"

    5. Click on "Create"

  3. Go to the newly created app

    1. Go to the Provisioning Tab

    2. Edit the provisioning

    3. Set the Provisioning Mode to "Automatic"

    4. Set the admin credentials

      1. Set the Tenant URL to:

      2. Set the Secret token to the token, you get when creating the SCIM integration in awork

      3. Test the connection, to see if the secret is correct

    5. Save the configuration. After that two other sections will appear

    6. Edit the mappings

      1. Click On the Groups. Disable this feature and save. Currently, awork does not support Groups with Azure AD.

      2. Go back to the mappings and edit the Users mappings

        1. Set Target Object Actions to all: Create, Update, Delete

        2. The default list of mappings already has the correct mapping for the required fields. The rest of the mappings need to be deleted, so that the Sync works as expected. The required mappings from Azure Active Directory Mapping to customappsso Attribute are:

          1. userPrincipalName -> userName (the userPrincipalName needs to be set to the email of the user)

          2. Switch([IsSoftDeleted], , "False", "True", "True", "False") -> active

          3. mail -> emails[type eq "work"].value

          4. preferredLanguage → preferredLanguage

          5. givenName → name.givenName

          6. surname → name.familyName

        3. Optionally you can currently also map:

          1. jobTitle → userType (This is shown as the Position in awork)

    7. Save the user mappings

    8. Edit the Settings

      1. Enable "Prevent accidental deletion" if you wish. This prevents the deletion of many users at the same time if you f.e. removed the wrong group. We recommend a number like 50, depending on your number of awork users and typical group sizes.

      2. Check "Sync only assigned users and groups"

    9. Turn the provisioning status to On and save

  4. Test provisioning for a single user

    1. Go to the Provisioning Tab of the Enterprise Application and click on "Provision on demand

    2. Select a single user via email

    3. Click on Provision

    4. Check results of the validation. Your user fields should now be updated in awork.

  5. Add the groups/users that should use the app. For every new user added, an additional license is needed, so please make sure to have enough awork licenses booked.

    1. Go to the Provisioning Tab. Click on users and groups and add the groups and individual users you want to add to awork. Group assignments are only available with a Azure AD Premium P2 subscription.

    2. Go to the provisioning overview and start the Provisioning Job. This job runs all 40 minutes and sync all changes between Azure AD and awork. Fields that are not included in the mapping will not be overridden in awork.

Troubleshooting Azure AD SCIM Sync

In case the SCIM sync is not working as expected, you can go to the Enterprise App Provisioning Overview and click on View provisioning logs. In the provisioning logs you can find informations on the synced users and properties. In case something something failed, the status of the entry will be set to Failure. Please click on that entry and go to the Troubleshooting & Recommendations page and copy the error message. Please then contact our support and pass the error message, so we can take a closer look.

For more infos on the Azure side of the SCIM integration, you can find more infos in the Azure docs here: How Application Provisioning works in Azure Active Directory

3. Configuring the mapping

The awork user fields are mapped to the SCIM user resource. A list of the supported fields can be found here:

SCIM field

awork field


SCIM user

awork user

awork account




userContactInfos → type=email && subtype=work (primary user email)


this email is used to match awork user/account and users from your SCIM client

name → familyName



name → givenName









currently only supports de-DE or en-GB (other en- and de- prefixes will get converted to the supported default value)



The IANA timezone info (



SCIM User multi-value attributes


userContactInfos → type=email

the first work email is set to the primary email of the user


userContactInfos → type=phone


userContactInfos → type=address




multi value string array. Matching happens by name.

SCIM Group

awork User role







If there are any fields that you would like to sync which aren’t shown in this overview, please let us know.

Note: awork supports team assignments via the external namespace urn:ietf:params:scim:schemas:extension:Teams:2.0:User as a multi value string field. The team assignments get matched via the name of the team. Therefore, the name of the team in awork and your SCIM client need to match exactly.

Note: awork User roles are mapped to the SCIM /Groups feature for handling permissions. Please note, that an awork user can only have one user role at a time, therefore you need to make sure that you don’t assign more than one role via the group assignments as this limitation is not supported directly by SCIM.


Can I create/update user roles via SCIM?

No, you can only match roles. To create or update permission roles in awork navigate to Menu → Settings → Permissions.

Can I sync profile pictures via SCIM?

This is not supported right now from the providers OneLogin and Okta. We therefore don't offer this functionality yet.

What happens if I change the name of a permission role in awork?

After renaming the permission roles in awork, you need to refresh the groups in your SCIM client to show the correct names. The mappings should not change as this done by the identifier of the user role and not the display name.

What can I do if my SCIM integration is not working as expected?

Check the users that cannot be provisioned and check the corresponding error messages. Send our support team the trace id so we can check it for you. Make sure your client application is set up correctly and also the api access item (item in list below the integrations) is existent. Otherwise delete the integration in awork and try to set it up again.

Can guest users be synced via SCIM?

Guest users cannot be created via the SCIM integration, because the user role with the least permissions that is not the guest role is automatically assigned on user creation. If the user already exists in awork, the role does not get changed via the SCIM integration, unless explicitly configured via the SCIM Groups feature. Existing guest users can be synced via the SCIM integration, but the SCIM Groups feature does not support assigning guest roles.

Did this answer your question?