Case Study 04: EduPath Learning Solutions — Q&A Preparation
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.
Q&A Format
Duration: 30 minutes following 30-minute presentation Strategy: State your position, give the reasoning, acknowledge the trade-off. Keep answers to 1-2 minutes.
Integration
Q1: What happens if the LMS webhook fails and Salesforce misses a completion event?
Daily batch reconciliation catches it. MuleSoft compares enrollment counts and completion totals per account between LMS and Salesforce every night. Discrepancies trigger an alert and automated re-sync. Additionally, MuleSoft uses Anypoint MQ for webhook ingestion — if the Salesforce upsert fails, the message retries from the queue rather than being lost.
Q2: Why MuleSoft instead of a simpler integration tool like Salesforce Connect or direct Apex callouts?
Five external systems with bidirectional flows, different protocols, and a need for canonical data transformation. Salesforce Connect is read-only and would not handle enrollment requests from portal to LMS. Direct Apex callouts create point-to-point dependencies that are hard to monitor and maintain with a 12-person team. MuleSoft provides centralized monitoring, retry logic, and the ability to add systems without touching Salesforce code.
Q3: Could you use Change Data Capture instead of Platform Events for portal enrollment requests?
CDC captures changes to Salesforce records. For enrollment requests, I would need to create a record first and then have CDC detect it. Platform Events are cleaner — the portal publishes an intent event directly without an intermediate record. CDC is better suited for outbound sync patterns like Account changes flowing to HubSpot, which is exactly where I use it.
Q4: How does the daily batch reconciliation work without bringing 42M progress events into Salesforce?
The reconciliation compares aggregate counts, not individual records. MuleSoft queries the LMS API for enrollment count and completion count per Account, then compares against Salesforce rollup fields. If Account X has 450 enrollments in LMS but 448 in Salesforce, MuleSoft requests the delta records and upserts them. This handles edge cases without bulk data transfer.
Portal Architecture
Q5: Why not give 250K learners a Salesforce portal?
Cost and purpose. 250K Customer Community licenses would dominate the budget. More importantly, the LMS is purpose-built for learning — video delivery, assessments, progress tracking. Building a parallel learner experience in Salesforce would duplicate functionality. Salesforce adds value for corporate admins and support agents, not individual learners consuming course content.
Q6: What if corporate training managers want to see detailed lesson-by-lesson progress for their employees?
The portal shows completion percentages, milestones, and certification status — which is what training managers use for reporting to leadership. If a specific manager needs lesson-level detail, the portal can embed an iframe or link to the LMS dashboard scoped to their company. This avoids storing granular progress in Salesforce while providing access when needed.
Q7: How do you handle bulk enrollment of 500+ employees via CSV upload?
The corporate admin uploads a CSV in the portal. A Flow validates the data (email format, seat availability against License Allocation), creates Contact records where needed, and publishes Platform Events for each enrollment. MuleSoft processes the queue and calls the LMS enrollment API in batches. The portal shows upload status and any failures. Seat count is decremented on License Allocation atomically to prevent over-enrollment.
Q8: Why Partner Community licenses for instructors instead of Customer Community Plus?
Instructors are external partners, not customers. Partner Community provides the right access model — instructors see data related to their assigned courses, not account-level data. The partner role hierarchy scopes visibility naturally. With only 45 instructors, the license cost difference is negligible, and the access model is more appropriate.
Security and Compliance
Q9: FERPA compliance by month 6 is aggressive. What is the minimum viable scope?
Three elements must be live: the Consent Record object with parental consent workflow, Restriction Rules limiting FERPA-tagged learner data to authorized users, and Shield Event Monitoring for audit trails. Shield encryption on PII fields is also required. This does not require the full portal or analytics — K-12 accounts can operate through Sales Cloud with CSM-managed onboarding while the portal builds out in Phase 2.
Q10: How do you handle a GDPR right-to-erasure request when learner data exists in both Salesforce and the LMS?
The request triggers a cross-system workflow. MuleSoft orchestrates: anonymize the Contact record in Salesforce (replace PII with tokens, retain aggregate enrollment data for reporting), then call the LMS erasure API to anonymize the learner record there. Consent Record is updated to “Withdrawn” with timestamp. The audit trail of the erasure itself is retained per GDPR requirements. Aggregate course metrics are preserved because they contain no PII.
Q11: How do Restriction Rules work alongside Territory Management for FERPA data?
They operate at different layers. Territory Management controls which accounts a sales rep can see (geographic). Restriction Rules add an additional filter: even if a rep’s territory includes a K-12 account, they cannot see FERPA-tagged learner detail records without the K12 Data Access permission set. The rep sees the Account and Opportunity but not the individual learner Contact details. This is additive security, not conflicting.
Data and Migration
Q12: Why not migrate Stripe payment history into Salesforce?
Stripe is the system of record for individual payments and has excellent reporting. Migrating 85K subscription histories adds complexity with minimal value — support agents can view Stripe data via a MuleSoft experience API embedded in the agent console. Going forward, payment events sync in real-time. Historical payment lookup is an API call, not a data migration.
Q13: How do you deduplicate 450K HubSpot contacts against 250K LMS learners?
Email is the primary match key — both systems use email as the unique learner identifier. MuleSoft performs the match during migration: LMS learner record is the master (it has enrollment data), HubSpot fields merge where the LMS record is blank (marketing engagement scores, lead source). Contacts in HubSpot without LMS matches are evaluated by engagement score — inactive contacts older than 12 months are excluded to avoid bloating the org.
Governance and Delivery
Q14: With only 12 internal IT staff, how do you avoid vendor lock-in with the SI partner?
The 3-person CoE participates in every sprint — not as observers but as active developers on a subset of stories. Documentation standards require all custom code to have inline comments and a central architecture wiki. Knowledge transfer is a contractual deliverable with defined milestones: CoE members must pass hands-on assessments at months 6, 12, and 18. SI headcount tapers from 15 to 5 in the final phase.
Q15: What is your biggest risk and what would make you reconsider the architecture?
LMS integration reliability. If the LMS API cannot handle the volume of portal-initiated enrollment requests at peak (corporate bulk enrollments for thousands of learners), I would introduce an async queue on the LMS side or batch enrollment requests rather than individual API calls. The architecture already accounts for this with Anypoint MQ buffering, but if LMS response times degrade under load, the portal user experience suffers. Load testing the LMS API in Phase 1 is a gating activity before portal development begins.
Question Categorization
| Domain | Questions |
|---|---|
| D1 System Architecture | Covered in presentation |
| D2 Security | Q9, Q10, Q11 |
| D3 Data | Q4, Q12, Q13 |
| D4 Solution | Q5, Q6, Q7, Q8 |
| D5 Integration | Q1, Q2, Q3 |
| D6 Dev Lifecycle | Q14 |
| D7 Communication | Q15 |
Q&A Survival Rules
- Answer the question asked — do not pivot to a topic you prepared better for
- State position first, then reasoning: “I chose X because Y. I rejected Z because W.”
- Name the trade-off proactively — judges respect honesty over pretending there is no cost
- Say “I don’t know” when appropriate: “I would validate that during the design phase”
- Stay within 1-2 minutes per answer