Student Lifecycle Data Model

Overview

The Salesforce Education Cloud (EDA) data model supports higher education institutions, with particular focus on online and adult-learning programs. The model integrates with legacy student information systems (SIS) while supporting CRM workflows for admissions and student engagement.

Prerequisites

Required Knowledge:

• Understanding of Salesforce Education Cloud (EDA) data model
• Knowledge of Program Enrollment and Course Enrollment objects
• Familiarity with SIS integration patterns and batch synchronization
• Understanding of External IDs and their use in integration
• Knowledge of Record Types and lifecycle stage tracking

Recommended Reading:

• rag/integrations/sis-sync-patterns.md - SIS synchronization patterns
• rag/data-modeling/external-ids-and-integration-keys.md - External ID patterns
• rag/data-modeling/data-migration-patterns.md - Data migration strategies
• rag/integrations/etl-vs-api-vs-events.md - Integration pattern selection

Core Data Model Decisions

Contact as Core Student/Applicant Record

Decision: Contacts serve as the primary person record for students and applicants

Rationale:

• Consistent person record across all Education Cloud implementations
• Supports both applicants and enrolled students
• Enables relationship modeling with programs and institutions
• Aligns with Education Cloud standard model

Implementation:

• Store student identifiers (SIS ID, external ID) on Contact
• Link Contacts to Accounts (programs, institutions) through relationships
• Use Record Types to differentiate between applicant, student, alumni if needed
• External IDs mirror SIS primary keys (e.g., EMPLID)

Program Enrollment Objects

Decision: Use Education Cloud Program Enrollment and Course Enrollment objects

Implementation:

• Program Enrollment for program-level enrollments
• Course Enrollment for course-level enrollments if needed
• Track enrollment status, start date, end date, and related academic information
• Link enrollments to Contacts (students) and Accounts (programs)
• Support multiple active enrollments per student if institution allows

Application Objects

Decision: Custom or standard Application objects represent one or multiple applications per student

Implementation:

• Design Application objects to support multiple applications per student (different programs, different terms)
• Include fields for application status, program, term, and modality
• Link applications to Contacts (applicants) and Accounts (programs)
• Support application checklists and required documents
• Track application submission date and decision date

Account for Programs

Decision: Accounts represent academic programs or institutions depending on the data model approach

Implementation:

• Use Accounts to represent programs or institutions
• Support program hierarchies if needed
• Link to Contacts through Program Enrollment relationships
• Use composite external IDs when SIS uses multi-column keys

Program and Enrollment Modeling

Program Modalities

Fields or Record Types for:

• Online programs
• Hybrid programs
• In-person programs

Implementation: Use fields or Record Types to differentiate program delivery modes

Program Levels

Fields for categorization:

• Undergraduate
• Graduate
• Non-degree programs

Implementation: Use picklist fields or Record Types to categorize program levels

Special Program Types

Flags or fields for:

• Accelerated programs
• Cohort-based programs
• Special program groupings

Implementation: Use boolean flags or picklist fields to identify special program characteristics

Enrollment Status and History

Tracking:

• Enrollment status (active, completed, withdrawn)
• Enrollment history tracking
• Term and section data mapping from SIS
• Effective dates for time-versioned records

Application Tracking

Multiple Applications Per Student

Support:

• Different programs
• Different terms
• Different application types
• Application history tracking

Application Status Tracking

Statuses:

• Submitted
• Under review
• Admitted
• Enrolled
• Withdrawn

Implementation: Use picklist fields or Record Types to track application status

Program-Specific Metadata

Fields:

• Program type
• Modality (online, hybrid, in-person)
• Term
• Application type

Application Checklists

Support:

• Required documents
• Milestone tracking
• Automated advisor task generation based on application status
• Document submission tracking

SIS Integration Data Model

External ID Strategy

Pattern: External IDs mirror SIS primary keys

• Use SIS primary keys (e.g., EMPLID) as external IDs on Contact
• Use composite external IDs on Account when SIS uses multi-column keys
• Include timestamp fields to track last sync time
• Implement job tracking fields to correlate Salesforce records with SIS sync jobs

Composite External IDs

Pattern: Account-level external IDs using composite keys

• Example: Institution + Program + Effective Date
• Concatenate component fields with delimiter (pipe | or dash -)
• Ensure delimiter doesn’t appear in component field values
• Handle null values in component fields appropriately
• Support effective-dated records where the same logical record has multiple versions over time

Integration Job Tracking Fields

Standard fields on all integrated objects:

• Last_Sync_Timestamp__c (DateTime) - when record was last synced
• Last_Sync_Status__c (Picklist: Success, Error, In Progress) - sync job status
• Last_Sync_Error__c (Long Text Area) - error message if sync failed
• Integration_Job_ID__c (Text) - correlation ID with external system
• Record_Source__c (Picklist: Integration, Manual Entry, Migration) - how record was created

Derived Fields

Pattern: Computed fields from SIS data

• Example: “last three enrolled terms” computed from Program Enrollment records
• Use formula fields for simple calculations
• Use Apex or Flow for complex derived fields that require aggregation
• Cache derived fields in custom fields if computation is expensive
• Update derived fields when source data changes

Custom Fields and Structures

Non-Degree Application Types

Support:

• Non-degree program applications
• Certificate programs
• Continuing education

Application Types for Program Groupings

Support:

• Hybrid program logic
• Special program groupings
• Program-specific application workflows

Derived Fields from SIS Data

Examples:

• Last three enrolled terms
• Academic standing
• Credit hours completed
• GPA calculations

Best Practices

Contact as Primary Person Record

• Use Contact as the core student/applicant record across all Education Cloud implementations
• Store student identifiers (SIS ID, external ID) on Contact
• Link Contacts to Accounts (programs, institutions) through relationships
• Use Record Types to differentiate between applicant, student, alumni if needed

Program Enrollment Modeling

• Use Education Cloud Program Enrollment object for program-level enrollments
• Use Course Enrollment for course-level enrollments if needed
• Track enrollment status, start date, end date, and related academic information
• Link enrollments to Contacts (students) and Accounts (programs)
• Support multiple active enrollments per student if institution allows

Application Object Design

• Design Application objects to support multiple applications per student
• Include fields for application status, program, term, and modality
• Link applications to Contacts (applicants) and Accounts (programs)
• Support application checklists and required documents
• Track application submission date and decision date

External ID Strategy for SIS Integration

• Use SIS primary keys (e.g., EMPLID) as external IDs on Contact
• Use composite external IDs on Account when SIS uses multi-column keys
• Include timestamp fields to track last sync time
• Implement job tracking fields to correlate Salesforce records with SIS sync jobs
• Document external ID strategy for each integrated object

Derived Field Patterns

• Compute derived fields from related records (e.g., “last three enrolled terms” from Program Enrollment records)
• Use formula fields for simple calculations
• Use Apex or Flow for complex derived fields that require aggregation
• Cache derived fields in custom fields if computation is expensive
• Update derived fields when source data changes

Tradeoffs

Advantages

• Aligns with Education Cloud standard model
• Supports both applicants and enrolled students
• Enables relationship modeling with programs
• Integrates well with SIS systems

Challenges

• Requires careful external ID management
• Derived fields need maintenance
• Multiple applications per student adds complexity
• Enrollment history tracking can be complex

When to Use This Model

Use this data model when:

• Implementing Education Cloud for higher education
• Integrating with legacy SIS systems
• Supporting both applicants and enrolled students
• Need to track program enrollments and applications
• Require SIS synchronization

When Not to Use This Model

Avoid this model when:

• Simple contact management only
• No SIS integration required
• No program enrollment tracking needed
• Different data model requirements exist

Q&A

Q: What is the Education Cloud (EDA) data model?

A: The Education Cloud (EDA) data model supports higher education institutions, focusing on online and adult-learning programs. It integrates with legacy Student Information Systems (SIS) while supporting CRM workflows for admissions and student engagement. The model uses Contacts as core student/applicant records, Program Enrollment objects for program-level enrollments, and Application objects for application tracking.

Q: Why use Contact as the core student record instead of a custom object?

A: Use Contact because: (1) Consistent person record across Education Cloud implementations, (2) Supports both applicants and enrolled students (same record type), (3) Enables relationship modeling with programs and institutions, (4) Aligns with Education Cloud standard model, (5) Leverages standard Salesforce features (sharing, relationships). Contacts provide flexibility for student lifecycle management.

Q: How do I model program enrollments in Education Cloud?

A: Model enrollments by: (1) Program Enrollment object for program-level enrollments (Education Cloud standard), (2) Course Enrollment object for course-level enrollments (if needed), (3) Link enrollments to Contacts (students) and Accounts (programs), (4) Track enrollment status (Active, Completed, Withdrawn), (5) Track dates (start date, end date), (6) Support multiple active enrollments per student if institution allows.

Q: How do I handle applications in the student lifecycle model?

A: Handle applications by: (1) Application objects (custom or standard) representing applications per student, (2) Support multiple applications per student (different programs, different terms), (3) Include application fields (status, program, term, modality), (4) Link to Contacts (applicants) and Accounts (programs), (5) Support application checklists (required documents, tasks), (6) Track dates (submission date, decision date).

Q: How do I integrate with legacy Student Information Systems (SIS)?

A: Integrate with SIS by: (1) External IDs mirroring SIS primary keys (e.g., EMPLID on Contact), (2) Batch synchronization (high-volume batch sync patterns), (3) ETL platforms (Dell Boomi, MuleSoft for transformation), (4) File-based staging for large datasets, (5) Data reconciliation (ensure data consistency). External IDs enable stable record mapping and idempotent operations.

Q: What is the difference between Program Enrollment and Course Enrollment?

A: Program Enrollment tracks program-level enrollments (student enrolled in a program/degree). Course Enrollment tracks course-level enrollments (student enrolled in specific courses). Use Program Enrollment for program tracking, Course Enrollment for detailed course tracking. Both link to Contacts (students) and can link to Accounts (programs/courses).

Q: How do I model Accounts in Education Cloud?

A: Model Accounts as: (1) Academic programs (programs/degrees students enroll in), (2) Institutions (if multi-institution model), (3) Link to Program Enrollments (students enrolled in programs), (4) Link to Applications (applications to programs), (5) Support hierarchy (institution → program if needed). Account structure depends on institution model (single vs. multi-institution).

Q: How do I track student lifecycle stages?

A: Track lifecycle by: (1) Record Types on Contact (Applicant, Student, Alumni if needed), (2) Application status (tracking application stage), (3) Enrollment status (tracking enrollment stage), (4) Status fields (explicit status tracking), (5) Date fields (application date, enrollment date, graduation date). Lifecycle stages help track student progression from applicant to enrolled to alumni.

Q: When should I use the Education Cloud data model?

A: Use when: (1) Implementing higher education CRM (admissions, student engagement), (2) Supporting online/adult-learning programs (flexible enrollment models), (3) Integrating with legacy SIS (batch synchronization), (4) Tracking program enrollments (program-level tracking), (5) Managing applications (application tracking, multiple applications per student).

Q: What are best practices for Education Cloud data models?

A: Best practices include: (1) Use Contact as core student record (consistent with EDA model), (2) Use Program Enrollment objects (Education Cloud standard), (3) Use external IDs for SIS integration (mirror SIS primary keys), (4) Support multiple applications per student, (5) Track lifecycle stages (applicant → student → alumni), (6) Design for SIS integration (batch sync, reconciliation), (7) Maintain data quality (validation, duplicate prevention).

Edge Cases and Limitations

Edge Case 1: High-Volume SIS Synchronization

Scenario: Synchronizing hundreds of thousands of student records daily from legacy SIS, causing performance issues.

Consideration:

• Use Bulk API for high-volume synchronization
• Implement file-based staging for large ID lists (exceeding 50,000 records)
• Use dynamic SQL batching (1,000 IDs per IN clause)
• Implement chunking strategies (1,000-10,000 records per batch)
• Monitor synchronization performance and adjust as needed

Edge Case 2: Multiple Applications Per Student

Scenario: Students applying to multiple programs simultaneously, creating complex application tracking.

Consideration:

• Support multiple Application records per Contact
• Use Application status fields to track application stage per program
• Link Applications to Program Enrollment when student enrolls
• Handle application-to-enrollment conversion logic
• Test application tracking with multiple applications per student

Edge Case 3: Program Enrollment Status Changes

Scenario: Students changing enrollment status (active, inactive, graduated, withdrawn) requiring status tracking.

Consideration:

• Use Program Enrollment status fields to track enrollment stage
• Implement status change workflows (automation, validation)
• Track status change dates and history
• Handle status change business rules (e.g., can’t change from graduated to active)
• Test status change logic with various scenarios

Edge Case 4: SIS External ID Format Changes

Scenario: SIS system changing external ID formats, causing integration failures or duplicate records.

Consideration:

• Design external IDs to be stable (don’t change over time)
• Handle external ID format changes gracefully (migration strategy)
• Validate external ID formats before upsert operations
• Support external ID migration when formats change
• Test external ID matching logic with various formats

Edge Case 5: Course Enrollment with Large Class Sizes

Scenario: Courses with hundreds or thousands of enrolled students, creating large Course Enrollment record sets.

Consideration:

• Monitor Course Enrollment query performance with large class sizes
• Use pagination for Course Enrollment queries
• Consider data archiving for historical Course Enrollments
• Test Course Enrollment queries with large datasets
• Optimize Course Enrollment queries for performance

Limitations

• Education Cloud License Requirements: Education Cloud features require Education Cloud licenses
• Program Enrollment Limits: Program Enrollment objects have relationship limits
• Course Enrollment Volume: Large Course Enrollment volumes may impact query performance
• SIS Integration Complexity: SIS integration requires careful design and error handling
• External ID Stability: External IDs must be stable and properly formatted
• Lifecycle Stage Tracking: Lifecycle stage tracking requires careful design and maintenance
• Application Tracking: Multiple applications per student adds complexity to application management

• Data Reconciliation: SIS data reconciliation requires careful design and monitoring

• SIS Synchronization Patterns - High-volume batch sync patterns
• External IDs and Integration Keys - External ID patterns
• Data Migration Patterns - Data migration strategies