Power Automate for Dynamics 365

What is a "trigger," anyway?

Power Automate lets you build "flows" — automated recipes that say "when this happens, do that" — without writing traditional code. Every flow starts with a trigger, and picking the right one is the first decision you make on any automation. The easiest way to picture a trigger is a doorbell camera: it sits there quietly watching for something to happen (motion at the door, a new record showing up), and the moment it does, it automatically springs into action. There are three broad kinds of triggers:

• Automated — fires by itself in response to an event, such as a new email arriving, a file landing in SharePoint, or a record changing in your database. No one has to press a button.
• Instant — started manually, usually by someone clicking a button inside an app or the Power Automate mobile app. Think of it as a doorbell you press yourself, for "run this right now" situations like manually re-generating a document.
• Scheduled — runs on a timer, like every night at 2 AM, similar to setting a recurring alarm. Common for batch jobs like flagging stale opportunities or archiving old cases while everyone's asleep.

The Dataverse trigger, up close

Dataverse is Microsoft's built-in business database underneath Dynamics 365 — it's where records like Accounts, Contacts, and Cases actually live. The trigger you'll reach for constantly in CRM-related automation is called "When a row is added, modified, or deleted." It behaves a lot like a mail-sorting rule in your email inbox: "when an email arrives from this sender, move it to this folder" — except here it's watching database records instead of emails. It's more configurable than it first looks:

• Table and Scope — scope decides whether the flow reacts only to records the current user owns, their whole team, or the entire organization. Getting this wrong is a very common reason a flow seems to "randomly" not fire for other people's records.
• Filter columns — tell the trigger to only pay attention when specific fields change, the same way an email rule might only fire on messages with a certain subject line, ignoring everything else.
• Filter expression (trigger conditions) — a more precise condition, for example only triggering when the status field changes to one particular value, so the flow doesn't waste effort starting up just to immediately decide there's nothing to do.

Real-world CRM automation examples

Notify the owner about a big deal

Trigger: a row changes on the Opportunity table, watching the estimated value field specifically. Condition: check whether the new value crosses a threshold (say, over $100,000) and it hasn't already been flagged. Action: send an email or Teams message to the deal's owner, and optionally flip a "High Value Flag" so the flow doesn't send the same alert again on every future edit. It's the same idea as a banking app that texts you only the first time your balance crosses a certain amount, not every single time afterward.

Case escalation

Trigger: a row changes on the Case table, watching the priority field. Condition: priority is now High or Urgent, and the case is still open. Action: reassign it to a senior support queue, alert the support manager, and optionally move the case forward a stage in its business process flow.

Lead assignment

Trigger: a new row is added to the Lead table. Actions: look up the right salesperson (often based on territory, or simply the next person in a round-robin list), then update the lead's owner field to match. This is a common, low-code replacement for older assignment rules or heavier custom code, whenever the actual assignment logic is simple enough to describe in plain steps.

Keeping documents organized with SharePoint

A frequent request is to keep documents related to a CRM record in a properly organized SharePoint folder, rather than as loose attachments sitting directly on the record. A typical pattern looks like this:

1. Trigger when a new row is added (for example, a new Account or Case).
2. Create a SharePoint folder named after that record's ID or name (with any characters SharePoint doesn't allow cleaned up first).
3. Write the folder's web address back onto the Dataverse record, so a user can click straight through to it from the record's form.
4. Later, other flows can use SharePoint's "Create file" action to drop generated documents, like quotes or contracts, straight into that same folder.

This keeps things scalable: SharePoint is purpose-built for storing large numbers of files and tracking their version history, in a way that basic record attachments aren't really designed to handle at scale — think of it as the difference between a proper filing cabinet and a shoebox full of loose papers.

Getting sign-off with multi-level approval flows

The Approvals connector handles the common situation of "someone needs to say yes before this can move forward." It's the same everyday process as getting a purchase order signed off by your manager, and then by their manager too if the amount is large enough. For a multi-level approval (say, a discount request that needs a manager's approval, and a director's approval too above a certain size), the flow's shape typically looks like this:

Trigger: Row modified (Quote) - discount % changed
  -> Start and wait for an approval (manager)
     -> Condition: approved?
        Yes -> discount > 20%?
                 Yes -> Start and wait for an approval (director)
                 No  -> Update Row: status = Approved
        No  -> Update Row: status = Rejected, notify requester

Keeping each approval as its own separate "Start and wait for an approval" step, instead of trying to squeeze the whole thing into one giant condition, makes the flow far easier to read and fix later — the same reason a checklist with clear steps beats one giant paragraph of instructions.

Reaching systems that aren't in the cloud

Not everything a flow needs to talk to lives on the internet. When a flow has to reach something that only exists inside a company's own network — an on-site SQL Server database, a shared file drive, or an older internal system — it needs the on-premises data gateway. Think of the gateway as a translator and phone line rolled into one: it lets a cloud service like Power Automate securely "call in" to a system living inside a private building's network, without having to punch a hole in the company firewall to let outside traffic in. Practically, it's a small piece of software installed on a machine inside that network, and both Power Automate and Power BI can route requests through it.

Custom connectors solve a related but different problem. If a piece of software has its own web-based API (a way for other programs to talk to it) but Microsoft hasn't built an official connector for it yet, you can build your own by describing that API's actions in a standard format. Once built, it shows up in the flow designer looking and behaving just like any built-in connector. It's common to pair the two: a custom connector for an internal company system, tunneled through the gateway if that system only exists inside the private network.

Handling errors so flows fail gracefully

A flow running in production needs a plan for when something goes wrong, not just for when everything works. Two features matter most:

• Retry policies — each action has a settings panel where you can control how many times it automatically tries again, and how long it waits between attempts, when something temporary goes wrong (like a busy external service asking you to slow down). The default setting retries a few times automatically, but for actions calling systems known to be unreliable, it's worth setting a longer, more deliberate retry pattern.
• Run-after configuration — this is Power Automate's version of a backup plan. Normally an action only runs if the one before it succeeded, but you can configure it to also (or instead) run if the previous action failed, timed out, or was skipped. A common approach is to group your main actions into a "Try" bundle, followed by a separate "Catch" bundle that only runs if something in the Try bundle failed, sending an alert with the details of what went wrong.

A note on licensing

Not every connector comes free with a standard Dynamics 365 or Microsoft 365 license. Connectors are split into standard and premium tiers, and using a premium connector (or a custom connector, or the on-premises data gateway, in most cases) requires a premium Power Automate license, billed either per user or per flow. This matters while you're still designing the flow, not just when it's time to turn it on: if a flow mixes one free, standard trigger with even a single premium action anywhere in its chain, the whole flow generally needs premium licensing to run. It's worth double-checking current licensing details against Microsoft's official documentation before committing to a specific connector in your design, since pricing and connector tiers do shift over time.