Salesforce DevOps for Education Cloud

Education Cloud's trigger framework is configured through data records, not metadata. Here's how that trips up deployments.

What's hard to deploy

Education Cloud is built on the Education Data Architecture (EDA), and EDA's trigger logic runs through TDTM, Table-Driven Trigger Management, where each trigger handler is a row in a custom object rather than a metadata component. A metadata-only deployment can ship a new class meant to run through TDTM, but if the corresponding Trigger Handler record isn't migrated too, the class is simply never invoked, and the gap fails silently instead of blocking the deploy.

Where it gets hard

Trigger handlers are data, not metadata

EDA's automation runs through TDTM, Table-Driven Trigger Management, where each handler is a row in a custom object rather than a metadata component.

A missing handler record fails silently

A metadata-only deploy can ship a class meant to run through TDTM, but if the matching Trigger Handler record isn't migrated too, the class is simply never invoked, and nothing blocks the deploy to warn you.

Hierarchy settings drive core behavior

EDA leans on Hierarchy Settings and other custom settings records for things like automatic contact and affiliation creation, so an org's real behavior depends on data most metadata tools never inspect.

In practice

How Serpent helps

Serpent's dependency detection extends beyond metadata to catch these data-as-configuration patterns, so a TDTM handler record can be tracked and migrated as part of the same task as the class it activates. See org management in Serpent for how environments stay in sync. For a look at dedicated data-movement tooling, see how Serpent compares to Prodly.

Every Salesforce environment managed in one place in Serpent

Typical release for Education Cloud

Task the class and its handler together
A TDTM-driven change gets tasked as one unit: the Apex class plus the Trigger Handler record that activates it.
Dependency detection catches the gap
Serpent's dependency detection looks past metadata to flag when a class references a handler record that hasn't shipped yet.
Migrate the handler record with the deploy
The Trigger Handler data moves as a tracked step alongside the metadata, not a separate manual insert.
Confirm the automation actually fires
Validate in a synced sandbox that the new handler is active, since a silent gap here won't throw an error.

Common questions

Education Cloud DevOps, answered

Why did our TDTM automation stop firing after a deploy?

Almost always a missing Trigger Handler record. The class deployed, but nothing in the target org tells EDA to invoke it. Serpent's dependency detection flags this before deploy instead of after.

Does Serpent deploy EDA's Hierarchy Settings and other config data?

Yes, as part of the same task-based pipeline used for metadata. Data-as-configuration records like these move as a tracked step rather than a manual insert.

Do we need a separate tool for TDTM records?

No. Serpent's data operations handle the migration as part of the same release as the metadata it supports.

Start free. No credit card, no install, no commitment.

Set up in under 15 minutes. No DevOps hire needed.

Start free Book a demo