// the find
mitchspano/trigger-actions-framework
A framework for partitioning, ordering, and bypassing trigger logic for applications built on Salesforce.
A Salesforce trigger framework that moves all trigger routing logic into custom metadata, letting you configure what fires, in what order, and whether it's bypassed — without touching Apex code. Supports both Apex classes and Flows as action handlers. Aimed at orgs tired of managing trigger hell across dozens of objects.
Metadata-driven configuration means you can reorder or disable trigger actions through the Salesforce UI without a deployment — useful for disabling something during a data migration without a code change. The bypass mechanism is granular: you can bypass per-permission, per-user, per-object, or globally, which covers the real support/integration scenarios that usually get hacked in. DML-less testing support is genuinely useful — Salesforce tests with DML are slow and hit governor limits fast. Mixing Apex and Flow in the same ordered pipeline is a practical win for orgs where admins own some automations and developers own others.
Custom metadata has deployment overhead — changes to trigger action config still require a metadata deploy in CI, so the 'no code change needed' story is only true for admins with direct org access, not true in a proper DevOps pipeline. The entry criteria formula field evaluates per-record using Salesforce formula syntax, which is limited and can get ugly fast for anything non-trivial. No native support for async/queueable chaining within the framework — if your actions need to go async, you're on your own. Testing DML-less is nice but the test utility approach requires discipline to maintain; teams that don't enforce it will end up with a mix of DML and DML-less tests that's harder to reason about than just picking one.