Custom, business and Dataverse triggers

What it does

Triggers are the signals that start a journey, branch it, or end it. Three kinds exist: business triggers shipped with the app for common Dynamics 365 record changes, Dataverse triggers you configure yourself against any table, and custom triggers fired from outside Dynamics by a code snippet or API call.

Key facts

Business triggers are the out-of-the-box set: contact created, contact email/phone/address updated, lead created, incident created, opportunity created, marketing form submitted, and the event check-in, registration and registration-cancelled triggers.
Dataverse triggers are the no-code option — pick "when a record related to a customer is created or updated", choose the table, choose the column that identifies the customer, choose which columns' changes fire it. No developer needed.
Custom triggers are the code path: you define a title, description and attributes in the Triggers area, then the app generates a JavaScript snippet with an ingestion key for a developer to wire into a website, app or service.
Custom trigger attributes support text, number, true/false, date/time and entity reference.
Every trigger carries three built-in attributes: customer data (authID, resolving to a contact, lead or Customer Insights profile), contactpoint_email and contactpoint_phone as fallbacks when a full profile isn't available.
A custom trigger stays unusable until the app has actually seen it fire — the status only moves to "Ready to use" after the integration is confirmed. A Dataverse trigger is activated by hand with the "Ready to use" button.
Interaction triggers are a fourth, separate category: email opened, link clicked, and the equivalents on SMS and push. They come from journey messages themselves and are what if/then branches usually wait on.
Trigger attributes are usable in entry conditions, attribute branches, wait tiles, goals, exits, and message personalisation.
Triggers can also be fired from a journey ("activate a custom trigger" tile) to kick off another journey or a Power Automate flow.
Triggers do not move with an ordinary solution export in the way people expect — Microsoft documents a separate move-triggers-between-environments process.

When to use / skip

Reach for a Dataverse trigger first. If the signal already exists as a record change in Dataverse — case resolved, opportunity won, order status set to shipped, a custom table your integration writes to — configure it there and you are done in ten minutes with no developer, no key to protect, and no deployment.

Custom triggers are for signals that never touch Dataverse: browsing behaviour, in-app events, IoT, a third-party commerce platform's webhook. They are genuinely powerful and genuinely more work: someone owns the snippet, the key, and the schema forever.

The pattern worth avoiding is a custom trigger that fires from a middleware layer which is also writing to Dataverse. You have then built two integration paths for one business event. Write to Dataverse and trigger on that.

Configuration decisions

Per signal: business trigger, Dataverse trigger, or custom trigger. Default to the highest-numbered option only when the lower two genuinely can't reach the data.
The trigger's attribute schema, decided up front — attributes carry the payload for personalisation and branching, and adding a required one later means the sending system changes too.
Which column identifies the customer on a Dataverse trigger, and what happens when it's empty or points at a record with no contact point.
Whether the audience resolves to contact, lead or customer profile, which follows the environment's audience source setting.
Naming and ownership. Triggers are a shared, flat, environment-wide list that gets long fast; agree a prefix convention on day one.
Environment promotion approach for triggers, and who re-issues the ingestion key in production.

Gotchas

The ingestion key in the custom trigger snippet identifies your tenant and sits in client-side code. Anything you put in trigger attributes and then use for personalisation is an injection surface — keep the attribute list minimal and never pass anything you wouldn't publish.
A custom trigger that has never fired is invisible in the journey designer. Developers ask "why can't I see it" constantly; the answer is that nobody has actually sent one yet.
Dataverse triggers fire on the column changes you selected. Select too many and a bulk data import lights up every journey using that trigger. Test against a realistic data migration, not one record.
Trigger attribute changes on a live custom trigger can break journeys already using those attributes in personalisation. Treat the schema as a contract.
Deleting or re-creating a trigger to "fix" it orphans the journeys referencing it. Fix in place.
Business triggers such as contact created fire on every creation route, including integrations and imports, not just the form submissions the client had in mind.

Consultant notes

In the first design workshop, list every business event the client wants to react to and classify each one as business, Dataverse or custom on the spot. It usually collapses to two or three custom triggers at most.
Demo a Dataverse trigger live — resolve a case, watch the journey start. It kills the assumption that everything needs developer effort.
Give developers the trigger test page and make them prove the trigger reaches "Ready to use" in each environment before you promise journey delivery dates.
Insist on a bulk-import test before go-live for any Dataverse trigger on a table that a data migration will touch.
Agree who owns the trigger catalogue after handover. Left unowned, it becomes forty triggers with names like "test2" within a year.

Worth revisiting if Dataverse trigger coverage widens, or if the trigger promotion story between environments improves.