Transactional and service messaging: Journeys or Power Automate

What it does

Somebody wants an email when a case is resolved, an order ships or an appointment is booked. You can build that as a Dataverse-trigger journey in Customer Insights – Journeys, or as a cloud flow in Power Automate sending through Exchange, Communication Services or a connector. Both work. They differ on consent, tracking, cost per message and who can change it next year.

Key facts

A Dataverse trigger is created in the Journeys Triggers area with When a record related to a customer is created or updated, pointing at a table, an audience attribute that resolves the customer, and the specific columns to watch. Publishing it means setting it Ready to use.
It fires on any change to the watched columns, not on a value. Filtering to "Status = Resolved" is a condition inside the journey, not part of the trigger.
Dataverse triggers are no-code. Custom triggers are the alternative and need an instrumented event and developer work.
Once created, the trigger's table attributes are available for journey entry, goals, exits, attribute conditions, wait tiles and content personalisation.
Trigger-based journeys are documented at up to 2,500 triggers a minute, with latency P90 under 3 minutes and P95 under 5 minutes at that rate. Above it, processing slows and triggers can fail.
Every message sent through Journeys counts as an interaction against the tenant's monthly interaction quota, and the recipient counts as an interacted person. The service caps at 10 interactions per interacted person per month.
Consent enforcement is per purpose. A transactional purpose set to Non-restrictive sends unless there is an explicit opt-out; Disabled skips the consent check entirely.
Power Automate sending sits outside all of this: no consent evaluation, no interaction quota, no engagement tracking, no interaction timeline entry.

When to use / skip

My default: build it in Journeys if it is a message to a customer, and in Power Automate if it is a message to a colleague. That line holds up better than any of the more sophisticated ones.

The reason is consent and record-keeping, not features. A Power Automate flow sending through a mailbox has no idea that the recipient unsubscribed, will not appear on the contact's interaction timeline, and produces no evidence six months later when someone asks what the customer was sent. On a UK client that has to answer a data subject access request, "it was sent by a flow and we did not record it" is a bad answer. Journeys gives you consent evaluation, a timeline entry and engagement data for free.

Where I would do the opposite. First, genuinely high-volume machine messages — a delivery notification per parcel, a daily balance alert — because the 10-interactions-per-person-per-month cap and interaction quota make Journeys the wrong economics, and nobody needs open-rate data on a dispatch note. Second, messages that must arrive within seconds and must never be delayed: Journeys quotes minutes, not seconds, and quiet times exist to hold messages back. A password reset or a one-time passcode belongs in a purpose-built path, not a marketing journey. Third, internal notifications, approvals and anything to a queue — Power Automate all day.

The awkward middle is service messaging that marketing also wants to influence: appointment reminders with a promotional footer, order confirmations with a cross-sell block. Put those in Journeys, set them against a transactional purpose, and be strict about who can pick that purpose. The moment a genuinely promotional message goes out under a non-restrictive transactional purpose, the client has a compliance problem that started as a convenience.

One more consideration people miss: durability. A journey is visible to a marketing administrator, versioned, and has analytics. A cloud flow lives in someone's personal environment, breaks when they leave, and nobody notices until a customer complains. If the message matters, Journeys is the more supportable home even where the flow would be quicker to build.

Configuration decisions

Which purpose transactional messages run under, and its enforcement mode. Non-restrictive is the usual answer; Disabled should be a deliberate, documented exception.
Whether the message is exempt from quiet times and frequency capping as operational.
Whether the trigger is a Dataverse record-change trigger or a custom trigger, and who builds it.
The condition inside the journey that turns "any change to Status" into the specific state you care about.
Latency tolerance: whether minutes is acceptable, or whether this message needs a path that does not go through journey processing.

Gotchas

Dataverse triggers fire on change, not on value. Resolve, reopen, resolve again sends three emails unless the journey guards against it.
A bulk data load or an integration backfill that touches thousands of rows can exceed 2,500 triggers a minute in seconds. The result is failed triggers, and it looks like a product fault.
Every transactional send consumes interaction quota shared tenant-wide, sandboxes included. Volume-heavy service messaging can quietly eat the marketing budget.
Quiet times apply unless exempted. A shipping confirmation held until 9am is technically correct and commercially wrong.
Consent for text and custom channels is not covered by the contact-consent feature switch, which handles contacts and email only. Do not assume SMS is protected by the same setting.
Power Automate sends leave no interaction timeline record. That gap only becomes visible during a DSAR or an audit, which is the worst time to find it.

Consultant notes

Draw the customer-versus-colleague line in the first design session and hold it. Every exception after that should be argued individually.
Demo a case-resolved journey end to end, including the timeline entry on the contact. The timeline is what convinces the service manager, not the email.
Push back on rebuilding existing Power Automate notification flows in Journeys just for consistency. If they go to internal recipients, leave them alone.
Check with the client's privacy owner which messages they class as transactional before you configure the purpose. Do not make that call for them, and say so in writing.
Before go-live, run a bulk update in a sandbox against every Dataverse trigger you built and count what comes out. That test finds both the fires-on-any-change problem and the throughput ceiling in one go.

Worth revisiting if trigger throughput limits change, or if the consent feature switch is extended to text and custom channels.