Case Study 4: EduPath Learning Solutions - Presentation Notes
Work in Progress
This content is currently being reviewed for accuracy and will be updated soon.
Presentation Guide
This page turns the worked solution into a boardroom delivery outline. Use it after you have completed the case study and reviewed the reference solution.
Presentation Snapshot
| Field | Detail |
|---|---|
| Open after | Worked Solution |
| Format | 45-minute presentation + 45-minute Q&A |
| Study role | Rehearse structure, timing, and transitions |
| Related pages | Case Study Overview, Scenario Paper, Q&A Preparation |
Presentation Focus
Cover all nine artifacts, going deeper on LMS integration, multi-portal design, and FERPA compliance.
Opening (3 min)
Show the System Landscape diagram (Figure 1).
“EduPath Learning Solutions needs to transform from disconnected systems into a unified platform serving three distinct audiences: B2B corporate sales, learner support, and content creators. The critical architectural challenge is integrating a custom AWS-based LMS that must remain the system of record while making its data actionable in Salesforce for sales, support, and self-service portals, all under three different privacy regimes with a hard FERPA deadline at month 6.”
Frame scale: 800 employees, 250K learners, 15K corporate accounts, 85 courses, 42M progress events in LMS. State single-org decision and multi-portal approach. Name the key systems being added (Sales Cloud with Agentforce Revenue Management, Service Cloud, Experience Cloud, Shield, CRM Analytics) and the two systems being retired (Zendesk, Metabase).
Deep Dive 1: LMS Integration Pattern (8 min)
Show the Integration Architecture diagram (Figure 4).
“42 million progress events live in the LMS. The question is: what data does Salesforce actually need?”
Salesforce needs summarized data: enrollments, completion percentages, certifications, assessment scores. Not raw lesson-by-lesson progress. LMS publishes webhook events (enrollment, completion, certification, assessment score) to MuleSoft. MuleSoft transforms and upserts to Salesforce using external IDs (LMS_Enrollment_Id__c, LMS_Course_Id__c) for idempotent operations.
For the reverse direction: portal enrollment requests flow through Platform Events to MuleSoft to LMS API. CDC captures Account and Contact changes in Salesforce and pushes them outbound to HubSpot via MuleSoft.
Daily batch reconciliation compares enrollment counts as a safety net. Anypoint MQ provides durable retry with dead-letter queues for failed events. All traffic stays within the LMS API rate limit of 2,000 requests per minute using MuleSoft throttling policies.
Trade-off: Corporate dashboards show completion percentages and milestones, not granular lesson progress. Sufficient for renewal conversations and training manager needs. If granular progress is ever needed, it is available via API call to LMS, not stored in Salesforce.
Deep Dive 2: Multi-Portal Architecture (7 min)
Show the Identity diagram (Figure 5) and the Data Model (Figure 2).
“Three user populations, but only two need Salesforce portals.”
Corporate Portal (Customer Community Plus): ~2,000 corporate admins manage enrollments, view dashboards, download reports. Instructor Portal (Partner Community): 45 content creators view course metrics and revenue share.
Critical decision: individual learners (250K) do NOT get a Salesforce portal. They use the LMS directly. This avoids a 250K-user licensing problem and keeps the learner experience on the purpose-built LMS.
Walk through the data model: Enrollment bridges Contact and Course (master-detail to Contact for sharing inheritance). Course Feedback captures student ratings and sentiment for instructor dashboards. License Allocation tracks purchased vs. consumed seats per corporate account. Entitlement on Account drives tiered SLA enforcement.
Sharing sets scope corporate admins to their own Account’s data. Instructors see only their assigned courses and aggregated metrics via partner sharing sets.
Deep Dive 3: FERPA Compliance (6 min)
Show the Role Hierarchy diagram (Figure 3).
“K-12 partnerships launch at month 6. FERPA is a hard constraint. Without it, those partnerships cannot proceed.”
Architecture: K-12 flag on Account, FERPA flag on learner Enrollment. Enforcement uses a two-layer control model. Layer 1: Restriction Rules on Enrollment, Course Feedback, and Consent Record (custom objects — supported targets for Restriction Rules) filter out FERPA-flagged rows for users lacking the K12_Data_Access Custom Permission. The Custom Permission is assigned through the K12 Data Access Permission Set Group, and the Restriction Rule UserCriteria references the Custom Permission because Restriction Rules cannot directly evaluate Permission Set membership. Layer 2: Field-Level Security on Contact fields (name, email, DOB, assessment summary) hides those values for users outside the K12 Data Access Permission Set Group because Contact is not a supported target for Restriction Rules. Together the two layers isolate FERPA-flagged records and sensitive Contact field values.
Shield Platform Encryption on learner PII with Deterministic encryption on DOB so the age-gate trigger can evaluate under/over-18 without in-memory decryption. Consent object with parental consent workflow triggered when Is_Minor__c = true. Shield Event Monitoring for audit trail; Event Monitoring Analytics App produces the quarterly FERPA compliance report.
Dedicated K-12 support queue is driven by a Public Group whose members are agents holding the K12 Data Access Permission Set Group (queues accept Public Groups, not Permission Sets directly). The combination of queue-based sharing, the Restriction Rules on Enrollment, and the FLS on Contact means that even if a rep’s territory includes a K-12 account, they cannot see the FERPA-flagged Enrollment rows or the protected Contact field values.
Phase 1 prioritizes FERPA framework alongside Sales Cloud and LMS integration. The three are inseparable because K-12 accounts need Sales Cloud to manage and LMS integration to track learner progress.
Service Cloud and Revenue Management (5 min)
“Service Cloud replaces Zendesk with three capabilities: unified agent console, tiered SLAs, and self-service knowledge. Enhanced Omni-Channel is required because Standard Omni-Channel retires June 2026.”
Agent console: split view with learner Contact (enrollment summary, certifications, Stripe payment history via MuleSoft) on the left and active Case on the right. Enhanced Omni-Channel routing by Account type and issue category. Three queues: Corporate, Individual, K-12. Entitlements drive SLA milestones: 4-hour first response for corporate, 24-hour for individual. Knowledge base targets 30% ticket deflection.
Agentforce Revenue Management (ARM, Revenue Cloud) handles the three pricing models for corporate clients: per-seat annual, per-seat multi-year, and usage-based billing tied to monthly active learner counts from LMS (pushed through MuleSoft into the Usage Summary custom object). Contract amendments that add seats mid-term run as native ARM amendment actions, satisfying Req 7 without rewriting the contract. DocuSign integration via MuleSoft for contract signing. ARM’s native billing engine generates invoices and handles revenue recognition aligned to contract terms.
ARM is the net-new recommendation because Salesforce CPQ and Salesforce Billing both entered end-of-sale in March 2025. EduPath has no pre-existing CPQ footprint, so CPQ is not a viable fallback — the client starts on ARM from day one.
Supporting Artifacts (12 min)
Data Migration (2 min): Show timeline. HubSpot accounts/contacts and LMS learner data in Phase 1 with email-based deduplication. Individual learners without corporate association are distributed across 65+ hash-bucket Accounts so each bucket stays under the 10K-child account-data-skew threshold; alphabetical bucketing and Person Accounts were considered and rejected (alphabetical produces 25K per bucket which is 2.5x over threshold; Person Accounts are an irreversible org-wide change for a population that never logs into Salesforce). Zendesk tickets as read-only cases in Phase 2. Stripe syncs going forward only. 42M progress events stay in LMS. Automated row-count and checksum validation for each migration batch.
Identity and SSO (2 min): Show the SSO sequence diagram (Figure 7). Three IdPs serving four populations: Google Workspace SAML for 800 internal employees with a custom Apex JIT handler that assigns Permission Set Groups and writes Region fields (standard JIT only updates User fields; PSG assignment and territory placement require the custom handler). Enterprise SAML federation for corporate portal clients configured through Authentication Providers plus SAML SSO Settings with Salesforce as the Service Provider — not per-client Connected Apps, because Connected Apps are for Salesforce-as-IdP or OAuth grant flows. Auth0 OIDC as fallback for non-federated corporate admins and as the primary IdP for the 45 external instructor contractors. 250K learners authenticate via Auth0 to LMS only; they never touch Salesforce. MFA enforced across all paths.
Sharing Model (2 min): Show the OWD table. Account Private with Territory Management (US/UK/AU). Enrollment is master-detail to Contact for Controlled by Parent inheritance. Course is Public Read Only. Course Metric is Controlled by Parent via master-detail to Course. Course Feedback and Revenue Share reach instructors through criteria-based sharing rules keyed to a direct Instructor__c lookup — sharing sets cannot traverse the Course.Instructor__c relationship from the instructor’s portal user. Corporate Portal uses Customer Community Plus with implicit Account-based sharing (not redundant sharing sets on the master-detail chain). FERPA is a two-layer model: Restriction Rules on Enrollment, Course Feedback, and Consent Record filter FERPA-flagged rows by Custom Permission; Field-Level Security on Contact hides protected fields because Contact is not a supported target for Restriction Rules.
Governance and Environments (3 min): Show the Environment Topology diagram (Figure 8). ARB bi-weekly with VP Engineering as chair. 3-person CoE for knowledge transfer from SI partner. Full Copy sandbox for UAT, Partial Copy connected to LMS staging for integration testing. CI/CD via Salesforce CLI + GitHub Actions with automated deployment on PR merge.
Roadmap (3 min): Show the Gantt chart (Figure 6). 18 months in three phases. Phase 1 driven by FERPA deadline at month 6. Phase 2 delivers portals and service. Phase 3 adds analytics and optimization. LMS integration runs continuously across all phases as a cross-cutting workstream.
Risk and Trade-offs (3 min)
Four risks and mitigation:
- LMS integration reliability: Event-driven with daily batch reconciliation as safety net; external ID-based upserts ensure idempotency; Anypoint MQ DLQ prevents silent data loss; 2,000 req/min rate limit managed via MuleSoft throttling
- FERPA month-6 deadline: Phase 1 prioritizes FERPA framework in parallel with Sales Cloud, not sequentially after it; Legal Counsel sign-off is a deployment gate
- Small team (12 internal): SI partner handles build; 3-person CoE ensures knowledge transfer with contractual skill assessment gates at months 6, 12, and 18; SI headcount tapers from 15 to 5 in final phase
- Multi-jurisdiction privacy: FERPA is the Phase 1 hard gate; GDPR and Privacy Act hardening are Phase 3 because UK and AU operations already function; Consent Record object is jurisdiction-aware from day one
Closing (1 min)
“EduPath’s architecture balances platform unification with system-of-record clarity. The LMS owns learning, Salesforce owns relationships, MuleSoft bridges them, and privacy controls span both. The month-6 FERPA deadline drives Phase 1 sequencing, and the 250K learner decision to keep them on the LMS avoids the single biggest licensing and complexity trap.”
Transitions
- Opening to LMS Integration: “The first decision that affects everything else is how we integrate with the LMS.”
- LMS to Portals: “Once learner data flows into Salesforce, the next question is how we expose it to the right audiences.”
- Portals to FERPA: “One of those audiences, K-12 school districts, introduces a hard compliance constraint.”
- FERPA to Service/Revenue: “With the three key decisions covered, let me address how we handle learner support and corporate billing.”
- Service/Revenue to Supporting: “Now let me walk through the supporting artifacts.”
- Supporting to Risk: “Before closing, the top risks and how we mitigate them.”
- Risk to Close: “To summarize the architecture in one sentence…”
Timing Checkpoints
| Segment | Duration | Cumulative |
|---|---|---|
| Opening | 3 min | 3 min |
| LMS Integration Deep Dive | 8 min | 11 min |
| Portal Architecture Deep Dive | 7 min | 18 min |
| FERPA Deep Dive | 6 min | 24 min |
| Service Cloud and Revenue Management | 5 min | 29 min |
| Supporting Artifacts | 12 min | 41 min |
| Risk and Trade-offs | 3 min | 44 min |
| Closing | 1 min | 45 min |
Related Topics
Always verify against official Salesforce documentation
This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.
Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.