The PLTW User Journey Today (Legacy)

Project Lead The Way (PLTW) is a nonprofit that provides STEM curriculum to K-12 schools across the United States. PLTW instructors are a significant source of leads for SolidProfessor's education business. Here is how the pipeline works today:

1. An instructor is on PLTW's website and discovers SolidProfessor through a partner link.
2. The instructor clicks through and signs up for an individual SolidProfessor account — not a school account, just a personal one.
3. On the SP login page, the instructor can use the "Login with PLTW" button, which authenticates them through PLTW's Okta instance using a custom OAuth 2.0 flow.
4. The new user is automatically tagged as an "SP Web" lead in Salesforce, flagged as PLTW-sourced.
5. The sales team reaches out to the instructor and attempts to convert them to an EDU (education) account.
6. If converted, a school account is created and the user becomes an Instructor with access to classes, student management, and reporting.

What Platform 2.0 Supports Today

Platform 2.0 (the Nuxt 2 / Vue 2 frontend) has a modern SAML SSO implementation for enterprise accounts. Here's how it currently works and where the gaps are for PLTW:

SAML SSO (Company & School Accounts)

SAML is fully supported for company and school accounts only. An admin configures SAML via Account → SAML Configuration → Email Domains in platform-admin. When a user logs in, their email domain is detected, they're routed to their organization's Identity Provider, and upon successful authentication they are auto-provisioned into the company/school account.

Individual Accounts

Individual accounts support email/password or social login (Google, LinkedIn). There is no SAML support for individual accounts — the platform-admin UI explicitly filters out SAML onboarding strategies for individual account types.

PLTW OAuth in Platform 2.0 — Dead Code

While PLTW OAuth was fully working in the legacy application (legacy-app/ with hardcoded credentials in OauthPLTW.php), the integration was only partially ported to Platform 2.0. Class files exist in platform-backend (PltwServiceProvider.php, OAuthProvider.php enum), but the integration was never fully wired up:

• platform-frontend: The PLTW login button is not rendered — LoginForm.vue's socialMediaButtons array only includes Google, LinkedIn, and SAML. CSS and logo assets exist in SocialLoginButton.vue but are unreachable.
• platform-backend Socialite driver: Not registered — EventServiceProvider.php only registers Cognito; no PLTW handler is wired.
• platform-backend config URLs: Missing — config/urls.php has no urls.pltw.* entries.
• platform-backend credentials: Missing — config/services.php has no PLTW client_id or client_secret. (The legacy app had these hardcoded in OauthPLTW.php.)

Gap Analysis

How It Works

Create a single academic account for PLTW in platform-admin and configure SAML SSO against PLTW's Okta instance. All PLTW instructors would land in this shared "umbrella" account as Learners. When sales converts an instructor, they manually move the user to the instructor's own school EDU account.

Implementation

No code changes required — this is purely configuration:

• Create a PLTW academic account in platform-admin
• Configure SAML SSO with PLTW's Okta IdP metadata
• Map PLTW email domains to this account in AWS Cognito
• All PLTW-authenticated users auto-provision into this holding account

How It Works

PLTW OAuth was fully working in the legacy application but was only partially ported to Platform 2.0 (see Page 3). This option completes that port — wiring up the platform-backend Socialite driver, adding configuration and credentials, and adding the "Login with PLTW" button to platform-frontend. Individual accounts are created exactly as the legacy flow works today.

Implementation

1. Register the PLTW Socialite driver in EventServiceProvider.php — create a PltwExtendSocialite event handler (currently only Cognito is registered).
2. Add PLTW endpoint URLs to config/urls.php — add urls.pltw.authorize, urls.pltw.token, and urls.pltw.userinfo entries.
3. Add PLTW client credentials to config/services.php — wire client_id and client_secret from environment variables.
4. Configure environment variables for PLTW OAuth endpoints and credentials across all deployment environments.
5. Add PLTW to the socialMediaButtons array in LoginForm.vue to render the "Login with PLTW" button on the Platform 2.0 login page.
6. Verify PLTW's Okta OAuth endpoints are still active and accepting client credentials — coordinate with PLTW if endpoints have been decommissioned.
7. Test the full flow: PLTW login → OAuth redirect → callback → individual account creation → session.

How It Works

Extend the platform to allow individual accounts to have SAML configurations. Today, SAML is only available for company and school accounts because the admin UI and backend logic explicitly filter it out for individual account types. This option removes those restrictions and creates a new provisioning path for individual SAML users.

Implementation

1. Platform-admin: Remove the filteredOnboardingStrategies filter in AccountForm.vue (line ~607-615) that blocks SAML strategies for individual accounts.
2. Backend: Update AuthenticationController SAML callback to handle individual accounts — skip the ProvisionUserToCompany step and create an individual account instead.
3. Backend: Update SamlEmailValidation rule to not require a Company. Allow AccountDomain records without a Company association.
4. Create a new onboarding strategy variant for individual SAML that handles the "create individual account, not company member" flow.

How It Works

Combine the best of both worlds: keep PLTW OAuth for the initial individual signup (preserving the lead-gen funnel), and when sales converts an instructor to EDU, set up SAML SSO on the school account. Build an "account conversion" tool in platform-admin to streamline the Individual → EDU transition that sales performs today manually.

Phased Implementation

Phase 1 — PLTW OAuth in Platform 2.0

Same as Option B: complete the PLTW OAuth integration (backend wiring + frontend button).

• Register Socialite driver, configure endpoints and credentials (see Option B steps 1–4)
• Add PLTW social login button to Platform 2.0 login page
• Verify OAuth callback creates individual accounts correctly
• Tag PLTW-sourced users for Salesforce lead tracking

Phase 2 — Account Conversion Tool

Build a tool in platform-admin for the sales-to-EDU workflow:

• Select individual user → create or assign to a school account
• Change user role from Individual to Instructor
• Migrate user data (progress, certificates) to the new account context
• Optionally configure SAML SSO on the school account

Phase 3 — Lead Tracking

Ensure full visibility for the sales pipeline:

• Tag PLTW-sourced users automatically in Salesforce
• Dashboard for sales to view PLTW leads and conversion status

Recommendation Matrix

* Option D Phase 1 delivers the same value as Option B in 2–3 weeks. Full value (conversion tool) takes longer.

Open Questions for Team Discussion

1. Is the PLTW OAuth endpoint still active? We need to verify that PLTW's Okta instance still accepts our OAuth client credentials. If not, Options B and D (Phase 1) require coordination with PLTW.
2. How does sales currently "convert" Individual → EDU? Understanding the manual process helps us assess the value of the conversion tool in Option D and informs whether we need it regardless of the PLTW decision.
3. Do we need individual SSO for other partners beyond PLTW? If yes, Option C becomes more attractive as a generic solution. If PLTW is unique, the cost of Option C may not be justified.
4. What's the priority: quick win or long-term solution? Options A and B can be delivered immediately. Options C and D solve deeper architectural problems but take longer. The answer depends on when the legacy frontend is being retired.