Sync Azure AD & SCIM

Overview

This feature connects your Microsoft Entra ID (Azure AD) directory to Swiftask through two complementary mechanisms.

SSO Group Sync reads the Azure AD groups included in the SAML token every time a user signs in, and updates that user's Swiftask group membership to match — adding them to newly-joined groups and removing them from groups they've left. It requires no Azure credentials and no Microsoft Graph access; it only needs the group claim already present in your SAML sign-in.

SCIM 2.0 lets Azure push group membership changes for any assigned user (not only when that user next signs in), and deactivates Swiftask accounts for users removed from the enterprise application. It runs on Azure's own cycle (about every 40 minutes).

Use this feature if you manage group membership centrally in Azure AD and want it reflected in Swiftask automatically, without manual work in Swiftask.

Note: neither mechanism ever creates a Swiftask account. Account creation and login always happen through SSO (SAML), which is covered in a separate guide. A user must sign in at least once before they can belong to any Swiftask group.

You can rely on SSO Group Sync alone, or add SCIM on top. SSO Group Sync keeps group membership fresh whenever people actually sign in; SCIM keeps it fresh continuously and is the only mechanism that can deactivate someone who has been removed from Azure (a deactivated user can no longer sign in to trigger the SSO path).

There used to be a third, manual mechanism ("Sync with Azure", based on Microsoft Graph and per-workspace Azure app credentials). It has been removed from the product — group syncing is now fully automatic, through SSO Group Sync and/or SCIM.

Prerequisites

• An administrator account on the Azure portal (Entra ID), able to edit the enterprise application you configured for Swiftask SSO.

• An Admin or Owner role on the target Swiftask workspace.

• The Swiftask workspace on a Team Growth plan or higher (required for the User Provisioning page).

• That enterprise application already created in Azure (its exact name depends on what you chose when creating it — often "Swiftask", but not necessarily), with SSO (SAML) already configured and working. If it isn't, configure SSO first — this guide does not cover that step.

• A user must have signed in via SSO at least once to exist in Swiftask, before they can be added to a group through SSO Group Sync or SCIM.

Step-by-step guide

This walks through both sides together, in the order you'll actually click through them, starting in Azure.

Step 1 — (Azure) Make sure group membership is sent at sign-in

SSO Group Sync reads the Azure AD groups from your SAML token, so Azure must be configured to include them.

1. In the Azure portal, go to Enterprise applications → open the application you configured for Swiftask SSO.

2. In the left menu, click Single sign-on.

3. Under Attributes & claims, click Edit.

4. Check whether a group claim already exists. If not, click Add a group claim.

5. Choose "Groups assigned to the application" (recommended, to only send the groups relevant to Swiftask) and set the source attribute to Group ID.

6. Click Save.

Azure only includes this claim for users who belong to 150 groups or fewer. Above that, Azure omits the claim entirely for that user, and neither SSO Group Sync nor SCIM discovery can see their groups.

Step 2 — (Swiftask) Generate your SCIM connection details

Skip this step if you only want SSO Group Sync (no automatic deactivation). Come back to it later if you change your mind — nothing here is destructive.

1. In Swiftask, go to Settings → User Provisioning (URL pattern: /{workspaceId}/workspace/user-provisioning).

2. Click Setup Directory Sync.

3. Step 1 of the wizard confirms your SSO/SAML is already configured — continue.

4. Step 2: choose Microsoft Entra ID (Azure AD) as your identity provider.

5. Step 3: click Generate SCIM credentials. Swiftask displays a SCIM endpoint URL and a Bearer token.

Copy the Bearer token immediately — like an Azure client secret, it is only ever shown once. If you navigate away before copying it, click Generate new on the credentials screen to issue a fresh one (this immediately invalidates the previous one, so update Azure right after).

Step 3 — (Azure) Enable SCIM provisioning

Skip this step too if you're not using SCIM.

1. Still in that enterprise application, click Provisioning in the left menu.

2. Click Get started, then set Provisioning Mode to Automatic. An "Admin Credentials" section appears.

   If Azure shows a message instead saying admin credentials have moved to a new experience, click through to it — the same fields (Tenant URL, Secret Token) are there, just laid out differently.

3. Fill in:

   • Tenant URL (SCIM endpoint): the SCIM endpoint URL from step 2.

   • Secret Token: the Bearer token from step 2.

4. Click Test Connection. A confirmation banner should appear. If it fails, re-copy both values from Swiftask — a trailing space is the most common cause.

5. Expand Mappings → "Provision Azure Active Directory Users" and confirm the default attribute mappings (they should already be correct):

6. Go to Users and groups → Add user/group and assign every user and group you want SCIM to manage. SCIM only provisions what is explicitly assigned here.

7. Go back to Provisioning → Settings (top of the page). Set Scope to "Sync only assigned users and groups", set Provisioning Status to On, then Save.

Once you save with Provisioning Status set to On, Azure starts the first provisioning cycle automatically — there is no "Provision now" button on the Provisioning page itself. Track progress under Provisioning logs (left menu). If you want to test the sync for one specific user or group right away instead of waiting for the full cycle, use Provision on demand — a separate item in the left menu, listed above Manage — which runs a one-off sync for a user or group you pick.

Step 4 — (Swiftask) Link Azure groups to Swiftask groups

Neither SSO Group Sync nor SCIM ever creates a Swiftask group by itself — you decide which Azure group maps to which Swiftask group.

1. Get at least one user who belongs to the Azure group to sign in via SSO once (this discovers the group), or wait for Azure to push it via SCIM if you enabled step 3.

2. In Swiftask, go to Settings → User Provisioning → Groups tab. Every discovered Azure group appears here, unlinked.

   Tip: a group discovered only through sign-in (no SCIM) shows its raw Azure Object ID as its name, since the SAML token carries no group name — only SCIM pushes the real name. Keep a note of which Object ID (Azure → Entra ID → Groups → [group] → Overview) matches which team, so you can tell rows apart.

3. For each group, either:

   • Link to group — attach it to an existing Swiftask group, or

   • Create group — create a new Swiftask group (you choose its name and workspace role) already linked to this Azure group.

4. That's it — no separate "activate" step is required for membership to sync. (The Active toggle on this screen controls whether the group appears in the agent-sharing selector elsewhere in Swiftask; it doesn't gate the sync itself.)

From here on, every user who signs in gets added to — or removed from — their linked Swiftask groups automatically, and (if SCIM is enabled) Azure-side membership changes for any assigned, already-onboarded user are pushed within the ~40-minute cycle too.

Part 2 — Day-to-day lifecycle

Practical use cases

• Onboarding through Azure groups: a new hire is added to an Azure AD group before day one. Once they sign in via SSO on their first day, they're added to the matching Swiftask group immediately (if the group is already linked).

• Offboarding: an employee leaves and is removed from the enterprise application configured for Swiftask in Azure. With SCIM enabled, their Swiftask account is deactivated automatically within the next cycle — no manual action needed.

• Team reorganization: moving a user from one Azure group to another updates their Swiftask group membership the next time they sign in, keeping permissions aligned with their new role.

• Okta, Google Workspace or another IdP alongside Azure AD groups: SSO Group Sync works the same way for any SAML group claim — this guide focuses on the Azure AD steps, but the Swiftask-side setup is identical.

Tips & best practices

• Keep a simple record mapping each Azure Object ID to its Swiftask group — it speeds up linking in step 4 and future troubleshooting.

• Enable SCIM if you need account deactivation to happen automatically; SSO Group Sync alone only refreshes group membership for users who are still able to sign in.

• Test with a small group first before linking your entire directory — use Provision on demand to sync just that group without waiting for the full cycle.

• Regenerating the SCIM Bearer token breaks the connection until you paste the new value into Azure — do it during a low-risk window.

Troubleshooting

Additional resources

• SSO (SAML) setup for Azure AD — required before configuring SSO Group Sync and SCIM.