SCIM Connection Guide
Overview
Section Coach (formerly, "ProfAI") supports SCIM 2.0-based Directory Sync for enterprise clients. Once enabled, your identity provider (IdP) keeps Section up to date on each employee's profile, and deactivations in your IdP automatically revoke access. You no longer need CSV imports or manual user management. Each person's Section Coach account is created at their first sign-in through SSO.
SCIM is built on top of your existing SSO connection. Completing SSO setup is a prerequisite to enabling SCIM - see the SSO Connection Guide before starting the process below.
SCIM can also bring your HR and org data into Section. Beyond provisioning users, SCIM has become the primary way our customers send department, manager, and other org attributes to Section. This data powers team and manager breakdowns in reporting.
Please reach out to your Customer Success representative if you have questions or difficulty with the process below.
How It Works
Once Directory Sync is established, your IdP pushes user changes to Section using the SCIM 2.0 standard:
- Create - When IT assigns a new employee to Section in your IdP, Section receives their profile and they can sign in right away. Their Section Coach account is created at their first sign-in.
- Update - When an employee's name or profile attributes change in the IdP, the change flows through to Section automatically.
- Deactivate - When IT removes or deactivates an employee in the IdP, that user is signed out of Section and blocked from signing back in.
The mechanics: your IdP sends SCIM 2.0 events to Clerk (Section's authentication provider), Clerk applies the change, and Section's user list stays continuously in sync with your IdP.
Technical note: in practice, especially at large organizations, there's at least one hop between "new hire" and "enabled for Section." IT staff assign employees to IdP groups within their org, and then assign those groups to Section. This is the same mechanic as SSO.
Supported Identity Providers
Section supports any SCIM 2.0-compliant identity provider. We provide step-by-step setup instructions for the two most common, Okta and Microsoft Entra ID (formerly Azure AD), in the sequence below.
If your organization uses a different SCIM 2.0 provider, such as SailPoint IdentityIQ, follow the Other SCIM 2.0 providers steps below. Contact your Customer Success representative if your provider's setup does not match them.
Setup Sequence
Step 1 - Client: Complete SSO Setup
If your organization has not yet completed SSO with Section, follow the SSO Connection Guide first. SCIM cannot be enabled on a connection without an established SSO link.
Step 2 - Section: Provide SCIM Endpoint and Bearer Token
Once your SSO connection is active, Section will enable Directory Sync on your connection and send you two values:
| Value | Purpose |
|---|---|
| Endpoint URL | The SCIM 2.0 endpoint your IdP will push user changes to. |
| Bearer token | The API credential your IdP will use to authenticate to that endpoint. |
Treat the Bearer token as a secret - store it in your IdP's credential field, not in plaintext documentation or shared channels.
Tell Section which reporting attributes you plan to send before your first sync. Section turns each attribute on for your connection before you start provisioning, so every person's values are in place from their first sync. If an attribute is turned on later, Section applies it to people who have already synced. You do not need to edit users in your IdP. See Reporting attributes below.
Step 3 - Client: Configure Your IdP
Configure your IdP to push users to the endpoint provided by Section.
- In the Okta admin dashboard, open your Section enterprise app and go to the Provisioning tab.
- Select Configure API Integration and enable Enable API integration.
- Paste the Endpoint URL from Section into the SCIM connector base URL field.
- Set Unique identifier field for users to
userName. - Paste the Bearer token from Section into the API Token field.
- Click Test API Credentials to confirm the connection, then click Save.
- Under To App, enable: Create Users, Update User Attributes, and Deactivate Users. Click Save.
- Under Attribute Mappings, confirm
emails(user.email) is mapped. Even ifuserNameis the user's email, a separate mapping toemailsis required. - Assign the users or groups that should have access to Section.
- In the Azure portal, open your Section enterprise application and select Provisioning.
- Set Provisioning Mode to Automatic.
- In Admin Credentials, paste the Endpoint URL from Section into the Tenant URL field.
- Paste the Bearer token from Section into the Secret Token field.
- Click Test Connection to verify, then click Save.
- Expand Mappings and confirm attribute mappings exist for
userName,name.givenName,name.familyName,emails, andactive. - Under Settings, set Provisioning Status to On and click Save.
- Assign the users or groups that should have access to Section.
These steps apply to any SCIM 2.0 provider. Field names vary by provider.
- In your provider, create a SCIM 2.0 application or connector for Section.
- Paste the Endpoint URL from Section into the base URL field.
- Paste the Bearer token from Section into the provider's credential field, often named API Token or Secret Token. Some providers expect the token entered with the word Bearer and a space in front of it, as
Bearer <token>. If the connection test fails with an authorization error, try that format. - Use
userNameas the unique identifier for users. - Map the user's email address to
emails. Even ifuserNameis the user's email, a separate mapping toemailsis required. - Map
name.givenName,name.familyName, andactive. - Turn on creating users, updating user attributes, and deactivating users.
- Test the connection, then assign the users or groups that should have access to Section.
If you are sending reporting attributes, start with one test user. Provision a single user first (in Entra, use Provision on demand; in Okta, assign one user), with every reporting attribute filled in. Section finishes setting up your attribute mappings using that user and confirms the values are arriving. Then assign the rest of your users and groups.
Step 4 - Section: Verify Provisioning
Once your IdP completes its first sync, Section will confirm that users have been provisioned successfully. You can verify by signing in as one of the newly provisioned users.
If you send reporting attributes, Section also checks that each one is arriving for your users (for example, that department and manager are present on nearly everyone) before you rely on them in reporting.
Synced User Attributes
Standard attributes
The following attributes are synced from your IdP to Section. Once SCIM is enabled, these fields are managed exclusively by the IdP and become read-only in Section - changes must be made in your IdP and will flow through on the next sync.
| Section field | SCIM attribute |
|---|---|
| Email address | emails[0].value |
| First name | name.givenName |
| Last name | name.familyName |
Each user's SCIM id is assigned by Section's SCIM service when the user is created. Your IdP does not send it.
Reporting attributes (recommended)
Section can also receive employee profile attributes over the same SCIM connection. This is the recommended way to bring your HR and org data into Section. These attributes power team and manager breakdowns in Section's reporting (for example, adoption and proficiency broken out by department). Provisioning works without them, and users without a value appear ungrouped in the corresponding report views.
We recommend sending these three:
| Section field | SCIM attribute | Why it matters |
|---|---|---|
| Department | department (enterprise schema) | Department breakdowns across reporting. |
| Employee ID | employeeNumber (enterprise schema) | A stable identifier that links each person to your HR records and to their reports. |
| Manager | Depends on your IdP (see below) | Manager and team breakdowns. |
department and employeeNumber are part of the standard SCIM enterprise user schema (urn:ietf:params:scim:schemas:extension:enterprise:2.0:User), so most IdPs send them without extra setup.
How you send the manager depends on your IdP:
- Okta and other SCIM 2.0 IdPs: send the manager's email address in the standard
managerattribute (enterprise schema). Keep it as an email, because Section matches it to the manager's own email. - Microsoft Entra ID: we recommend sending the manager's employee ID as plain text in the custom attribute
manager_employee_id. This is the same value you send as that manager's ownemployeeNumber. If your users do not carry their manager's employee ID, leave Entra's standardmanagermapping in place. Section resolves it to the right manager on its side, and you do not need to do anything else.
Include managers in the sync scope. Section can roll a person up to their manager only when the manager is also provisioned to Section. If a manager is left out of the users or groups assigned to Section, that manager's reports will not roll up to them in team views.
Section can enable other common fields for deeper reporting. Some are standard enterprise attributes, and others fall outside the standard schema, so your IdP sends them as custom attributes under Section's namespace. Send every value as plain text:
| Section field | SCIM attribute |
|---|---|
| Business unit | division (enterprise schema) |
| Cost center | costCenter (enterprise schema) |
| Organization | organization (enterprise schema) |
| Job level | job_level (custom) |
| Management level | management_level (custom) |
| Employee type | employee_type (custom) |
| Hire date | hire_date (custom) |
| Location | location (custom), for example an office, city, or country |
For custom attributes, the namespace is:
urn:ietf:params:scim:schemas:extension:clerk:2.0:UserTell your Customer Success representative which of these you plan to send, and Section will turn them on for your connection before your first sync.
Section does not receive payroll data, compensation, social security numbers, or any sensitive fields beyond those listed above.
Getting the values into your IdP
The values must exist on the user profile in your IdP before they can be sent. If the source of truth is an upstream HR system (for example, Workday), first map the fields from the HR system onto your IdP's user profile using your IdP's standard HR-source profile mapping. Section does not need a separate integration with your HR system.
Then map them in the Section app's provisioning settings:
- Open your Section app and go to Provisioning > To App, then scroll to the attribute mappings.
- If
departmentoremployeeNumberis not already listed, open Go to Profile Editor and add it. Set the External namespace tourn:ietf:params:scim:schemas:extension:enterprise:2.0:Userand usedepartmentoremployeeNumberas the External name. - For the manager, add an attribute in the Profile Editor with the External name
manager.valueand the External namespaceurn:ietf:params:scim:schemas:extension:enterprise:2.0:User, typed as a string. - For each custom attribute, add it in the Profile Editor with the External namespace
urn:ietf:params:scim:schemas:extension:clerk:2.0:User. Use the attribute name from the tables above as the External name, typed as a string. - Map each attribute to the matching field on the Okta user profile. Map the manager attribute from the profile field that holds the manager's email address.
- Open your Section enterprise application, select Provisioning, and open Attribute Mapping for users.
- Confirm the default mappings for
departmentandemployeeId(sent asemployeeNumber) are present. - For each custom attribute, including
manager_employee_id, select Advanced Options > Edit target User attributes and add an attribute namedurn:ietf:params:scim:schemas:extension:clerk:2.0:User:manager_employee_id(substituting the attribute name), typed as a string. Then add a mapping to it from the Entra user attribute that holds the value. - For
manager_employee_id, the source must be a field on each user that already holds their manager's employee ID as text, such as an extension attribute filled by your HR sync. Entra's built-in manager field cannot be the source, because its mappings cannot read another user's fields. If your users do not carry their manager's employee ID, skipmanager_employee_idand leave the default manager mapping in place. Section resolves the manager on its side. - If Edit target User attributes does not appear, Microsoft's guide on customizing attribute mappings explains how to enable the schema editor.
- Open the attribute mappings for your Section application or connector.
- Map
departmentandemployeeNumberto the enterprise schema. Its namespace isurn:ietf:params:scim:schemas:extension:enterprise:2.0:User. - For the manager, map the profile field that holds the manager's email address to
manager.valuein the same enterprise schema. Keep it as an email, not a name, because Section matches it to the manager's own email. - For each custom attribute, use the namespace
urn:ietf:params:scim:schemas:extension:clerk:2.0:Userand the attribute name from the tables above. Send each value as a string. - Provision your test user. Section checks where each value arrives and confirms the mapping with you before you assign everyone else.
Section confirms the values are arriving correctly before you rely on them in reporting.
FAQs
Do I need SSO before SCIM?
Yes. SCIM is configured on top of an existing SSO connection. See the SSO Connection Guide.
What happens when an employee is deactivated in our IdP?
The user is signed out of Section immediately and blocked from signing back in. Their history is preserved internally. If you need a deactivated user's seat reassigned, contact your Customer Success representative.
What happens when a deactivated employee is re-added in our IdP later?
The user is automatically reactivated and restored to their prior state - organization, role, and progress are preserved. No admin action is required.
Can we send additional employee attributes from our HR system (for example, Workday)?
Yes. Any attribute that exists on your IdP user profile can be delivered over the SCIM connection, including values your IdP imports from an HR system. Section does not need a separate HR-system integration. See "Reporting attributes" above, and coordinate with your Customer Success representative so the fields are enabled on Section's side before your first sync.
We already synced our users. Can we add reporting attributes now?
Yes. Contact your Customer Success representative so Section can turn the attributes on for your connection. Section then applies them to people who have already synced, using the values your IdP has sent. You do not need to edit users in your IdP or run a full re-sync.
What happens if we provision more users than our contracted seat count?
You will not experience a hard block at the IdP layer while this is resolved. Your Customer Success representative will reach out.
How are seat counts displayed?
Seat usage ("X of Y seats used") is visible in the Section HQ admin dashboard both before and after SCIM is connected. The count reflects users who have signed in to Section Coach at least once, measured against your contracted seats. Assigning users to Section in your IdP syncs their profiles to Section, but a user does not have a Section Coach account or use a seat until their first sign-in.
How are users who were provisioned but never logged in counted in reporting?
They are not included in reporting until their first sign-in. Provisioned users who have not yet signed in do not appear in headcounts, seat usage, engagement, or activation metrics, so unused provisioned accounts don't artificially depress your reported numbers. Profile attributes sent for them (such as department or job level) are stored and take effect in reporting once the user signs in.
Will SCIM-provisioned users be reported differently from users we added manually?
No. Reports do not split users by provisioning method. All users - manually added, self-enrolled, or SCIM-provisioned - appear in unified reporting.
How are SCIM errors surfaced if something fails after setup?
SCIM errors (malformed requests, failed provisioning events, etc.) are surfaced in an error log in the Section HQ admin dashboard. For broader or persistent issues, your Customer Success representative will be alerted and reach out.
Which IdP does Section use under the hood?
Clerk. Section's SCIM endpoint is provided by Clerk, which acts as the SCIM service provider on Section's behalf.
Can I disconnect SCIM?
Yes. To protect against accidental loss of provisioning, SCIM disconnection is handled through your Customer Success representative rather than self-serve. Contact them and Section will disable the SCIM connection; SSO will continue to work unaffected.
Updated 5 days ago