Grow LMS API Documentation

Grow by Plenum — SSO & Identity Integration

Letting your people sign in with the credentials they already have, governed by your IT organization.

This document is for the identity and access management owners evaluating how Grow by Plenum fits into your existing sign-on and identity stack. It covers the standards Grow supports, the path for the most common identity providers, how an authenticated identity maps to a learner record, and what gets decided together during onboarding.

Throughout, <SCHOOL_ID> is your dedicated Grow environment. Specific attribute mappings and provider settings are confirmed with your IT team during setup; this document describes the supported model.

1. The short version

Grow supports enterprise single sign-on, so learners authenticate against your identity provider rather than maintaining a separate Grow password. For a workforce-compliance program, that matters for three reasons:

• One set of credentials. Employees sign in with the corporate identity they already use — nothing new to issue, remember, or reset.
• Central governance. Who can access training is governed where you already govern access — in your identity provider — rather than as a separate list inside the LMS.
• Cleaner audit. Sign-in is tied to your directory identity, which keeps your completion and certification records anchored to a person your systems already recognize.

Behind the scenes, SSO is delivered through a Plenum-managed identity layer. Your identity provider federates into that layer once; it then brokers authenticated sign-in into your <SCHOOL_ID> environment consistently and securely. This is why any standards-based IdP works, and why your team integrates once with a managed surface rather than wiring directly into the LMS. That layer speaks the two standards covering essentially every enterprise IdP: SAML and OIDC.

2. Supported standards

Either standard establishes the same outcome — a trusted, IdP-asserted sign-in brokered into your Grow environment. The choice is normally dictated by what your identity provider speaks, not by a limitation on our side. If your IdP supports both, we’ll pick the one that’s simplest to operate for your environment.

3. Google Workspace — a dedicated path

If your organization runs on Google Workspace, there is a named, documented integration path via OIDC — not a generic “configure it yourself” route. This is the smoothest setup of the common options: your Workspace tenant federates into the managed identity layer, and your people sign in to Grow with their existing Google accounts.

Standards-based OIDC sign-on is the mechanism Plenum already operates for Grow SSO today, so this is a path we run in production rather than a spec we’re reading for the first time.

4. Other identity providers

Beyond Google Workspace, any IdP that speaks SAML or OIDC — Okta, Microsoft Entra ID, Ping, OneLogin, and the like — integrates through the same standards. The general pattern is the same in every case:

1. Establish trust between your IdP and Plenum’s managed identity layer (exchange the standard metadata/keys) — done once, then it brokers into your <SCHOOL_ID> environment.
2. Map the identity attributes your IdP asserts (email, name, and any attributes you want carried into Grow) to the corresponding learner fields.
3. Test a sign-in end to end, then enable it for your population.

We don’t need a pre-built, vendor-specific connector for this — that’s the point of standards-based SSO. If your IdP speaks SAML or OIDC, it’s in scope.

5. How identity maps to a learner record

Authentication establishes who someone is; the learner record is what Grow knows about them for training purposes. When a person signs in via SSO, their session is associated with a Grow learner record that carries the attributes your reporting depends on — identity and contact details, tags, custom fields, and role level.

This is where SSO and your data integration meet: the organizational attributes you assert at sign-in (or maintain on the learner record) — region, crew, job classification, employee ID — travel with every completion and certificate your integration later consumes (see Pull-Based Data Access and Webhooks). So the same identity that signs in is the identity your compliance reporting is keyed to, end to end.

6. What we decide together at onboarding

SSO is standards-based but not one-size-fits-all. A short setup conversation with your IT team settles the specifics:

• Which standard (SAML or OIDC) and which IdP.
• Attribute mapping — exactly which asserted attributes populate which learner fields, including any custom fields or tags you want to drive cohorts.
• Account handling — how a first-time SSO sign-in is matched to or used to create a learner record, and how that aligns with any learners already provisioned via the API.
• Access governance — because sign-in is delegated to your IdP, disabling a person in your directory prevents future sign-in; we’ll confirm together how that interacts with your enrollment and reporting requirements.

None of these require custom code — they’re configuration decisions, captured once per environment.

7. Where to go next

• Authentication & Access Setup — how systems (as opposed to people) authenticate to Grow’s API.
• Integrations & Notifications — where SSO sits in the broader integration picture.
• Pull-Based Data Access — how the identity that signs in becomes the identity your reporting consumes.

Prepared by Plenum Solutions for your evaluation. “Grow by Plenum” is operated and supported by Plenum on your behalf. Specific identity-provider configuration is confirmed for your environment during onboarding. For integration design support, contact your Plenum engagement lead.