Case Study 04: EduPath Learning Solutions — Worked Solution

AI-Generated Content — Use for Reference Only

This content is AI-generated and has only been validated by AI review processes. It has NOT been reviewed or validated by certified Salesforce CTAs or human subject matter experts. Do not rely on this content as authoritative or completely accurate. Use it solely as a reference point for your own study and preparation. Always verify architectural recommendations against official Salesforce documentation.

Solution Context

Heavy domains: D1 System Architecture, D4 Solution, D5 Integration | Difficulty: Intermediate Time budget: 180 minutes | Key frameworks: 9 Essential Artifacts

Attempt the Scenario First

If you have not yet worked through the scenario paper, stop here. Set a 180-minute timer and build your own solution before reading this one.

Assumptions

1. Single Salesforce org — Sales Cloud (B2B pipeline), Service Cloud (learner support), Experience Cloud (two portals: corporate admin + instructor). Covers all business requirements without multi-org complexity.
2. LMS remains system of record for course content, video delivery, assessments, and grading. Salesforce stores summarized learner data (enrollments, completions, certifications) — not raw progress events.
3. MuleSoft Anypoint for integration — bidirectional LMS sync, Stripe, HubSpot, Zoom, and DocuSign. Rejected point-to-point Apex callouts given 5+ external systems and bidirectional data flows.
4. Auth0 stays as learner IdP — Salesforce trusts Auth0 via OIDC for portal users. Employees authenticate via Google Workspace SAML. Corporate clients federate via their own SAML IdP.
5. Shield Platform Encryption + custom consent framework for FERPA/GDPR/Privacy Act — no single product covers all three jurisdictions, so a combination of Shield encryption, field-level security, custom consent objects, and automated retention policies.

Key Architectural Decisions

Decision 1: LMS Integration Pattern (D5)

The LMS holds 42M progress events. Salesforce does not need raw progress data — it needs summarized metrics for sales conversations, support context, and corporate dashboards.

Pattern: Event-driven inbound (LMS to SF) + request-reply outbound (SF to LMS).

• LMS publishes webhook events on enrollment, milestone completion, course completion, certification earned, and assessment final score
• MuleSoft receives events, transforms to Salesforce canonical model, upserts to Salesforce
• Salesforce sends enrollment/unenrollment requests to LMS via MuleSoft when corporate admins act through the portal
• Daily batch sync reconciles enrollment counts and completion stats as a safety net

Trade-off: Salesforce does not have granular lesson-by-lesson progress. Corporate dashboards show completion percentages and milestones, not “learner watched 47% of video 3.” This is sufficient for renewal conversations and training manager dashboards.

Decision 2: Multi-Portal Architecture (D4)

Two Experience Cloud portals on a single org:

• Corporate Portal (Customer Community Plus): training managers and corporate admins manage enrollments, view dashboards, download reports. Licensed per corporate admin user (~2,000 active admins across 15K accounts).
• Instructor Portal (Partner Community): 45 content creators view course performance, revenue share, and student feedback. Partner Community licenses.

Individual learners do NOT get a Salesforce portal. They use the LMS directly (Auth0 authenticated). Corporate training managers see aggregated data in Salesforce — individual learners interact only with the LMS.

Trade-off: No Salesforce-based learner portal eliminates a 250K-user licensing problem. Corporate admins (~2K) and instructors (45) are manageable portal populations.

Decision 3: FERPA Compliance Architecture (D2)

FERPA applies to K-12 partnerships only (subset of corporate accounts). Architecture:

• K12_Partnership__c flag on Account identifies FERPA-scoped accounts
• Learner records under K-12 accounts tagged with FERPA_Protected__c = true
• Restriction Rules limit FERPA-tagged learner data to users with “K12 Data Access” permission set
• Shield Platform Encryption on learner PII fields (name, email, date of birth)
• Consent object tracks parental consent with version, date, and withdrawal capability
• Shield Event Monitoring for audit trail on all FERPA record access

Must be operational by month 6 — this drives Phase 1 scope.

Artifact 1: System Landscape

graph TB
    subgraph Legend["Legend"]
        L1["🟢 NEW system"]
        L2["⚪ KEEPING as-is"]
        L3["🔴 RETIRING"]
        L4["🟠 INTEGRATION LAYER"]
    end

    subgraph SF["Salesforce Org"]
        SC[Sales Cloud]
        SVC[Service Cloud]
        EC1[Experience Cloud<br/>Corporate Portal ~2K admins]
        EC2[Experience Cloud<br/>Instructor Portal 45]
        Shield[Shield — Encryption + Audit]
        CRMA[CRM Analytics]
    end

    subgraph MW["MuleSoft Anypoint"]
        EXP[Experience APIs]
        PROC[Process APIs]
        SYS[System APIs]
    end

    subgraph EXT["External Systems"]
        LMS[Custom LMS — AWS]
        ST[Stripe]
        HB[HubSpot]
        DS[DocuSign]
        ZM[Zoom]
    end

    subgraph ID["Identity"]
        AUTH0[Auth0]
        GOOG[Google Workspace]
        CORP_IDP[Corporate IdPs]
    end

    subgraph RET["Retiring"]
        ZD[Zendesk]
    end

    SF <-->|"REST / Bulk API"| MW
    EC1 -->|"REST"| EXP
    EXP --> PROC
    PROC --> SYS
    SYS <-->|"REST webhooks + API — bidirectional"| LMS
    SYS <--|"REST webhooks — payment events"| ST
    SYS <--|"REST API — hourly lead sync"| HB
    SYS <-->|"REST — on-demand contracts"| DS
    SYS <--|"REST webhook — attendance"| ZM
    GOOG -->|"SAML 2.0 SSO"| SF
    AUTH0 -->|"OIDC"| EC1
    CORP_IDP -->|"SAML federation"| EC1
    LMS -->|"Webhooks — enrollment, completion, cert"| MW
    ZD -.->|"Migrating 180K tickets to Service Cloud"| SVC

    classDef newSystem fill:#d4edda,stroke:#28a745,color:#000
    classDef keepSystem fill:#f8f9fa,stroke:#6c757d,color:#000
    classDef retireSystem fill:#f8d7da,stroke:#dc3545,color:#000,stroke-dasharray:5 5
    classDef integrationLayer fill:#fff3cd,stroke:#fd7e14,color:#000
    classDef sfSystem fill:#cce5ff,stroke:#0d6efd,color:#000

    class SF,SC,SVC,EC1,EC2,Shield,CRMA sfSystem
    class MW,EXP,PROC,SYS integrationLayer
    class LMS,ST,HB,DS,ZM keepSystem
    class AUTH0,GOOG,CORP_IDP keepSystem
    class ZD retireSystem
    class L1 newSystem
    class L2 keepSystem
    class L3 retireSystem
    class L4 integrationLayer

Artifact 2: Data Model

erDiagram
    ACCOUNT ||--o{ CONTACT : has
    ACCOUNT ||--o{ OPPORTUNITY : generates
    ACCOUNT ||--o{ CONTRACT : signs
    ACCOUNT ||--o{ LICENSE_ALLOCATION : holds
    CONTACT ||--o{ ENROLLMENT : enrolled_in
    ENROLLMENT }o--|| COURSE : for_course
    ENROLLMENT ||--o{ COMPLETION : achieves
    CONTACT ||--o{ CERTIFICATION : earns
    COURSE ||--o{ COURSE_METRIC : tracked_by
    COURSE }o--|| INSTRUCTOR : taught_by
    INSTRUCTOR ||--o{ REVENUE_SHARE : earns
    CASE ||--o{ CONTACT : reported_by
    CONTACT ||--o{ CONSENT_RECORD : governs

    ACCOUNT {
        string Type "B2B / K12 / Individual"
        boolean K12_Partnership
        string Region "US / UK / AU"
        number Health_Score
    }
    ENROLLMENT {
        string LMS_Enrollment_Id
        picklist Status "Active / Completed / Dropped"
        percent Completion_Pct
        date Enrolled_Date
    }
    CERTIFICATION {
        string Certification_Name
        date Earned_Date
        date Expiry_Date
        boolean Active
    }
    COURSE {
        string LMS_Course_Id
        string Track
        number Avg_Rating
        number Total_Enrollments
    }
    CONSENT_RECORD {
        picklist Regulation "FERPA / GDPR / Privacy_Act"
        picklist Status "Granted / Withdrawn"
        date Consent_Date
        boolean Parental
    }

• Enrollment is the bridge between Contact (learner) and Course. Stores summarized progress from LMS, not granular events.
• Course and Course Metric store aggregate performance data synced from LMS daily.
• License Allocation tracks how many seats a corporate account has purchased vs. consumed.
• Consent Record handles multi-jurisdiction consent tracking with regulation-specific logic.
• Certification is separate from Enrollment — a learner may have multiple enrollments contributing to one certification.

Artifact 3: Role Hierarchy & Sharing Model

graph TB
    CEO --> CRO
    CEO --> VPCS["VP Customer Success"]
    CEO --> VPEng["VP Engineering"]
    CEO --> Legal
    CRO --> USSales["US Sales Mgr"]
    CRO --> UKSales["UK Sales Mgr"]
    CRO --> AUSales["AU Sales Mgr"]
    USSales --> USReps["US Sales Reps"]
    UKSales --> UKReps["UK Sales Reps"]
    AUSales --> AUReps["AU Sales Reps"]
    VPCS --> SvcMgr["Service Manager"]
    SvcMgr --> CorpAgents["Corporate Support Agents"]
    SvcMgr --> IndAgents["Individual Support Agents"]
    VPCS --> CSMMgr["CSM Manager"]
    CSMMgr --> CSMs["Customer Success Managers"]

Object	OWD	Mechanism
Account	Private	Territory Management (US / UK / AU)
Contact	Controlled by Parent	Inherits from Account
Opportunity	Private	Owner-based + sharing rules for team selling
Enrollment	Controlled by Parent	Inherits from Contact (which inherits from Account)
Case	Private	Assignment rules + queue-based sharing
Course	Public Read Only	All internal users can view
Certification	Controlled by Parent	Inherits from Contact
Consent Record	Private	K12 Data Access permission set only

Portal sharing: Customer Community Plus uses sharing sets. Corporate admin sees only their own Account’s Contacts, Enrollments, and Certifications via Account relationship.

FERPA restriction: Restriction Rules on Contact and Enrollment where FERPA_Protected__c = true — only users with “K12 Data Access” permission set can view.

Artifact 4: Integration Architecture

graph LR
    subgraph Legend["Legend"]
        L1["🟢 NEW"]
        L2["⚪ KEEPING"]
        L3["🟠 INTEGRATION LAYER"]
    end

    subgraph SF["Salesforce"]
        PE[Platform Events]
        CDC[Change Data Capture]
        API[REST API + Bulk API]
    end

    subgraph Mule["MuleSoft Anypoint"]
        EXP["Experience APIs"]
        PROC["Process APIs"]
        SYS["System APIs"]
        AMQ[Anypoint MQ]
    end

    subgraph Systems["External Systems"]
        LMS["Custom LMS — AWS"]
        STR[Stripe]
        HUB[HubSpot]
        DOC[DocuSign]
        ZOM[Zoom]
    end

    LMS -->|"REST webhooks — enrollment,<br/>completion, certification events"| SYS
    SYS -->|"REST API — enroll/unenroll requests"| LMS
    EXP -->|"REST API upsert"| API
    PE -->|"Platform Events — enrollment actions"| EXP
    CDC -->|"CDC — account/contact changes"| EXP
    EXP --> PROC
    PROC --> SYS
    PROC -->|"Async queue — retry + DLQ"| AMQ
    AMQ --> SYS
    STR -->|"REST webhooks — real-time payment events"| SYS
    HUB -->|"REST API — hourly lead sync + MQL events"| SYS
    SYS <-->|"REST — on-demand contract generation"| DOC
    SYS <--|"REST webhook — post-session attendance"| ZOM

    classDef keepSystem fill:#f8f9fa,stroke:#6c757d,color:#000
    classDef integrationLayer fill:#fff3cd,stroke:#fd7e14,color:#000
    classDef sfSystem fill:#cce5ff,stroke:#0d6efd,color:#000
    classDef newSystem fill:#d4edda,stroke:#28a745,color:#000

    class SF,PE,CDC,API sfSystem
    class Mule,EXP,PROC,SYS,AMQ integrationLayer
    class LMS,STR,HUB,DOC,ZOM keepSystem
    class L1 newSystem
    class L2 keepSystem
    class L3 integrationLayer

System	Pattern	Direction	Protocol	Frequency
LMS	Event-driven + request-reply	Bidirectional	REST webhooks + REST API via MuleSoft	Real-time events + daily batch reconciliation
Stripe	Event-driven	Inbound	Webhooks to MuleSoft	Real-time payment events
HubSpot	Batch + event	Inbound (leads)	REST API via MuleSoft	Hourly lead sync + real-time MQL events
DocuSign	Request-reply	Bidirectional	REST via MuleSoft	On-demand (contract generation/signing)
Zoom	Event-driven	Inbound	REST webhook (attendance)	Post-session attendance sync

LMS sync detail: MuleSoft receives LMS webhook events (enrollment created, milestone reached, course completed, certification earned, assessment scored). Each event maps to a canonical Learner Event schema. MuleSoft upserts Enrollment, Completion, and Certification records using LMS_Enrollment_Id__c and LMS_Course_Id__c as external IDs. Daily batch reconciliation compares Salesforce enrollment counts per account against LMS totals, flagging discrepancies.

Corporate enrollment flow: Corporate admin enrolls employees via portal. Salesforce publishes a Platform Event. MuleSoft subscribes, calls LMS enrollment API, receives confirmation, updates Enrollment record status.

Artifact 5: Identity & SSO

graph LR
    subgraph Users["User Populations"]
        EMP[800 Employees]
        CORP[~2,000 Corporate Admins]
        INST[45 Instructors]
        LEARN[250K Learners]
    end

    subgraph IdPs["Identity Providers"]
        GOOG[Google Workspace]
        AUTH0[Auth0]
        CIdP[Corporate IdPs]
    end

    subgraph SF["Salesforce"]
        CORE[Core Org]
        CP[Corporate Portal]
        IP[Instructor Portal]
    end

    EMP -->|SAML 2.0| GOOG -->|SSO| CORE
    CORP -->|SAML Federation| CIdP -->|SSO| CP
    CORP -->|Auth0 fallback| AUTH0 -->|OIDC| CP
    INST -->|SAML 2.0| GOOG -->|SSO| IP
    LEARN -->|Auth0 OIDC| AUTH0 -->|LMS only| LMS[LMS]

• Employees (800): Google Workspace SAML 2.0 for Salesforce core org. SCIM not needed at 800 users — manual provisioning with JIT attribute updates.
• Corporate portal admins (~2,000): Two auth paths. Large enterprise clients federate via their own SAML IdP (Connected App per client). Smaller companies use Auth0 (same credentials as LMS). Auth0 as fallback ensures all corporate admins can access the portal.
• Instructors (45): Google Workspace SAML into Partner Community (same IdP as employees, different profile).
• Individual learners (250K): Auth0 for LMS only. No Salesforce portal access — eliminates 250K-user licensing and auth complexity.

MFA: Enforced for all Salesforce internal users. Portal users via enterprise IdP inherit their corporate MFA. Auth0 portal users require TOTP or SMS second factor.

Artifact 6: Data Migration Strategy

Phase 1 (Months 1-6):

1. HubSpot: Migrate 15K company records as Accounts, 450K contacts (deduplicate against LMS learner data using email match). Contacts without corporate Account association become Person Accounts or are excluded based on engagement score (inactive >12 months excluded). HubSpot marketing automation continues — MuleSoft syncs new MQLs going forward.
2. LMS initial load: Bulk extract of 250K active learners as Contacts (matched to Accounts where corporate), 1.8M enrollments, 85 courses, active certifications. Progress events are NOT migrated — only current completion percentages per enrollment.
3. FERPA framework: Consent objects, restriction rules, Shield encryption deployed and validated before K-12 launch at month 6.

Phase 2 (Months 4-12):

4. Zendesk: 180K historical tickets migrated as read-only Cases (closed status, archived). Active tickets cut over during a maintenance window — MuleSoft dual-writes for 2-week parallel period.
5. Stripe: No bulk migration. MuleSoft syncs active subscription status and payment events going forward. Historical payment data remains in Stripe (accessible via API if needed).
6. DocuSign: Connect via MuleSoft for new contracts. Historical contracts remain in DocuSign with links stored on Account/Contract records.

Phase 3 (Months 10-18):

7. Zoom attendance: Historical not migrated. Real-time sync from month 10 onward.
8. HubSpot decommission assessment: Evaluate whether HubSpot can be replaced by Marketing Cloud or Pardot, or remains for top-of-funnel.

Data volume management: 42M LMS progress events stay in LMS. Salesforce holds ~2M enrollment records, ~500K certification records, ~15K accounts — well within standard limits. Growth at 20% YoY is manageable for 3+ years without LDV strategies.

Artifact 7: Governance

Architecture Review Board (ARB): Bi-weekly. VP Engineering (chair), IT Director, SI lead architect, Legal representative. Reviews integration changes, data model modifications, security configurations.

Change Type	Approval	Lead Time
Data model / integration	ARB	2 sprints
Portal configuration	IT Director	1 sprint
Privacy / compliance	ARB + Legal	2 sprints
Emergency fix	IT Director + VP Eng	Same day

Standards:

• Naming: EP_[Object]_[Purpose] (e.g., EP_Enrollment_CompletionSync)
• All integrations through MuleSoft — no direct Apex callouts to external systems
• 85% Apex test coverage minimum
• All Flows documented in a central registry

Center of Excellence: Given the small team (12 internal + 15 SI), establish a 3-person CoE (1 architect, 1 admin, 1 integration lead) to own standards and train the broader team. SI partner handles build; CoE ensures knowledge transfer.

Artifact 8: Environment Strategy

Environment	Purpose	Refresh
Full Copy Sandbox	UAT + performance testing	Monthly
Partial Copy	Integration testing (LMS, Stripe, HubSpot)	Bi-weekly
Developer Sandbox (x2)	Core team + SI partner	Sprint start
Developer Pro Sandbox	Portal development + testing	Sprint start

CI/CD: Salesforce CLI + GitHub + GitHub Actions. Branch strategy: main (prod), release/* (UAT), feature/* (dev). All deployments automated — no manual metadata moves.

LMS integration testing: Dedicated LMS staging environment mirrors production data structure. MuleSoft CloudHub sandbox connects Salesforce Partial Copy to LMS staging for end-to-end integration testing.

Privacy testing: Full Copy sandbox with data masking for learner PII. FERPA consent workflows tested with synthetic K-12 data.

Artifact 9: Phased Delivery Roadmap

gantt
    title EduPath — 18-Month Delivery
    dateFormat  YYYY-MM
    axisFormat  %b %Y

    section Phase 1 — Foundation
    Salesforce org setup + data model     :p1a, 2026-05, 2M
    Sales Cloud + territory config        :p1b, 2026-06, 2M
    MuleSoft + LMS integration            :p1c, 2026-05, 4M
    HubSpot migration                     :p1d, 2026-07, 2M
    FERPA compliance framework            :p1e, 2026-06, 3M
    FERPA Go-Live                         :milestone, m1, 2026-10, 0d

    section Phase 2 — Service + Portals
    Service Cloud + Zendesk migration     :p2a, 2026-09, 4M
    Corporate Portal (Exp Cloud)          :p2b, 2026-10, 4M
    Instructor Portal (Exp Cloud)         :p2c, 2027-01, 3M
    Stripe + billing integration          :p2d, 2026-10, 3M
    Portals Live                          :milestone, m2, 2027-04, 0d

    section Phase 3 — Analytics + Optimization
    CRM Analytics dashboards              :p3a, 2027-03, 3M
    GDPR + Privacy Act hardening          :p3b, 2027-03, 2M
    Mobile optimization                   :p3c, 2027-05, 2M
    Zoom attendance integration           :p3d, 2027-05, 2M
    Program Complete                      :milestone, m3, 2027-10, 0d

    section Cross-Cutting
    LMS ongoing sync + reconciliation     :cc1, 2026-05, 18M
    Training + change management          :cc2, 2026-06, 14M

Sequencing rationale: FERPA drives Phase 1 deadline — K-12 partnerships cannot launch without it. LMS integration starts month 1 because every subsequent phase depends on learner data flowing into Salesforce. Service Cloud and portals overlap in Phase 2 because portal users will generate support cases. GDPR/Privacy Act hardening in Phase 3 because UK and AU operations already function (compliance is improvement, not blocker). Analytics last because it requires data maturity across all integrated systems.

Identity & SSO Flow

sequenceDiagram
    participant EmpBrowser as Employee Browser
    participant Google as Google Workspace
    participant SF as Salesforce Core Org
    participant CorpAdmin as Corporate Admin
    participant CorpIdP as Corporate SAML IdP
    participant Auth0 as Auth0
    participant CorpPortal as Corporate Portal (EC)
    participant Instructor as Instructor
    participant InstPortal as Instructor Portal (EC)
    participant MuleSoft as MuleSoft (System-to-System)

    rect rgb(230, 240, 255)
    Note over EmpBrowser,SF: Internal Employee SSO (800 users)
    EmpBrowser->>Google: Navigate to Salesforce (SP-initiated)
    Google->>Google: Authenticate (Google MFA)
    Google->>EmpBrowser: SAML 2.0 Assertion
    EmpBrowser->>SF: POST Assertion to ACS URL
    SF->>SF: JIT attribute update (role, territory)
    SF->>EmpBrowser: Session established
    end

    rect rgb(230, 255, 230)
    Note over CorpAdmin,CorpPortal: Corporate Portal — Federated Enterprise Client
    CorpAdmin->>CorpPortal: Navigate to Corporate Portal
    CorpPortal->>CorpIdP: SAML redirect (SF as SP)
    CorpIdP->>CorpIdP: Corporate SSO + MFA
    CorpIdP->>CorpPortal: SAML Assertion
    CorpPortal->>CorpPortal: Match to portal user, apply sharing set
    CorpPortal->>CorpAdmin: Account-scoped learner dashboard
    end

    rect rgb(255, 245, 230)
    Note over CorpAdmin,CorpPortal: Corporate Portal — Auth0 Fallback
    CorpAdmin->>Auth0: Login (same credentials as LMS)
    Auth0->>Auth0: Authenticate + MFA (TOTP/SMS)
    Auth0->>CorpPortal: OIDC token
    CorpPortal->>CorpPortal: Map to portal user, apply sharing set
    CorpPortal->>CorpAdmin: Account-scoped learner dashboard
    end

    rect rgb(245, 235, 250)
    Note over Instructor,InstPortal: Instructor Portal (45 users)
    Instructor->>Google: Navigate to Instructor Portal (SP-initiated)
    Google->>Google: Authenticate (Google MFA)
    Google->>InstPortal: SAML 2.0 Assertion
    InstPortal->>InstPortal: Partner Community profile applied
    InstPortal->>Instructor: Course metrics + revenue share dashboard
    end

    rect rgb(240, 240, 240)
    Note over MuleSoft,SF: System-to-System Integration Auth
    MuleSoft->>SF: OAuth 2.0 Client Credentials
    SF->>MuleSoft: Access token (integration user)
    MuleSoft->>SF: API calls (REST / Platform Events / Bulk)
    end

Identity architecture rationale:

• Google Workspace SAML 2.0 for 800 internal employees. Google is already the corporate IdP (per paper). JIT attribute updates on login map Google Workspace groups to Salesforce territory assignments (US, UK, AU) and role-based Permission Set Groups. At 800 users, SCIM provisioning is not strictly necessary — manual user provisioning with JIT attribute sync is sufficient and avoids SCIM setup complexity.
• Corporate portal (two auth paths): Large enterprise clients (major tech companies, consulting firms) federate via their own SAML IdP — a Connected App is created per federated client with Salesforce as SP. Smaller companies and individual corporate admins use Auth0 (OIDC) — the same credentials they already use for LMS access. This dual path ensures all ~2,000 corporate admins can access the portal without forcing every company through SAML federation setup. MFA enforced on both paths: corporate MFA for federated, Auth0 MFA (TOTP/SMS) for non-federated.
• Instructor portal uses Google Workspace SAML (same IdP as employees, different Experience Cloud profile). 45 instructors are either employees or close contractors — Google Workspace accounts exist for all of them. Partner Community licenses with Partner profile restrict access to course metrics, revenue share, and student feedback only.
• Individual learners (250,000) do NOT access Salesforce. They use the LMS directly via Auth0 OIDC. This is the key architectural decision: no Salesforce portal for individual learners eliminates a 250K-user licensing and authentication problem. Learner data flows into Salesforce via MuleSoft integration, but learners never log into Salesforce.
• System-to-system authentication via OAuth 2.0 Client Credentials on Named Credentials. Each integration (LMS, Stripe, HubSpot, DocuSign, Zoom) has its own Connected App with scoped permissions. MuleSoft manages token lifecycle.

K-12 FERPA Implication for Auth

K-12 learners (minors) never access the Salesforce portal directly. K-12 partnerships use the corporate portal path (school district training managers as corporate admins). Parental consent workflows are backend processes — parents interact via the LMS or paper forms, not Salesforce. This keeps FERPA-protected minors out of the Salesforce authentication surface entirely.

Integration Error Handling

Error handling tailored to each integration’s business criticality, with special attention to the LMS as the foundational data source.

Integration	Pattern	Retry Strategy	Dead Letter Queue	Monitoring & Alerts	Fallback (Extended Outage)
LMS (bidirectional — primary)	Event-driven inbound + request-reply outbound	Inbound webhooks: MuleSoft acknowledges idempotently (LMS_Enrollment_Id as dedup key). Processing failure: Anypoint MQ retry 3x at 5-min intervals. Outbound enrollment requests: retry 3x with exponential backoff (30s, 2m, 10m)	Anypoint MQ DLQ for failed inbound events (enrollment, completion, certification). DLQ entries include LMS event ID, learner email, and error detail. DLQ reviewed daily by integration lead	Dashboard: event volume by type (enrollment, completion, cert). Alert if event volume drops >30% from baseline. Alert if DLQ depth >10. Daily reconciliation job flags SF-vs-LMS enrollment count mismatches per account	Inbound: Salesforce shows stale learner data (last successful sync timestamp displayed). Corporate dashboards note “data as of [timestamp].” Daily batch reconciliation catches up when LMS restores. Outbound: corporate admin enrollment requests queued in Anypoint MQ — LMS enrollments delayed but not lost. Manual enrollment via LMS admin panel as last resort
LMS (daily batch reconciliation)	Batch (safety net)	Nightly at 2 AM UTC. On failure: retry once at 4 AM. If both fail: alert integration lead for manual run	Discrepancy records written to LMS_Reconciliation__c staging object for review	Alert if reconciliation finds >1% discrepancy between SF and LMS enrollment counts. Dashboard: discrepancy trend over time	Reconciliation is a safety net, not primary. Webhook-driven sync continues independently. Manual reconciliation if batch fails 2 consecutive days
Stripe (inbound payment events)	Event-driven (webhooks)	Stripe retries webhooks per their exponential backoff policy (up to 72 hours). MuleSoft acknowledges idempotently. Processing failure: retry from Anypoint MQ 3x	DLQ for failed payment events with Stripe event ID, customer email, and amount. Finance team reviews weekly	Alert if payment event volume drops >50% from baseline (may indicate webhook URL misconfiguration). Dashboard: payment events received vs. expected	Stripe continues processing payments independently — no disruption to 85K subscribers. SF payment history temporarily stale. Finance team reconciles manually from Stripe dashboard for corporate invoicing
HubSpot (hourly lead sync)	Batch + Event	Hourly sync: retry 3x at 10-min intervals. MQL webhook events: retry from Anypoint MQ 3x	DLQ for failed lead records with HubSpot contact ID and error detail. Marketing ops reviews weekly	Alert if hourly sync fails 2 consecutive times. Dashboard: lead volume synced per hour	Sales team uses HubSpot directly for lead details. SF pipeline data temporarily incomplete. No revenue impact — leads are top-of-funnel
DocuSign (on-demand contracts)	Request-Reply (bidirectional)	Outbound (send for signature): retry 3x with 30s backoff. Inbound (signed doc webhook): DocuSign retries per their policy; MuleSoft processes idempotently	DLQ for failed envelope creation requests with Account ID and contract details. Legal ops reviews daily	Alert if >5 pending envelopes fail to send in 1 hour. Dashboard: envelope volume, success rate	Sales team sends contracts directly via DocuSign web UI. Signed documents linked to SF Account manually on restoration
Zoom (post-session attendance)	Event-driven (webhook)	MuleSoft acknowledges idempotently. Processing failure: retry from Anypoint MQ 3x at 5-min intervals	DLQ for failed attendance records with Zoom meeting ID and attendee list	Alert if attendance events missing for scheduled sessions. Dashboard: sessions tracked vs. scheduled	Attendance data is supplementary — not blocking for any critical workflow. Instructors can pull attendance from Zoom reports. Catch-up sync on restoration

Judge Signal

The LMS integration is the most critical because corporate dashboards, renewal conversations, and FERPA compliance all depend on learner data flowing accurately. Be ready to explain: (a) why webhook + daily reconciliation is better than pure batch (real-time enrollment actions from portal), (b) why discrepancy alerting matters (stale data directly impacts corporate renewal rate), and (c) why outbound enrollment requests queue in Anypoint MQ rather than failing silently (corporate admin experience).

Governance & DevOps

Environment Topology

flowchart LR
    subgraph DevEnvs["Developer Sandboxes"]
        DEV1["DEV Core\n(Developer Sandbox)\nInternal team"]
        DEV2["DEV Portal\n(Developer Pro)\nPortal development"]
        DEV_SI["DEV SI Partner\n(Developer Sandbox)"]
    end

    subgraph TestEnvs["Test Environments"]
        INT["Integration Test\n(Partial Copy)\nMuleSoft + LMS staging"]
        UAT["UAT / Staging\n(Full Copy)\nCompliance + performance"]
    end

    DEV1 -->|"PR merge to develop"| INT
    DEV2 -->|"PR merge to develop"| INT
    DEV_SI -->|"PR merge to develop"| INT
    INT -->|"Release candidate"| UAT
    UAT -->|"ARB approval +\nLegal sign-off (privacy changes)"| PROD["PRODUCTION"]

    style PROD fill:#d4edda,stroke:#28a745,color:#000
    style INT fill:#fff3cd,stroke:#fd7e14,color:#000
    style UAT fill:#cce5ff,stroke:#0d6efd,color:#000

Branching Strategy

Streamlined for a small team (12 internal + 15 SI) with 18-month delivery:

• main — mirrors production. Only IT Director deploys after ARB approval. Protected branch.
• develop — integration branch. Feature branches merge via PR. Auto-deploys to Integration Test (Partial Copy) on merge.
• feature/* — one branch per work item. 85% Apex coverage + naming convention check enforced at PR. Team prefixes: feature/core-*, feature/portal-*, feature/int-*.
• release/* — cut from develop for UAT cycle. Deployed to Full Copy. Bug fixes only after cut. Privacy/FERPA changes require Legal sign-off before production promotion.
• hotfix/* — emergency path. IT Director + VP Engineering approval. Merged to main and develop.

Sandbox Strategy

Sandbox	Type	Purpose	Data	Refresh
DEV Core	Developer Sandbox	Core platform, Sales/Service Cloud	Metadata only (200 MB)	Sprint start
DEV Portal	Developer Pro	Experience Cloud portal development	Metadata only	Sprint start
DEV SI Partner	Developer Sandbox	SI partner feature development	Metadata only (200 MB)	Sprint start
Integration Test	Partial Copy	MuleSoft + LMS staging end-to-end	Masked learner PII (Data Mask)	Bi-weekly
UAT / Staging	Full Copy	Compliance review, performance, FERPA validation	Full production clone with Data Mask	Monthly

LMS integration testing setup: Dedicated LMS staging environment (AWS) mirrors production data structure. MuleSoft CloudHub sandbox connects Salesforce Partial Copy to LMS staging. End-to-end flow tested: enrollment webhook -> MuleSoft -> SF record creation -> corporate portal display. Stripe and HubSpot use sandbox/test environments with test API keys.

Privacy testing (FERPA/GDPR/Privacy Act):

• Full Copy sandbox with Data Mask for learner PII (name, email, DOB, assessment scores)
• Synthetic K-12 data set for FERPA workflow testing: parental consent capture, restriction rule validation, audit trail verification
• GDPR workflows tested with synthetic UK learner data: consent management, right-to-erasure, data processing records
• Privacy Act tested with synthetic AU learner data: breach notification readiness, cross-border transfer controls

Testing Strategy

Test Type	Target	Environment	Gate
Unit tests (Apex)	>= 85% coverage (all Flows documented in registry)	Developer sandbox	PR merge to develop
Integration tests	MuleSoft + LMS end-to-end (enrollment, completion, cert events); Stripe payment webhooks; HubSpot lead sync	Integration Test (Partial Copy) with LMS staging	Sprint completion
Portal UAT	Corporate admin: enrollment, dashboards, reports, bulk CSV upload. Instructor: course metrics, revenue share	Integration Test with representative portal users	Product owner sign-off
Performance tests	2,000 concurrent corporate portal users, LMS webhook throughput (enrollment events at 20% YoY growth projection), daily reconciliation at 250K+ enrollment records	UAT (Full Copy)	ARB sign-off
FERPA compliance tests	K-12 account restriction rules, parental consent workflow, FERPA audit trail completeness, minor age verification gate	UAT with Legal + compliance representative	Legal Counsel sign-off (month 6 deadline)
GDPR / Privacy Act tests	UK learner consent, right to erasure, AU breach notification, cross-border transfer	UAT with Legal	Legal sign-off (Phase 3)
Auth flow tests	Employee Google SSO, corporate SAML federation (test IdP), Auth0 OIDC portal login, instructor portal login	Integration Test	IT Director sign-off

CoE & Ongoing Governance

Architecture Review Board (ARB):

• Composition: VP Engineering (chair), IT Director, SI lead architect, Legal representative
• Bi-weekly during implementation; monthly post-go-live
• Reviews: integration changes, data model modifications, privacy configurations, portal updates

Internal team (12 people):

Role	Count	Responsibility
IT Director (CoE Lead)	1	Release management, ARB coordination, vendor oversight
Salesforce Administrators	2 (existing, SF-experienced)	Configuration, user management, declarative automation
Salesforce Developer	1 (existing, SF-experienced)	Apex, LWC, code review, integration support
Integration Lead	1 (cross-trained from LMS team)	MuleSoft development, LMS API mapping
LMS Engineers	5	LMS API endpoints, webhook implementation, staging environment
Infrastructure	4	AWS hosting, networking, deployment support

SI partner (mid-size, 15 people): Handles primary build for Phases 1-2, transitions to advisory in Phase 3. Knowledge transfer: each SI consultant paired with internal team member. SI exits at month 16 with 2-month hypercare overlap.

Legacy portal team transition: 3 Java developers retrained. Month 1-3: Salesforce Trailhead + Admin cert path. Month 4-6: hands-on Experience Cloud development in DEV Portal sandbox. Month 7+: productive on portal configuration. Target: all 3 cross-trained by Phase 2 portal launch.

Release cadence:

• During implementation: 2-week sprints; production deployments every 4 weeks after ARB approval
• Post-go-live: Monthly releases with full regression. 48-hour hypercare after each deployment. Emergency fixes via hotfix branch with IT Director + VP Eng approval.

Standards:

• Naming: EP_[Object]_[Purpose] (e.g., EP_Enrollment_CompletionSync)
• All integrations through MuleSoft — no direct Apex callouts
• 85% Apex test coverage minimum
• All Flows documented in central registry (flow name, trigger, purpose, last modified)
• FERPA changes require Legal sign-off at PR level (GitHub CODEOWNERS rule)

Ongoing operations:

• MuleSoft Anypoint Monitoring: LMS sync health, payment event flow, lead sync rates
• Daily LMS reconciliation: automated discrepancy alerting with threshold (>1% flags for review)
• Shield Event Monitoring: FERPA record access audit (weekly review by IT Director)
• Quarterly platform review: enrollment data volume growth, API consumption, portal usage metrics
• Semi-annual privacy compliance review: FERPA audit trail completeness, GDPR consent records, Privacy Act breach readiness

Reporting Approach

CRM Analytics delivers the executive dashboard (revenue by B2B vs. B2C segment, renewal rates correlated with LMS utilization and completion data, learner growth trajectory, course performance rankings), the sales dashboard (pipeline, ARR, account health scores derived from LMS enrollment/completion metrics via MuleSoft, territory performance across US/UK/AU), and the operations dashboard (ticket volumes from Service Cloud, resolution times by channel, self-service deflection rates from the knowledge base). Corporate training managers access account-level dashboards directly in the Experience Cloud portal — enrollments, completion rates, certification status, and time-to-completion by department — powered by summarized LMS data synced through MuleSoft.

Presentation Strategy

For this intermediate scenario, allocate time roughly equally across artifacts but go deeper on: (1) LMS integration pattern — the make-or-break technical decision, (2) multi-portal architecture — shows solution design thinking, and (3) FERPA compliance — the timeline-driven risk. Cover remaining artifacts at summary level with confident, concise explanations.