SfSkills Domains Docs GitHub

Home / data / eda-data-model-and-patterns

eda-data-model-and-patterns

Education Data Architecture (EDA) data model deep dive: Contact-centric, Affiliations, Relationships, Account record types (Academic Program, Educational Institution, Sports Organization), Course_Offering__c, Term__c, Course_Connection__c patterns. NOT for Education Cloud setup, student success hub and advisor workflows — use admin/education-cloud-eda-setup. NOT for generic object and relationship modeling — use data/data-model-design-patterns.

Open the skill folder on GitHub

EDA Data Model and Patterns

Activate when working with the Education Data Architecture (EDA) data model in depth: object relationships, record types, extension patterns, and the contact-centric philosophy that underpins it. EDA is the backbone of Education Cloud and underpins most higher-ed + K-12 Salesforce implementations.

Before Starting

Core Concepts

Contact-centric model

Every Person = Contact. Roles are expressed via:

Account record types

Course data model

Attributes

Student health, test scores, demographics often live in Attribute__c (a generic key-value pattern) to avoid endless fields on Contact. This is a contested design choice — it trades schema clarity for extensibility.

Common Patterns

Pattern: Student → Institution via Affiliation__c

When a student enrolls: create Contact, create Affiliation__c with Role = "Student", Status = "Current", related Account = Academic_Program. Historical affiliations remain with Status = "Former" when they graduate.

Pattern: Faculty teaching assignment

Faculty are Contacts with an Affiliation__c (Role = "Faculty") to the Academic_Program. Their teaching load is Course_Connection__c with record type "Faculty" (or similar) to a Course_Offering__c.

Pattern: Parent / Guardian

Guardian is a Contact. Relationship__c between student Contact and guardian Contact with Type = "Parent". Bidirectional trigger creates the reverse Relationship__c automatically.

Pattern: Multi-campus student

Student Contact has multiple Affiliations to different Account (Academic_Program) records, each with its own status. Reports aggregate by Affiliation, not Contact.

Decision Guidance

QuestionAnswer
Where do I store student role?Affiliation__c with Role = Student
Where do I store parent relationship?Relationship__c with Type = Parent
Where do I store enrollment in a specific class?Course_Connection__c
Where does graduation date live?End Date on the Student Affiliation
Where do I store extended demographics?Prefer fields on Contact; use Attribute__c only when schema truly varies
  1. Document the real-world concepts (student, faculty, course, term) and map each to an EDA object + record type.
  2. Draft the ERD with record types called out explicitly.
  3. Build a reference dataset: 10 students, 5 courses, 2 terms, 3 faculty.
  4. Validate reports and Affiliation rollups work on the reference dataset.
  5. Plan any extensions as fields on existing EDA objects; avoid shadow custom objects.
  6. Map integration fields (SIS → EDA) with record type resolution.
  7. Write an admin runbook for onboarding new student → Contact → Affiliation → Course_Connection.

Review Checklist

Salesforce-Specific Gotchas

  1. Relationship__c bidirectional trigger runs on insert/update. Bulk loads must expect double the record count.
  2. Course_Connection__c has record types that change the page layout. A "Student" connection and a "Faculty" connection use the same object — layout validation is per record type.
  3. Affiliation rollups (Primary Affiliation, Primary Household) are governed by EDA settings. Changing the hierarchy setting after data load causes rollup drift.

Output Artifacts

ArtifactDescription
EDA ERD with record typesCanonical schema view
Object + field dictionaryDetailed field-level reference
Record-type matrixObject × record type × use case
SIS/LMS mappingIntegration field map

Package files