Data transformations allow you to programmatically modify the data flowing from a school's source system before it reaches your application. This ensures data consistency, fixes data quality issues, and adapts the school's data structure to match your application's requirements without needing to change the source system itself.
Transformations run every time data changes in the source system, so they should be deterministic and idempotent. This is a fancy way of saying that given the same input, they should produce the same output, regardless of how many times they are applied.
Here are some of the common ways developers use transformations:
- Sanitizing Input Data: Legacy databases or specific application logic may not handle special characters, emojis, or non-standard accents gracefully. Transformations can strip or replace these characters from names, emails, and course titles to prevent errors during data ingestion.
- Inferring User Roles: Some data sources (such as Google Workspace) do not explicitly assign global roles like "Student" or "Teacher" to user accounts. You can use transformations to analyze a user's class enrollments to determine their primary role—for example, assigning the "Teacher" role to anyone who owns a course.
- Standardizing Identifiers: Schools often have inconsistent ID formats, such as missing leading zeros or inconsistent email domains. Transformations can normalize these identifiers (e.g., padding student IDs to a fixed length or generating usernames from email addresses) to ensure users match correctly across different systems.
- Managing Cross-Listed Classes: Sometimes schools create multiple "copies" of class sections for state reporting reasons. Depending on your application's needs, you can use transformations to either merge these into a single class or ensure they remain split to reflect the teacher's workflow.
- Promoting Custom Data: Critical data often resides in provider-specific "custom fields" or "properties" (as they're called in Edlink) within the source system (e.g., a student's locker number or homeroom). Transformations can map this data from a nested custom property into a top-level field or a standardized location in the Edlink model, making it accessible to your application without digging through provider-specific JSON blobs. This is common when districts share demographics from platforms like ClassLink, where the data may be stored as a OneRoster extension field.