Our marketing team has set up an automated campaign email flow in D365 Sales 9.1 using Power Automate. The flow should trigger when a marketing list record is updated with a specific campaign status. However, the flow isn’t firing consistently - sometimes it works, but most of the time campaign emails are never sent and we only discover this when our marketing manager manually checks.
The trigger is configured as “When a row is added, modified or deleted” on the Marketing List entity, with a filter condition checking if the campaign status field equals “Ready to Send”. We’ve verified the field updates are happening in D365 (we can see the status changes in the audit logs), but the flow run history shows no triggers for those timestamps.
We’re concerned this is related to Dataverse trigger limitations or maybe security role permissions, since the field updates are sometimes made by different users across our marketing team. The workflow field update mechanism seems inconsistent - direct user updates sometimes trigger the flow, but bulk updates via our campaign planning tool never do. Has anyone dealt with trigger reliability issues in email marketing automation scenarios?
I’ve implemented several email marketing automation solutions in D365 and your symptoms point to a combination of all three focus areas you mentioned. Here’s a comprehensive solution:
Dataverse Trigger Limitations:
The core issue is that Dataverse triggers don’t reliably capture all update patterns, especially bulk operations. Instead of relying solely on the “When a row is modified” trigger, implement a hybrid approach:
Keep your existing trigger for real-time processing of manual updates
Add a scheduled flow (runs every 15 minutes) that queries Marketing Lists where campaign status = “Ready to Send” AND processed flag = false
This catches any lists that slipped through the trigger gaps
Workflow Field Updates:
Your campaign planning tool’s bulk updates are bypassing the event pipeline. To handle this:
Create a custom “Last Processing Timestamp” field on Marketing List
Have your scheduled flow update this timestamp when it processes a list
Filter your query to only process lists where status changed AFTER the last processing timestamp
This prevents duplicate processing while catching bulk updates
Security Role Permissions:
The inconsistent triggering across different users indicates permission issues:
Review the connection owner’s security role - they need Organization-level read on Marketing List and full access to Email entities
Change your trigger scope from “User” to “Organization” in the trigger settings
Use a dedicated service account with Marketing Manager role for the flow connection, not individual user accounts
Grant this account the “Act on Behalf Of” privilege so emails send from the actual campaign owner, not the service account
For immediate remediation:
Go to your flow trigger settings and change Scope to “Organization”
Create a new connection using a service account with proper permissions
Update your flow to use this connection
Implement the scheduled backup flow to catch missed triggers
This architecture has proven reliable across multiple D365 9.1 implementations. The scheduled flow acts as a safety net for the trigger’s limitations, while proper security configuration ensures consistent execution regardless of who updates the marketing lists.
This draft is based on general Microsoft Dynamics 365 Sales knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check your trigger configuration scope setting. If it’s set to “User” instead of “Organization”, the flow will only trigger for records modified by the flow owner. For marketing automation, you definitely want Organization scope so it captures updates from all team members. Also verify that your filter condition is using the correct field logical name - the display name can be misleading.
Dataverse triggers have known limitations with certain update patterns. If your campaign planning tool is using ExecuteMultiple requests or bulk operations, those can bypass the standard trigger mechanism. The trigger only fires for individual record operations that go through the standard Dataverse event pipeline. You might need to add a plugin or create a separate flow that monitors bulk operations differently. Also, there’s a delay of up to 5 minutes for Dataverse triggers - if you’re expecting immediate firing, that could explain why it seems inconsistent when you check manually right after updates.
I suspect this is a security role permissions issue combined with how the flow connection is established. When users update the marketing list, the flow executes under the connection owner’s context. If that user doesn’t have sufficient privileges to read related campaign data or send emails through the marketing entity, the flow will fail silently after triggering. Check the flow run history for any failed runs with permission errors. You might need to use a service account with full marketing module permissions as the connection owner instead of an individual user account.
Your bulk update scenario is the smoking gun here. When campaign planning tools perform batch updates, they often use the SuppressCallbackRegistrationExpanderJob parameter which explicitly bypasses workflow triggers to improve performance. This is common in third-party integration tools. You’ll need to either configure your planning tool to use standard update operations, or implement an alternative trigger mechanism like a scheduled flow that polls for marketing lists with the “Ready to Send” status that haven’t been processed yet.
Check if there are any classic workflows or business rules on the Marketing List entity that might be interfering. If a classic workflow updates the same field that triggers your Power Automate flow, it can create a race condition where the field value changes multiple times rapidly and the trigger misses some updates. Also verify your filter condition syntax - complex filter expressions with multiple AND/OR conditions sometimes fail silently in Dataverse triggers.