SCIM Connection Guide
Overview
Section Coach (formerly, "ProfAI") supports SCIM 2.0-based Directory Sync for enterprise clients. Once enabled, employees provisioned in your identity provider (IdP) are automatically created in Section Coach, and deactivations in your IdP automatically revoke access - eliminating the need for CSV imports or manual user management.
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, that user is provisioned in Section Coach and can sign in immediately.
- 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 IdP, it will still work. Contact your Customer Success representative and we will help you map the steps to your provider.
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.
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.
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.
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 |
|---|---|
| User ID | id |
| Email address | emails[0].value |
| First name | name.givenName |
| Last name | name.familyName |
Reporting attributes (optional)
Section can also receive additional employee profile attributes over the same SCIM connection. This is the recommended way to bring your HR and org data into Section. These power team and manager breakdowns in Section's reporting (for example, adoption and proficiency broken out by department). They are optional: provisioning works without them, and users without a value simply appear ungrouped in the corresponding report views.
For org-based reporting, send these two:
| Section field | Attribute name |
|---|---|
| Department | department |
| Manager ID | manager_id |
Other common fields we can enable for deeper reporting are below. Tell 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 field | Attribute name |
|---|---|
| Job level | job_level |
| Management level | management_level |
| Business unit | business_unit |
| Employee type | employee_type |
| Hire date | hire_date |
| Location | location |
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.
Some of the reporting attributes (for example, job_level and management_level) fall outside the standard SCIM schema, so your IdP defines them as custom attributes. If your IdP asks for an External Namespace when you add one, use:
urn:ietf:params:scim:schemas:extension:clerk:2.0:UserEnter the attribute name from the tables above (for example, job_level) as the External Name, typed as a string.
Section provides the exact attribute-mapping steps for your identity provider during setup, and 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.
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 provisions their accounts, but a provisioned user does not consume 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 8 days ago