Case Study 4: EduPath Learning Solutions - Worked Solution

Work in Progress

This content is currently being reviewed for accuracy and will be updated soon.

Reference Solution

This page compiles a worked answer for full-board study use. Compare the structure and trade-offs against your own attempt rather than treating it as the only acceptable design.

Solution Snapshot

Field	Detail
Open after	Scenario Paper
Difficulty	Intermediate
Primary pressure areas	Integration, Experience Cloud, Security, and Identity
Study role	Worked solution and artifact reference
Core frameworks	9 Essential Artifacts + Five-Finger Method
Related pages	Case Study Overview, Presentation Notes, Q&A Preparation

Only Open After Your Own Attempt

If you have not yet worked through the scenario paper, stop here. Set a full 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 the solution combines Shield encryption, field-level security, custom consent objects, and automated retention policies.
6. Agentforce Revenue Management (ARM, Revenue Cloud) for corporate quoting, contract lifecycle, and invoice generation with three pricing models (per-seat annual, per-seat multi-year, usage-based). Native Quotes lack the product rules, contract amendments, and usage-based pricing logic required for this scenario; ARM is the 2026 net-new path because Salesforce CPQ and Salesforce Billing entered end-of-sale in March 2025.

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). FLS alone hides fields but leaves the parent Contact and Enrollment records visible, which is not a board-defensible boundary for FERPA-protected learner data. The architecture therefore uses a two-layer control model: record-level isolation on the Enrollment object (where Restriction Rules are supported) plus field-level protection on Contact (where Restriction Rules are not supported).

• K12_Partnership__c flag on Account identifies FERPA-scoped accounts
• Enrollment records under K-12 accounts tagged with FERPA_Protected__c = true; Restriction Rules on Enrollment (a custom object — supported target for Restriction Rules) filter out FERPA-protected rows for any user who does not hold 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 (Restriction Rules cannot directly evaluate Permission Set or Permission Set Group membership)
• Contact cannot use Restriction Rules (Contact is not a supported object). Field-Level Security on PII, assessment score summary, and parental consent fields hides those values from users outside the K12 Data Access Permission Set Group; combined with the Enrollment-level filter, a non-K12 user sees neither the FERPA-protected enrollment rows nor the sensitive learner field values on the parent Contact
• Shield Platform Encryption on learner PII fields (name, email, date of birth). DOB uses Deterministic encryption so the age-gate trigger can evaluate under/over-18 without in-memory decryption; alternatively, a trigger on Contact computes Is_Minor__c (Boolean) at write time from the plaintext value and the encrypted DOB is used for display only
• Consent object tracks parental consent with version, date, and withdrawal capability; retention timers on Consent Record are jurisdiction-aware (see Decision 7 below)
• Shield Event Monitoring for audit trail on all FERPA record access. Quarterly compliance reports (Req 34) are produced via Event Monitoring Analytics App transforming EventLogFile data into an access summary, erasure-request count, and consent-expiration alert list

Must be operational by month 6. This drives Phase 1 scope.

Decision 7: Multi-Jurisdiction Retention (D2/D3)

FERPA (5 years post-enrollment), GDPR (3 years post-last-activity), and the Australian Privacy Act (follows GDPR timeline) cannot be satisfied by a single “2-year archive” rule. Retention is driven by the Jurisdiction__c field on Contact (populated from Account region and K-12 flag) and a scheduled job that evaluates each record against its jurisdiction-specific timer:

• K-12 FERPA learners: 5 years after the most recent enrollment closes. Retention clock starts on the Enrollment completion date, not the initial creation date
• GDPR (UK) learners: 3 years after the most recent login, enrollment, or support case — whichever is latest
• Privacy Act (AU) learners: same 3-year post-last-activity rule with additional cross-border transfer logging
• A learner with multiple jurisdictional memberships (UK learner enrolled in a K-12 partnership course) takes the longest retention period of the applicable regimes

The scheduled job writes expired records to a jurisdiction-tagged archive Big Object and raises an erasure event through MuleSoft to LMS, Stripe, and HubSpot for cross-system propagation.

Decision 4: Service Cloud Architecture (D1/D4)

Service Cloud replaces Zendesk with a unified agent console and tiered SLA enforcement.

• Omni-Channel Routing: Enhanced Omni-Channel with three queues (Corporate Support, Individual Support, K-12 Support). Standard Omni-Channel retires in Summer ‘26 (June 2026), so all new implementations must use Enhanced Omni-Channel. Routing based on case origin channel (email, chat, phone) and Account type. Corporate learner cases route to the corporate queue with higher priority. K-12 cases route exclusively to the K-12 queue. Queue membership is controlled via a Public Group (“K-12 Authorized Agents”) whose members are managed through the K12 Data Access Permission Set Group assignment process: when agents receive the Permission Set Group, administrators add them to the Public Group, which is the sole member of the K-12 Queue. Queues accept Public Groups as members but do not accept Permission Sets directly. Omni-channel overflow holds K-12 cases in queue rather than routing to unauthorized agents, because queue membership (via the Public Group) controls assignment eligibility. A validation rule on Case prevents manual reassignment of K-12 cases to agents outside the K-12 Authorized Agents group.
• Entitlements and Milestones: Two entitlement processes. Corporate entitlement: 4-hour first response, 8-hour resolution target. Individual entitlement: 24-hour first response, 48-hour resolution target. Milestone actions trigger email alerts at 75% elapsed and auto-escalate at 100%.
• Knowledge Base: Salesforce Knowledge with articles organized by category (enrollment, billing, technical, certification). Exposed in the corporate portal for self-service. Target: 30% ticket deflection within 6 months of launch.
• Escalation to LMS Engineering: Cases requiring LMS team involvement are assigned to an “LMS Engineering” queue. MuleSoft syncs case status bidirectionally: when the LMS team resolves the issue in their ticketing system, the Salesforce Case status updates automatically. Agents see a unified timeline.
• Agent Console Layout: Lightning App with split view. Left panel: learner Contact with enrollment summary, certification status, and payment history (Stripe data via MuleSoft experience API). Right panel: active Case with related Cases, Knowledge suggestions, and quick actions (macros for top 10 case categories).

Decision 5: Revenue Management Approach (D4)

EduPath is a net-new implementation, so Agentforce Revenue Management (ARM, the Revenue Cloud successor) is the primary platform for quoting, contracting, and invoice generation. ARM provides product rules, approval workflows, usage-based billing, and invoice generation natively on the core platform without the legacy managed-package footprint. Salesforce CPQ and Salesforce Billing are mentioned only for context because they remain supported for existing customers — they are not the recommendation for this build.

Product Lifecycle Note

Salesforce CPQ and Salesforce Billing both entered end-of-sale in March 2025. Existing CPQ and Billing customers are honored through their contract term, but net-new implementations should use ARM (Revenue Cloud) as the primary path. EduPath does not have a pre-existing CPQ footprint, so CPQ is not a viable fallback — the client starts on ARM.

ARM handles three corporate pricing models:

• Per-seat annual: Fixed price per seat per year. ARM Product Catalog entry with Quantity dimension = seat count.
• Per-seat multi-year: Discounted rate for 2-3 year commitments. ARM contract lifecycle with annual billing schedules; contract amendment (Req 7) is a native ARM amendment action that can add seats mid-term without rewriting the contract.
• Usage-based: Monthly billing based on active learner count. MuleSoft pushes monthly active learner counts from LMS into a Usage Summary custom object with a lookup to the ARM contract. ARM calculates the invoice amount from the usage data against the contracted per-learner rate.

Approval workflow: discounts exceeding 15% require CRO approval. Discounts exceeding 25% require CRO + VP Finance approval. ARM generates the quote document; DocuSign handles signature via MuleSoft integration.

Corporate invoicing, payment tracking, and revenue recognition all run through ARM’s native billing engine aligned to contract terms. Individual learners remain on Stripe entirely.

Decision 6: Mobile Strategy (D1)

No custom native mobile app. Mobile access uses three tiered approaches aligned to user population:

• Salesforce Mobile App for internal sales reps and CSMs only (the Salesforce Mobile App is an internal-user experience). Territory dashboards, account health scores, and pipeline views available on mobile with standard Salesforce Mobile configuration.
• Responsive Experience Cloud portal for corporate training managers. The corporate portal uses responsive Lightning Web Components that adapt to tablet and smartphone viewports. Dashboard components use standard CRM Analytics embedded dashboards, which render responsively in the browser. Offline access in the responsive portal is limited to whatever the browser caches; CRM Analytics offline caching (priming datasets for disconnected viewing) is available only inside the native Salesforce Mobile App or the standalone CRM Analytics mobile app, neither of which corporate admins use.
• Mobile Publisher for Experience Cloud is the path for branded native push notifications to the ~2,000 corporate admins. Mobile Publisher wraps the corporate Experience Cloud site as a branded iOS/Android app that supports push notifications natively. The Salesforce Mobile App does not deliver push to external Experience Cloud users. Mobile Publisher is added as a Phase 3 investment (mobile optimization slice) after portal go-live. Until Phase 3, push-equivalent alerting uses the email digest workflow described under Req 22 (daily/weekly digest preference on Contact).
• Push content: seat utilization exceeding 90%, batch certification completions, and enrollment milestone summaries. Platform Events fire from Salesforce; Mobile Publisher subscribes via Custom Notifications targeted at the Experience Cloud branded app audience.

Artifact 1: System Landscape

Figure 1. System landscape for EduPath Learning Solutions showing a single Salesforce org anchored by Sales Cloud with Agentforce Revenue Management, Service Cloud, two Experience Cloud portals (corporate and instructor), Shield, and CRM Analytics, integrated via MuleSoft Anypoint to the custom AWS LMS, Stripe, HubSpot, DocuSign, and Zoom, with Zendesk and Metabase retiring into native Salesforce equivalents.

Artifact 2: Data Model

Figure 2. Data model for EduPath Learning Solutions with Enrollment as the central bridge between learner Contact and Course (master-detail to Contact for Controlled by Parent sharing), supporting 1.8M enrollment records with LDV archival for completions older than two years, Course Feedback capturing student ratings and sentiment, Entitlements driving tiered SLA enforcement, and Consent Record tracking multi-jurisdiction FERPA, GDPR, and Privacy Act obligations including parental consent for K-12 learners.

• Enrollment is the bridge between Contact (learner) and Course. Master-detail relationship to Contact enables Controlled by Parent OWD and gives corporate admins implicit read through CCPlus Account-based sharing. The trade-off of the master-detail chain (Account -> Contact -> Enrollment -> Completion) is that sharing recalculations on Contact ownership changes cascade through Enrollment and Completion, which becomes expensive as volumes approach 5M+ records by year 5. Two mitigations are applied: (1) completed enrollments older than 2 years archive to a Big Object, keeping the live object under ~3M during the 18-month program, and (2) bulk migration and re-parenting operations are batched off-hours with sharing recalculation deferred via the Defer Sharing Rule Calculations setup option. A lookup + Apex Managed Sharing alternative was considered but rejected because CCPlus portal visibility depends on the implicit parent-child share, which only comes for free with master-detail.
• Course and Course Metric store aggregate performance data synced from LMS daily. A Flow on Course Metric fires instructor alerts (Req 28) when Average Rating drops below 3.5 or Completion Rate falls below 40%.
• Course Feedback captures student ratings and text feedback synced from LMS. Sentiment field is populated by a simple classification rule (rating 4-5 = Positive, 3 = Neutral, 1-2 = Negative). Aggregated per course for instructor portal dashboards. The Instructor__c lookup is populated on write so the criteria-based sharing rule can scope visibility to the assigned instructor without traversing the Course relationship.
• License Allocation tracks how many seats a corporate account has purchased vs. consumed. Paired with the Usage Summary object (monthly active learner rollup) to support ARM usage-based billing (Req 6, Req 55). Contract amendments that add seats mid-term (Req 7) flow through ARM’s native amendment action and update License Allocation atomically.
• Consent Record handles multi-jurisdiction consent tracking with regulation-specific logic, including the cross-system erasure orchestration state machine (Req 35): Pending, Acknowledged-SF, Acknowledged-LMS, Acknowledged-Stripe, Acknowledged-HubSpot, Completed, Failed. MuleSoft updates the Consent Record as each system confirms; a failure at any step leaves the record in Failed and raises a Case to the integration lead.
• Certification is separate from Enrollment. A learner may have multiple enrollments contributing to one certification.
• Audit Log captures enrollment and unenrollment events visible to corporate admins in the portal (Req 23). A Flow writes the record whenever a Contact is added to or removed from an Enrollment, with Account lookup so CCPlus implicit sharing exposes the log only to the correct corporate admin.
• Account.Health_Score__c (formula) combines LMS engagement score, completion rate, and support case trend; a scheduled Flow flags Accounts whose contract expiration is within 90 days (Req 3) and creates a Renewal Opportunity on the correct territory owner.
• Contact.Notification_Preference__c (picklist: Daily, Weekly, None) drives the Req 22 email digest. A scheduled Apex job aggregates enrollment milestones, certification completions, and license utilization alerts and sends the digest via Email Alert or Marketing Cloud journey.
• Instructor Application supports Req 27 self-registration. New creators submit credentials via a public Experience Cloud page; an approval process routes to Head of Content; on approval a Flow promotes the application to an Instructor__c record and provisions the Partner Community user. Until approved, the applicant cannot access the Instructor Portal.
• Entitlement on Account drives SLA enforcement. OWD is Private (Entitlement does not support Controlled by Parent). Corporate accounts receive the 4-hour first response entitlement; individual accounts receive the 24-hour entitlement. Assignment happens through a Flow on Account creation (or update when Account.Type changes) that creates or swaps the Entitlement record based on Account.Type. The Entitlement Process itself governs SLA milestone timing (first-response target, resolution target, escalation actions) rather than assigning the Entitlement to the Account.

Artifact 3: Role Hierarchy & Sharing Model

Figure 3. Role hierarchy for EduPath Learning Solutions showing three geographic sales branches (US, UK, AU) under the CRO, a customer success branch under VP Customer Success with dedicated K-12 support agents, and 45 instructors on a separate Partner Community branch under Head of Content, with FERPA enforcement using a two-layer control model: Restriction Rules on Enrollment, Course Feedback, and Consent Record filtering to holders of the K12_Data_Access Custom Permission (assigned through the K12 Data Access Permission Set Group), and Field-Level Security on Contact PII and assessment summary fields for the same population.

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	Master-detail to Contact; Restriction Rule filters FERPA-flagged rows to holders of the K12_Data_Access Custom Permission
Certification	Controlled by Parent	Inherits from Contact
Case	Private	Assignment rules + queue-based sharing
Course	Public Read Only	All internal users can view
Course Metric	Controlled by Parent	Detail of Course via master-detail (sharing inherits from Course, which is Public Read Only)
Course Feedback	Private	Direct Instructor__c Lookup(Contact) on Course Feedback drives criteria-based sharing rules to the instructor’s portal user; sharing sets cannot traverse Course.Instructor__c from User.ContactId
License Allocation	Controlled by Parent	Inherits from Account
Consent Record	Private	Restriction Rule filtering to K12_Data_Access Custom Permission holders; field-level access on the parent Contact fields controlled by the K12 Data Access Permission Set Group
Entitlement	Private	Owner-based; Entitlement is lookup-to-Account and is assigned by a Flow on Account creation based on Account.Type (Corporate = 4-hour, Individual = 24-hour). Entitlement Process governs milestone timing (first-response and resolution SLAs), not Account assignment
Revenue Share	Private	Criteria-based sharing rule to the instructor’s portal user via Instructor__c Lookup(Contact)
Contract	Controlled by Parent	Inherits from Account
Completion	Controlled by Parent	Inherits from Enrollment (milestone/course completions synced from LMS)

Portal sharing — Customer Community Plus (Corporate Portal): CCPlus users have role-based sharing and receive implicit read access to their Account’s related records through the standard Account-Contact implicit share. Because Contact is Controlled by Parent and Enrollment/Certification/License Allocation are master-detail children, corporate admins automatically see their Account’s Contacts and all master-detail children without additional sharing sets. Sharing sets are reserved for custom objects that do not sit on a master-detail chain to Contact (for example, the Audit_Log__c object used for Req 23 where the lookup to Account drives portal visibility).

Portal sharing — Partner Community (Instructor Portal): Instructors are partner users with their own role. Course Feedback and Revenue Share visibility is granted by criteria-based sharing rules keyed to Instructor__c — a direct Lookup(Contact) field populated when the course is assigned to the instructor. Experience Cloud sharing sets cannot traverse multi-level lookups (User.ContactId to Course_Feedback__c.Course__r.Instructor__c), so the direct lookup is added to every record the instructor must see, and criteria-based sharing (or Apex managed sharing where rule limits are exceeded) is used instead of sharing sets.

FERPA enforcement: Two-layer model (see Decision 3). Layer 1: Restriction Rules on Enrollment, Course Feedback, and Consent Record filter out FERPA-flagged rows for users lacking the K12_Data_Access Custom Permission; the Custom Permission is assigned via the K12 Data Access Permission Set Group, and the Restriction Rule UserCriteria references the Custom Permission because Restriction Rules cannot evaluate Permission Set or PSG membership directly. Layer 2: Field-Level Security on Contact fields (PII, assessment summary, parental consent) hides values for non-K12 users; Contact is not a supported target for Restriction Rules, so FLS is the enforcement lever for sensitive fields on the Contact record itself. Together the two layers mean a non-K12 user sees neither the FERPA-flagged child rows nor the protected Contact fields.

Artifact 4: Integration Architecture

Figure 4. Integration architecture for EduPath Learning Solutions showing MuleSoft Anypoint as the sole integration layer between Salesforce and five external systems, with Platform Events driving outbound LMS enrollment requests, CDC pushing Account/Contact changes outbound to HubSpot, LMS webhooks flowing inbound for enrollment and certification events, and Anypoint MQ providing durable async retry for all inbound event processing failures.

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 + CDC	Bidirectional	REST API via MuleSoft (inbound leads); CDC via MuleSoft (outbound Account/Contact changes)	Hourly lead sync inbound + real-time CDC outbound
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. All integration traffic stays within the LMS API rate limit of 2,000 requests per minute by using MuleSoft throttling policies.

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.

HubSpot bidirectional sync: Inbound: hourly lead sync + real-time MQL webhook events flow from HubSpot to Salesforce via MuleSoft. Outbound: CDC captures Account and Contact changes in Salesforce and pushes them to HubSpot via MuleSoft, keeping marketing records current.

Artifact 5: Identity & SSO

Figure 5. Identity architecture for EduPath Learning Solutions showing Google Workspace SAML for 800 internal employees with a custom Apex JIT handler applying Permission Set Groups and territory-driving region fields, Auth0 OIDC Auth Provider for the 45 external instructors landing on the Instructor Portal (Partner Community), a dual corporate portal path offering SAML federation (Authentication Provider + SAML SSO Settings, Salesforce as SP) for enterprise clients alongside Auth0 OIDC as a fallback, and the key architectural decision to route all 250,000 individual learners through Auth0 to the LMS only, keeping them off Salesforce licensing entirely.

• Employees (800): Google Workspace SAML 2.0 for Salesforce core org. SCIM not needed at 800 users; manual provisioning with a custom SAML JIT handler (Apex) is used. The custom handler reads Google Workspace group membership from the SAML assertion attributes and writes the User region (User.Region__c), which feeds Account territory assignment rules, and applies the appropriate Permission Set Groups. Standard SAML JIT provisioning updates only User fields — territory assignment and Permission Set Group assignment require the custom handler or a post-login Flow, not standard JIT.
• Corporate portal admins (~2,000): Two auth paths. Large enterprise clients federate via their own SAML IdP, configured as Authentication Providers plus SAML Single Sign-On Settings with Salesforce acting as the Service Provider (the enterprise IdP issues the assertion; Salesforce validates and establishes the session). A Connected App is not the mechanism here — Connected Apps are for Salesforce acting as an Identity Provider or for OAuth grant flows, while SAML SP-initiated federation uses Auth Providers and SSO Settings. Smaller companies use Auth0 (same credentials as LMS) via the OpenID Connect Authentication Provider pattern. Auth0 as fallback ensures all corporate admins can access the portal.
• Instructors (45): Instructors are external contractors, not employees, so Google Workspace SAML is not applicable. They authenticate through a dedicated Auth Provider (Auth0 OIDC with an instructor role claim, or the instructor’s own IdP where available) and land on the Instructor Portal with Partner Community licenses and a restricted Partner profile.
• Individual learners (250K): Auth0 for LMS only. No Salesforce portal access, which 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 and 450K contacts (deduplicate against LMS learner data using email match). Individual learners without a corporate Account association are distributed across 65+ hash-bucket Accounts (named Individual_Learners_001 through Individual_Learners_065, assignment driven by a deterministic modulo on the learner’s Salesforce Id or email hash). The bucket count is sized so that each bucket holds fewer than 10,000 child Contacts — the Salesforce account-data-skew threshold below which sharing recalculation, row locking, and ownership changes stay within acceptable windows. A combined population of ~650K individual learners (450K HubSpot + ~200K LMS-only) divided across 65 buckets yields ~10K per bucket; growth beyond that triggers automatic creation of additional buckets. Alphabetical bucketing (A-C, D-F) is explicitly rejected: it produces roughly 25K per bucket (2.5x over threshold) and rebalances unpredictably on last-name changes. Person Accounts were also evaluated and rejected for this scenario because the 250K individual learner population never logs into Salesforce and enabling Person Accounts is an irreversible org-wide decision; the hash-bucket pattern keeps the data model simpler while honoring the skew threshold. Inactive contacts (no engagement in 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. ETL mapping document covers field-by-field LMS-to-Salesforce mapping for enrollment status, completion percentages, certification dates, and assessment scores.
3. FERPA framework: Consent objects, FLS via K12 Data Access Permission Set Group, Shield encryption deployed and validated before K-12 launch at month 6.
4. Migration validation: Automated row-count and checksum reconciliation between source and target for each migration batch. Data steward sign-off required before cutover.

Phase 2 (Months 4-12):

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

Phase 3 (Months 10-18):

8. Zoom attendance: Historical not migrated. Real-time sync from month 10 onward.
9. HubSpot decommission assessment: Evaluate whether HubSpot can be replaced by Marketing Cloud or Marketing Cloud Account Engagement, 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. At the 3-year mark (~3.7M enrollments), evaluate Big Object archival for completed enrollments older than 2 years to maintain query performance.

Performance, Mobile, and Reporting Coverage

This section maps to Req 32, 34, 35, 44, 45, 46, 47, 51, and 60 so that each requirement has a named mechanism and an owner.

Req 32 — Age verification / under-18 consent gate: On Contact insert and update, a before-save Apex trigger computes Is_Minor__c (a Boolean) from the plaintext DOB value available in the trigger context (triggers run with decrypt permission when the running user’s profile has it) and stamps it on the record before save. An after-save record-triggered Flow reads Is_Minor__c and, when true, creates a pending Consent Record and blocks Experience Cloud activation until parental consent is received. The trigger must run before the Flow because Salesforce order of execution runs before-save Flows before before-save triggers; using an after-save Flow guarantees Is_Minor__c is already stamped by the trigger. The encrypted DOB is used only for display in the UI; the Boolean Is_Minor__c avoids Flow/formula limitations on encrypted fields.

Req 34 — Quarterly compliance report: Event Monitoring Analytics App consumes EventLogFile records (LoginEvent, ReportEvent, RestApi events filtered to FERPA-protected objects) and produces a quarterly CRM Analytics dashboard with three tiles: FERPA access log summary by user, erasure-request count, and consent expiration alerts. The dashboard is exported to PDF and delivered to Legal Counsel on a scheduled basis.

Req 35 — Cross-system erasure orchestration: Consent Record state machine (Pending -> Acknowledged-[system] -> Completed / Failed) with MuleSoft orchestrating fan-out to Salesforce anonymization, LMS erasure API, Stripe /v1/customers delete, and HubSpot contact delete. Each system’s acknowledgment updates a state field; a Consent Record stays Pending until all systems confirm. Failure at any step creates a Case and leaves the record Failed until manually resolved — GDPR requires completion or explicit rejection within 30 days.

Req 44 — 500 events/min peak throughput: MuleSoft CloudHub runtime sized for 2x peak (1,000 events/min sustained). Anypoint MQ buffers inbound LMS webhook events; the Salesforce System API uses the Bulk 2.0 API for enrollment and completion upserts during peak bursts to stay within the daily API limit. Load test scenarios at 150% of projected peak (750 events/min) are a Phase 2 UAT gate.

Req 45 — 60-second CRM Analytics refresh: CRM Analytics dataflows for corporate learner progress run on a 15-minute recipe schedule with incremental sync; a Data Manager job reruns hourly. For portal dashboards that require tighter latency than 15 minutes, the underlying Enrollment summary is updated via Platform Events (not dataflow refresh), keeping the rendered dashboard effectively real-time. The 60-second refresh target applies to dashboard render time after the user clicks Refresh, not to data latency — render budget is enforced through dataset partitioning and dashboard lens count.

Req 46 — API governor: A scheduled Apex job reads OrgLimits.DailyApiRequests and posts the current percentage to an operational Event Monitoring dataset. An automated alert fires at 70% and a second escalation at 80%. MuleSoft’s API consumption is tracked separately via Anypoint Monitoring and is subject to the same thresholds.

Req 47 — 5-second page load release gate: Lightning Inspector + Experience Cloud performance profiling in UAT (Full Copy sandbox). Any portal page exceeding 5 seconds on the third percentile (P90) load time is a release blocker; exemption requires ARB approval. The automated performance suite runs on every release/* branch deployment to UAT as a gated activity.

Req 51 — Push notifications for corporate admins: Mobile Publisher for Experience Cloud (Phase 3) — see Decision 6. Until Mobile Publisher ships, email digest per Req 22 covers the notification need.

Req 60 — Corporate learner outcome reporting: CRM Analytics embedded dashboard on the corporate portal home page shows certification pass rates, average time-to-completion, and a benchmark comparison against aggregated industry averages. The benchmark dataset is anonymized, aggregated, and refreshed quarterly from EduPath’s cross-customer reporting pipeline.

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
• FERPA changes require Legal sign-off at PR level (GitHub CODEOWNERS rule)

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. Knowledge transfer is a contractual deliverable with skill assessment gates at months 6, 12, and 18.

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

Figure 6. Phased delivery roadmap for EduPath Learning Solutions with FERPA compliance as the non-negotiable Phase 1 gate at month 6 (required before any K-12 partnerships launch), Service Cloud and dual portal delivery in Phase 2, and analytics, multi-jurisdiction privacy hardening, and Mobile Publisher for Experience Cloud push notifications in Phase 3, with LMS ongoing sync running as an 18-month cross-cutting workstream from day one.

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

Figure 7. SSO sequence flow for EduPath Learning Solutions detailing five authentication paths: employee Google Workspace SAML with a custom JIT handler assigning Permission Set Groups and region attributes, federated corporate SAML for enterprise clients via Authentication Providers and SAML SSO Settings with Salesforce as SP, Auth0 OIDC fallback for non-federated corporate admins, Auth0 OIDC for the 45-instructor Partner Community (external contractors, not employees), and OAuth 2.0 Client Credentials via an External Client App for inbound MuleSoft-to-Salesforce system integration.

Identity architecture rationale:

• Google Workspace SAML 2.0 for 800 internal employees. Google is already the corporate IdP (per paper). A custom Apex SAML JIT handler consumes the SAML assertion on every login and writes User fields (Region, cost center, department) from SAML attributes. The JIT handler also calls PermissionSetAssignment DML to grant or remove the appropriate Permission Set Groups based on the Google Workspace group claim, and sets User.Region__c so that standard Account territory assignment rules can place the user in the correct territory on next Account change. Standard SAML JIT on its own cannot assign Permission Set Groups or place a user into a territory — those require the custom handler. At 800 users, SCIM provisioning is not strictly necessary; the Apex JIT handler plus quarterly user access reviews are sufficient.
• Corporate portal (two auth paths): Large enterprise clients (major tech companies, consulting firms) federate via their own SAML IdP. Configuration is an Authentication Provider per client plus the site’s SAML Single Sign-On Settings with Salesforce as the Service Provider. A Connected App is not created per federated client — Connected Apps are for Salesforce-as-IdP or OAuth grant flows, not SP-initiated SAML. Smaller companies and individual corporate admins use Auth0 (OIDC) through an Authentication Provider, reusing the credentials they already have from LMS. 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: enterprise MFA for federated, Auth0 MFA (TOTP/SMS) for non-federated.
• Instructor portal uses Auth0 OIDC with an Authentication Provider. Instructors are external contractors (not employees), so Google Workspace is not applicable. Partner Community licenses with a restricted Partner profile expose only course metrics, revenue share, and student feedback on assigned courses.
• 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 — outbound from Salesforce: Named Credentials (with the External Credential pattern) point at each external system and hold OAuth 2.0 Client Credentials secured by the platform. Outbound Apex callouts, Flow HTTP Callouts, and External Services use the Named Credential so that no secret material lives in source. MuleSoft system-API endpoints are each an outbound Named Credential target.
• System-to-system authentication — inbound to Salesforce (MuleSoft calling Salesforce): MuleSoft holds credentials and authenticates to Salesforce as a dedicated integration user. In Spring ‘26 and later, inbound OAuth Client Credentials flow is configured through an External Client App (new create-path; creation of legacy Connected Apps was disabled by default in Spring ‘26). The External Client App is scoped to a single integration user per integration domain (LMS, Stripe, HubSpot, DocuSign, Zoom) with an OAuth Scopes set aligned to the minimum required objects. Named Credentials are explicitly not the inbound mechanism — they are for Salesforce acting as the caller, not for accepting inbound calls.

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 and 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 + CDC outbound)	Batch + Event + CDC	Hourly sync: retry 3x at 10-min intervals. MQL webhook events: retry from Anypoint MQ 3x. CDC outbound: MuleSoft processes CDC events with at-least-once delivery	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, CDC events processed	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

Figure 8. Environment topology for EduPath Learning Solutions with three developer sandboxes (core, portal, SI partner) promoting through a Partial Copy integration test environment connected to LMS staging for end-to-end MuleSoft testing, then a Full Copy UAT sandbox for FERPA compliance validation and concurrent portal user performance tests, before ARB and Legal sign-off for production release.

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, FLS and Permission Set Group 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 FLS enforcement via Permission Set Group, 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 use 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, SLA compliance rates, self-service deflection rates from the knowledge base). Corporate training managers access account-level dashboards directly in the Experience Cloud portal, including enrollments, completion rates, certification status, and time-to-completion by department, powered by summarized LMS data synced through MuleSoft. Instructor analytics dashboards show per-course enrollment trends, rating trends, revenue share accrual, and student feedback sentiment aggregation.

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, which shows solution design thinking, and (3) FERPA compliance, the timeline-driven risk. Cover remaining artifacts at summary level with confident, concise explanations.

Scoring Rubric

Criterion	Weight	What Judges Look For
Solution Architecture	25%	Multi-portal design (B2B corporate, B2C learner). LMS integration pattern with clear data ownership. Build-vs-buy for each capability (course delivery, payments, content management). ARM for revenue management (not CPQ — end-of-sale in 2025). Experience Cloud justification
Integration Architecture	25%	LMS bidirectional sync (enrollment, completion, progress). Payment processor integration. Lead sync patterns. Each endpoint with specific pattern, cadence, and error handling. Inbound vs outbound auth clearly split. MuleSoft justification for multi-system coordination
Security & Privacy	20%	FERPA compliance mapped to specific controls (two-layer model on supported objects, not generic “we’ll secure it”). GDPR for UK/AU learners. Learner data isolation per corporate account. Jurisdiction-aware retention. Consent management. Record access auditing
System Architecture	15%	Multi-cloud licensing (Sales Cloud, Service Cloud, Experience Cloud). Org strategy. Data model for courses, enrollments, certifications. Scaling for growth across B2B and B2C channels
Communication & Presentation	15%	Logical flow from business requirements to decisions. Clear portal architecture diagrams. Defense of LMS integration approach. FERPA timeline risk articulated as a constraint

---

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.