Skip to main content

Entra ID Setup Guide

  • Updated

This guide connects your Microsoft Entra ID tenant to Wisq using SCIM (System for Cross-domain Identity Management). Once it is set up, Wisq automatically creates, updates, and deactivates user accounts based on how they are assigned in Entra ID. Questions at any point? Contact your Wisq Agent Strategist.

What you'll need

  • Admin access to your Microsoft Entra ID tenant.

Wisq will send you the following via Proton Mail:

  • Tenant URL
  • Secret token

Setup

1. Add Wisq to Entra ID

  1. In the Microsoft Entra admin center, go to Applications → Enterprise Applications → + New Application.
  2. Click Create your own application.
  3. Name it something like Wisq SCIM Provisioning, select Integrate any other application you don't find in the gallery (Non-gallery), and click Create.

2. Connect to Wisq

  1. Open the new application, select Provisioning, then Connect your application.
  2. Under Admin Credentials, paste the Tenant URL and Secret Token Wisq sent you.
  3. Click Test Connection, wait for the confirmation, then click Save.

3. Map attributes

Go to Provisioning → Attribute mapping → Provision Microsoft Entra ID Users, then:

  • Enable Users and set Target Object Actions to Create, Update, and Delete.
  • Review the attribute mappings against the screenshot below — the left column is what Wisq expects, the right is your matching Entra field — adjust as needed, and Save.

Don't skip the active mapping. The list must include a mapping whose target attribute is active, driven by the account's enabled/disabled state (Entra's default expression is Switch([IsSoftDeleted], , "False", "True", "True", "False")). This is how Wisq knows whether a user is enabled or disabled — without it, a user you disable in Entra (rather than unassign) keeps their Wisq access. If active isn't in the list, add it with Add New Mapping.

Custom attributes. To add Wisq-specific attributes, click Show Advanced Options → Edit attribute list for customappsso, and prefix each one with:

urn:ietf:params:scim:schemas:extension:wisq:1.0:User:$CustomAttribute

For example, the manager's email address is:

urn:ietf:params:scim:schemas:extension:wisq:1.0:User:managerEmail

4. Assign users

Wisq provisions users, not groups. You can assign a group to control who gets provisioned — Entra expands it to its members and sends us the users, which is fine. Just leave group object provisioning off: under Provisioning → Mappings, do not enable Provision Microsoft Entra ID Groups. Wisq's SCIM endpoint is users-only, so a group sync has nothing to write to and will report errors.

  1. Start with 1–2 test users. Under your application, go to Users and groups → + Add user/group, select them, and click Assign.
  2. Provisioning begins on the next cycle — track it under Provisioning Logs.
  3. Once Wisq confirms the test users' attributes are arriving correctly, expand the rollout. Coordinate with your project lead on who should get access and when.

5. Test offboarding

Before rolling out widely, test deactivation as well as creation. A deprovisioning problem is silent — new users and profile updates keep syncing normally, so the only symptom is that departed employees keep their Wisq access. Far better to catch it now than after go-live.

  1. Confirm Delete is still on. Provisioning → Attribute mapping → Provision Microsoft Entra ID Users → Target Object Actions should have Create, Update, and Delete all checked. If Delete is off, Entra never tells us about a departure.
  2. Deactivate a test user the way you will day to day — usually either unassigning them under Users and groups, or disabling their account in Entra. These take different paths (unassigning uses the Delete action; disabling uses the active mapping), so test whichever one your offboarding process actually uses.
  3. Use Provision on demand — don't wait for the cycle. Entra syncs roughly every 40 minutes, so a change won't appear immediately and it's easy to assume something broke when it's simply queued. Go to Provisioning → Provision on demand, select the user, and click Provision.
  4. Check Provisioning Logs — you should see the disable/delete reported as successful. Let us know, and we'll confirm Wisq received it. Then re-assign or re-enable the user to restore their access.

Using a scoping filter? Make sure your test user stays in scope. A user who falls out of scope simply stops syncing — no deactivation is ever sent — which looks fine on your side but leaves their Wisq access in place.