Directory sync (SCIM)

Directory sync lets your identity provider manage SurveyRock users and groups. When someone joins the Research team in Okta, they get a SurveyRock account and the Research group’s access; when they leave, both are withdrawn. Nobody has to remember.

Available on Enterprise. It works alongside SSO, which handles how people sign in — directory sync handles what they can reach once they have.

What is supported today

Being precise about this matters more than making the list look long: your IT team configures against it, and a capability that turns out not to exist costs them an afternoon.

Create users	Yes
Deactivate users	Yes
Create, rename and delete groups	Yes
Add and remove group members	Yes
Push groups and users from your IdP	Yes
Filter by displayName / userName	Yes
Update a user’s name or email after creation	No — see below
Bulk operations	No

What a provisioned user gets

A user your identity provider creates joins the workspace with the role you set as the workspace default — Editor unless you change it, the same default an invitation uses. Set it under Workspace Users → Default role for new members.

An editor can build, send and analyse surveys. An editor cannot delete a survey, cannot see personally identifiable respondent data, and holds no administrative powers: not members, settings, branding, billing or the audit log. If that is more than a synced user should have, set the default to Viewer before you turn provisioning on — read-only access, and a client seat rather than a staff one.

That is a deliberate starting point rather than a shortcut. Provisioning is the moment access is granted without a person reviewing it, so the default has to be the role that is safe to hand out unreviewed. Raise an individual afterwards under Team members, or put them in a group that carries the access you want.

Each provisioned person occupies a staff seat, the same pool as anyone invited as an admin or editor. Enterprise plans are not capped on staff seats by default, so a rollout of any size provisions without needing seats bought in advance — unless your contract sets a specific limit, in which case provisioning stops at it rather than quietly exceeding it.

They are created without a password, and sign in through SSO. There is no invitation email and nothing for them to accept: the account exists the moment your directory says it should.

Changing the default affects people who join from then on. Anyone already in the workspace keeps the role they have, so setting it is safe at any point — but setting it before the first sync saves correcting everybody afterwards.

Name and email changes do not flow through

Once a user exists, SurveyRock keeps the name and email it was given. Your identity provider will send updates and we accept them without error, but they are not applied, so a person who changes their surname in your directory keeps the old one here until it is corrected under Team members.

We would rather say this plainly than let your IT team discover it during an audit.

Before you start

• An Enterprise plan
• Owner or admin on the workspace you’re syncing
• Someone with admin access to your Okta or Entra tenant

Directory sync is configured per workspace. If you use several workspaces, each has its own endpoint and token, and groups do not cross between them.

Step 1 — get your endpoint and token

1. In SurveyRock, open Workspace settings.
2. Find Directory sync (SCIM).
3. Copy the SCIM base URL. It looks like https://app.surveyrock.com/scim/v2.
4. Click Generate token and copy the token immediately.

The token is shown once. We store only a hash of it, so we cannot show it to you again — if you lose it, generate a new one and update your identity provider. Treat it like a password: it can create and remove group access in this workspace.

Step 2a — Okta

1. In the Okta Admin Console, go to Applications → Applications → Browse App Catalog, or create a SCIM 2.0 Test App (Header Auth) if you’re setting this up manually.
2. On the Provisioning tab, choose Configure API Integration and tick Enable API integration.
3. SCIM connector base URL — the base URL you copied.
4. Unique identifier field for users — userName.
5. Authentication Mode — HTTP Header, with the token you generated as the Bearer token.
6. Click Test API Credentials. It should succeed before you go further.
7. Under To App, enable Create Users and Deactivate Users. Leave Update User Attributes off — SurveyRock accepts those calls but does not apply them, so leaving it on gives you a sync that reports success without changing anything.
8. Enable Push Groups, then on the Push Groups tab add the groups you want SurveyRock to mirror.
9. Assign people to the application. Everyone assigned is created in the workspace.

If Test API Credentials fails, the cause is almost always one of: a token that was revoked, a workspace that is no longer on Enterprise, or a base URL missing the /scim/v2 suffix.

Step 2b — Microsoft Entra ID

1. In the Entra admin centre, go to Enterprise applications → New application → Create your own application, and choose the non-gallery option.
2. Open Provisioning and set Provisioning Mode to Automatic.
3. Tenant URL — the base URL you copied.
4. Secret Token — the token you generated.
5. Click Test Connection, then save.
6. Under Mappings, keep both Provision Microsoft Entra ID Users and Provision Microsoft Entra ID Groups enabled.
7. In the user mapping, userPrincipalName should map to userName. That is Entra’s default and it is the attribute SurveyRock matches on.
8. Assign the users and groups you want synced under Users and groups, then turn Provisioning Status on.

Step 3 — give the group access

Directory sync decides who is in a group. It does not decide what the group can do — that stays with you, so a change in your directory can never silently widen access.

In SurveyRock, open Workspace settings → Groups, find the synced group, and set Access in this workspace to the role it should carry. Until you do, the group exists and has members but confers nothing.

A group’s access adds to what each member already has: it can raise someone above their individual role, and it never lowers them. To restrict a particular person, set their own permissions on the survey — an individual restriction always wins.

If none of the built-in roles fit

Under Roles on the same page, copy a built-in role and change what it allows — the five axes (Build, Send, Analyze, Contacts, Workflows), whether it can see personal data, whether it can delete surveys, and which administrative permissions it carries. Then assign your new role to the group.

Editing a role changes access for every group already using it, immediately and everywhere. That is the point of roles rather than per-group settings, and it is worth knowing before you edit one that several groups share.

Three permissions cannot be granted through a role at all — billing, deleting a workspace, and transferring ownership. They stay with workspace owners, so no directory group can ever confer them.

How synced groups behave

A group managed by your identity provider is read-only in SurveyRock, and is labelled Managed by your identity provider. You cannot add or remove its members here.

That is deliberate. If both sides could edit membership, your change in SurveyRock would be silently undone at the next sync, with nothing to tell you why. Make the change in your identity provider and it appears here.

Groups you create in SurveyRock are unaffected and stay fully editable.

When someone leaves

Deactivate or unassign them in your identity provider and their workspace access ends on the next sync. Concretely:

• They are removed from the workspace and from every group in it.
• Any survey they owned is handed to a workspace owner rather than deleted or orphaned. Nobody loses data because somebody left.
• Permissions granted to them individually are revoked.
• Their SurveyRock login is not disabled platform-wide. A token authorises one workspace, so it never touches access they hold somewhere else.

Owners are the exception. Directory sync will not remove a workspace owner — there would be nobody to inherit their surveys. Transfer ownership under Team members first, and the next sync completes.

Deactivating twice is safe. If your identity provider retries, we report success rather than an error, because the state it asked for is the state that exists.

When a group is removed from sync

If you delete or unassign a synced group in your identity provider:

• Members it provisioned lose the access it gave them.
• Anyone added by hand in SurveyRock stays, and the group survives as an ordinary SurveyRock group you can edit again.
• The group’s own permissions are removed with it.

A group that still has hand-added members is not deleted, because those people were never your identity provider’s to remove.

Revoking access

Revoke a token from Directory sync (SCIM) in workspace settings. Syncing stops immediately.

Revoking does not remove anyone or delete any groups — it stops your identity provider from making further changes. Revoked tokens stay listed so you can see what was active and when.

Troubleshooting

“Never used” beside a token. The token was generated but no sync has ever reached us. The setup on the identity provider side was probably not finished.

A group syncs, but a member is missing. They are almost certainly not assigned to the application in your identity provider, so we were never told to create them. Assign them and re-run provisioning.

Provisioning stops with an insufficient-storage or quota error. The workspace has reached a seat limit. Enterprise plans have no seat cap by default, so this means your contract sets one. Remove a member, cancel unused invitations, or talk to us, and provisioning resumes on the next cycle. We fail the call rather than admitting people over an agreed limit, so your identity provider tells you rather than leaving you to find out from an invoice.

A user will not deactivate. Workspace owners cannot be removed by directory sync, because their surveys have to be handed to someone first. Transfer ownership under Team members, then retry.

Everything returns 403. The workspace is no longer on a plan that includes directory sync. The entitlement is checked on every request, not only when the token was created.

Everything returns 401. The token was revoked, or it was copied incompletely — it is long, and a truncated paste is the most common cause.