BetterUp Platform | Identity and Provisioning

	Question	Owned by (customer side)	What it produces
Identity	Who is a person, and should they have an account?	IT / IAM	A BetterUp account
Access	What product or program should this person get?	HR / Program team	A license and a program assignment

BetterUp supports several methods for each layer, and they compose: you pick one identity method and one access method. Deciding how accounts get created does not decide how licenses get assigned.

---

2. Identity methods: creating and maintaining accounts

SCIM 2.0

The industry standard for identity provisioning. The customer connects BetterUp as an application in their identity provider (Okta, Microsoft Entra ID) and user create, update, and deactivate flow to BetterUp automatically.

• Direction: push from the identity provider, near real-time
• Best for: IT-led deployments (where IdP drives group access), security-review requirements, fast deprovisioning on termination
• Customer needs: an identity provider that supports SCIM, and an IT owner to configure it. BetterUp product experiences aligned to IdP groups.
• Note: SCIM answers "does this person have access?" It does not typically carry rich HR data such as job level or department so it is common to use HCM integration in addition to SCIM.

Single sign-on with just-in-time account creation

The account is created the first time a person signs in through the customer's SSO. The identity provider's sign-in assertion carries attributes — called claims — and BetterUp reads them at that moment to decide whether to create the account and, optionally, what program to place the person in.

• Direction: member-initiated, real-time
• Best for: rolling or nomination-based programs where a person requests access rather than being loaded in a batch
• Customer needs: SSO configured, and the gating attribute exposed as a claim in the assertion
• Note: claims are read at sign-in, so this is the only method where provisioning happens at the moment of need rather than on a sync schedule.
• Important: because the claim is the authorization signal, the customer's identity provider becomes the control point for who gets a license. Whatever process adds the claim must be mirrored to remove it, or we could remove licensing via one of the other integration mechanisms, still in the identity pool.

HCM integration

BetterUp connects to the customer's HR system so employee data flows in on an agreed schedule. This is the method that brings employee attributes with it — job level, department, region, manager — which is what makes attribute-based eligibility, reporting, and personalization possible.

• Direction: scheduled, in both connection styles below
• Best for: Leveraging employee attributes rather than a simple yes/no entitlement; one connection to drive entitlement, member context, and reporting
• Customer needs: an HR system administrator to authorize the connection or produce the extract, and agreement on the field set

There are two ways to make the connection. The choice is about how data leaves the customer's system, not about what BetterUp does with it afterward — both land in the same place.

API connection. BetterUp connects directly to relevant systems and pulls on a schedule. Typically, this includes your HR system (Workday, SAP SuccessFactors, Oracle, UKG, etc.), but could also include custom-built integrations to other databases with information about your employees. This is the lower-effort path and the default recommendation.

File feed. The customer's HR system exports a file — commonly a nightly extract — to a secure location, and BetterUp ingests it. This gives the customer precise control over exactly which fields leave their system, which is why it remains common in regulated environments and with strict data-minimization requirements. It also covers HR systems without a supported API path. Setup is per-customer on both sides.

File upload

A one-time or occasional CSV upload handled by BetterUp. Supports a dry run before committing.

• Best for: pilots, one-off cohorts, migrations, and backfills — not an ongoing operating model

Admin invitations

A program administrator invites members directly, individually or in bulk. Not automated, but it is the baseline every deployment can fall back to and the right answer for small or highly curated populations.

---

3. Access methods: assigning products and programs

Attribute-based program assignment

Rules that read an employee attribute maintained in the customer's HR system and assign the matching program. A rule is an attribute plus a list of values mapped to a program. Different rules can key off different attributes.

• Pairs with: any HCM integration method
• Best for: a stable population split — by grade, level, region, business unit, or persona
• Customer needs: an attribute they will maintain accurately in their HR system, and an agreed mapping

SAML claim-based Program Assignment

The program is chosen from a claim in the customer's sign-in assertion. The customer maps a claim value to a program. One claim value maps to one program.

• Pairs with: SSO with just-in-time account creation, HCM integration, File Upload
• Best for: customers who already manage application entitlement by identity-provider group and want a set-once configuration with no roster file and no ongoing HR-system dependency
• Customer needs: SSO, plus a claim in the assertion whose value identifies the intended program. A group claim works well: the customer puts a person in the appropriate group, the group identifier arrives as the claim value.
• Two shapes in practice: a single-value gate (the claim is present and matches, so grant the one configured program) or a value-to-program map (different claim values route to different programs).
• Note: this assigns a program. While it is possible in some cases, this is not typically used for employee attributes. Customers who also want attributes for reporting or personalization typically need one of the HCM methods alongside it.

Eligibility rules with self-serve registration

A registration link the customer embeds in their own internal pages. When a person follows it, BetterUp checks eligibility before granting access — including whether they are flagged as eligible in the sign-in assertion, and whether they have already had coaching under the same program within a defined recency window. Ineligible people receive a clear message rather than a license.

• Pairs with: SSO with just-in-time account creation
• Best for: nomination or request-based programs, and any program with a "not more than once every N months" rule
• Customer needs: SSO with an eligibility attribute; a place to host the link
• Note: the recency and duplicate-access checks run on BetterUp's side. Customers building the same logic in their own HR system are duplicating something the platform already does.

Group-based access

Access driven by group membership rather than by an individual attribute. The customer manages a group in their identity provider; BetterUp maps that group to an experience.

• Pairs with: SCIM
• Best for: customers who already manage application access by group and want one place to control it
• Status: Scope of what a group can grant is narrower than attribute-based assignment

Attribute-change automation

Rules that watch for a change in an employee attribute and act on it — for example moving someone into a group when they are promoted, or out of one when they transfer.

• Pairs with: any HCM integration method
• Best for: keeping population segments current as the org changes
• Note: this handles group membership, not license assignment.

---

4. Choosing a combination

Combinations are common. A customer might run SCIM for identity so IT keeps control of accounts and deprovisioning, and an HCM integration alongside it to supply the attributes that drive program assignment and reporting. These are complementary, not competing.

---

Jump to: What to understand first | 2. Identity methods: creating and maintaining accounts | 3. Access methods: assigning products and programs | 4. Choosing a combination