Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Here's a list of known issues with Microsoft Dataverse and Microsoft Power Automate.
Localization of metadata
When you change the Power Automate language and regional locale settings, metadata like table and column names don't change. The metadata always displays in the language and regional locale settings of your Microsoft Dataverse environment. See Languages to view your Dataverse settings.
Set complex fields
Most Dataverse fields contain simple data types where you can set the values intuitively. Two types of fields that are frequently challenging are lookup and multiselect fields.
Set lookup fields
Lookup fields require the following syntax: <entity set name>(<item id>).
For example, if you set the value of the account table primary contact field to a contact record with ID value of aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb, set the lookup by using this value: contacts(aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb).
The tricky part is determining the entity set name. It's usually the same as the plural name of the table, but not always. Use the following procedure to get the correct entity set name for a table by using Power Apps.
Sign in to Power Apps.
To learn more about using the Power Apps interface, see Get started with Power Apps.
On the left navigation pane, select Tables.
Set the filter to All.
Search for the table you want and select it.
In the Table properties area, expand the Tools menu.
Select the Copy set name command.
By using this method, you can always get the correct entity set name.
View all entity set names
Another way to quickly check entity set names is to use your browser to navigate to [Organization URI]/api/data/v9.2/, where [Organization URI] represents the URL for your environment. You can find this Web API endpoint URL in Developer resources in Power Apps. This URL returns a list of all the entity set names. In the results, use Ctrl+F to search for the name you expect to confirm it exists.
{
"@odata.context": "[Organization URI]/api/data/v9.2/$metadata",
"value": [
{
"name": "aadusers",
"kind": "EntitySet",
"url": "aadusers"
},
{
"name": "accountleadscollection",
"kind": "EntitySet",
"url": "accountleadscollection"
},
{
"name": "accounts",
"kind": "EntitySet",
"url": "accounts"
},
[Truncated for brevity]
Learn more about this and other Web API resources
Set multiselect fields
The user interface accepts only one option. To select multiple options, switch the input method to Enter custom value, and then enter a unique name for each option, separating each name with a comma.
Learn more about multiselect 'choices' columns:
Adding a row with attachments to the Notes table
When you use an attachment from the dynamic output of a non-Dataverse step, you must use an expression to convert it to a string. For example, when you add a row inside an Apply to each loop over the output from the When a new email arrives trigger, use string(triggerOutputs()?['body/attachments']) instead of items('Apply_to_each')?['contentBytes'], as shown in the following image.

SharePoint and OneDrive document tables don't display inputs when you create a flow
When you create a flow that triggers on the Dataverse SharePoint documents table or the OneDrive documents table, no data from these tables is passed to the editor and the flow inputs array is empty. This behavior occurs because these tables are virtual and their data isn't stored in Dataverse.
Flow not triggering
If your Dataverse trigger flow isn't executing when expected, verify the following conditions:
Background processing is enabled – Ensure that background processing is enabled in your environment and that administration mode is disabled. Flows depend on the Dataverse asynchronous service, which requires background processing to be active. If administration mode is enabled, disable it to allow background operations to run.
Note
See Administration mode to see how to disable or enable background processing and administration mode.
Filtering attributes are present in the update – When the When a row is added, modified or deleted trigger is configured with filtering columns, the record update must include a value from at least one of those columns for the flow to trigger. If the update doesn't modify any of the specified columns, the flow doesn't execute.
Record passes the filter expression – If your When a row is added, modified or deleted trigger includes a filter expression, verify that the record meets the criteria. You can check System Jobs in the Power Platform admin center to see if the validation failed. Adjust the filter expression or the record data to ensure the condition evaluates to true.
Flow is enabled and licensed – Verify that the flow is turned on and that the owner has the necessary licenses. If a flow is disabled or the owner's license expires, the flow doesn't trigger. Ensure the flow is active and properly licensed.
Note
See Settings to view the user's licences. Learn more about types of Power Automate licenses
Callback registration record exists – Each Dataverse trigger creates a Callback Registration record in Dataverse. If this record is missing or deleted, the flow doesn't trigger.
To verify that a callback registration record exists for your flow, you can query the Dataverse API:
GET [Organization URI]/api/data/v9.2/callbackregistrations?$select=callbackregistrationid,name,entityname,sdkmessagename,filteringattributes,scope,createdon,softdeletestatus&$filter=entityname eq '[table_name]' and softdeletestatus eq 0Replace
[Organization URI]with your Dataverse organization URL and[table_name]with the target table name (for example,accountorcontact). If no records are returned, the callback registration is missing. Turn the flow off and back on to recreate the callback registration record.Column descriptions
- callbackregistrationid – Unique identifier of the callback registration record.
- name – Name of the callback registration (typically derived from the Power Automate flow name).
- entityname – The Dataverse table being monitored (for example, account, contact).
- sdkmessagename – The event that triggers the flow, such as Create, Update, or Delete.
- filteringattributes – The specific columns that must change for the trigger to fire (if configured).
- scope – Defines whose changes trigger the flow (User, Business Unit, or Organization).
- createdon – Date and time when the callback registration was created.
- softdeletestatus – Indicates whether the callback registration is inactive (soft-deleted). Only records with value 0 are active.
Note
You can send
GETrequests by using the URL in your browser and view the results. For better experiences, try:
Flow triggering multiple times
If your flow triggers multiple times for a single record change, investigate the following causes:
Duplicate callback registration records – Multiple callback registration records for the same flow can cause duplicate triggering. This problem can occur if you turn the flow off and on multiple times, or if errors occur during the registration process.
To check for duplicate callback registration records, query the Dataverse API by using the same method described in the Flow not triggering section.
To resolve this problem, identify and remove duplicate callback registration records. You can delete extra records by using the Dataverse API or by turning the flow off and back on, which recreates the registration.
Multiple updates to the same record – If you update a record multiple times in quick succession, each update triggers the flow separately. Review the audit history of the record to identify what process or user causes the multiple updates. Consider implementing logic in your flow to handle duplicate triggers, or adjust the upstream process to reduce unnecessary updates.
Flow triggering with delays
This delay represents the time between when a Dataverse row is created or updated and when the asynchronous service processes the event and notifies Power Automate to start the flow. If your flow triggers correctly but with significant delays, consider the following factors:
Normal asynchronous processing delays – Dataverse triggers run through the asynchronous service, which typically processes jobs within seconds to a few minutes. Some delay is expected and normal.
Abnormal delays – If you experience delays longer than five minutes, check System Jobs in the Power Platform admin center to see if multiple jobs are in a waiting state or if there's a backlog. A backlog indicates high load on the async service, which can be caused by:
- High volume of operations in your environment
- Other processes consuming async service resources
- Temporary platform issues
Most delays due to backlog are transient and resolve as the async service processes the queue. If delays persist or worsen, contact Microsoft support for assistance.