Power Pages and Cloud Flows – Validate user against Dataverse records based on Contact ID

The Power Automate Cloud Flows integration in Power Pages site offers a powerful way to automate actions beyond what’s available through the Power Pages WebAPI and also enables more integration scenarios and allows you to use data from any data source that is available for Power Automate.

However, it’s crucial to understand that table permissions are not enforced in Cloud Flow calls.

Even with Web Roles in place to secure the flows (please don’t use the Anonymous Users Web Role if the Flows and related actions needs to be secured, as it allows non registered users to call the Flow), if someone has the record ID or other parameters, they can initiate the flow using JavaScript from the Developer Tools in a browser.

This means that sensitive data could be exposed if the Flow doesn’t revalidate table permissions. To safeguard your data, it’s essential to add extra logic within the flow to recheck the contact and account IDs against some logic to replicate what you have in table permissions.

In this post you can see a sample implementation based on Contact and Account associated to a record in Dataverse.

Contact ID in the Trigger

Every Power Pages user is mapped to a record in the Contact table in Dataverse.

If we have a look at the properties that Power Automate provides us in the Power Pages trigger:

Note that there is a User ID returned in the ‘When Power Pages calls a Flow’ trigger. This User ID is exactly the same as the Contact ID in Dataverse.

Validating Contact against records

Imagine a scenario where you want to perform actions against Dataverse records in Power Automate. You can use Power Automate to call actions not available natively or even call bound or unbound Dataverse actions in Power Automate against a record/with a record ID sent as a parameter. You could also leverage Power Automate to unlock some other more complex scenarios that you can’t limit only with column permissions in the Web API, such as allow changing a choice value in a record from Pending to Submitted via Power Pages but never to Approved (for example the change of value to Approved will be running only from a Power Apps Model Driven app).

It will be more secure to check if the calling user should have the right to execute that.

There is no quick way to detect the current user’s table permissions, but we can check the contact ID against a record.

For example, we can use the Get a row by ID action to check the Contact ID against a field Portal User in a table (use the value property to match the user ID) – given that we would have some Record ID for a record in that table sent to the flow as parameter, and any action we would run after that would be against this record ID or something that bases its permissions on it:

If the user matches the correct contact ID, we proceed with running our desired action, otherwise, we can either Terminate the flow, or do not run the action and return a different response so that your JavaScript code can handle it better from Power Pages.

Note 1: If you choose to not terminate the Flow but run a ‘Return value(s) to Power Pages’ action, both return Return value(s) to Power Pages actions have to have the same output parameters, otherwise your Flow save will fail.

Note 2: if you run the Terminate action a flow without sending a response to Power Pages, you will get a Bad Gateway error:

Your Flow call will fail in JavaScript and you can handle in the .fail piece as below:

var data = {};
   data["SubmissionID"] = "<Some GUID of an item that the user has access>";
parameter, we should pass an empty object.
   var payload = {};
   payload.eventData = JSON.stringify(data);
     type: "POST",
     contentType: "application/json",
     url: "<flow url>",
     processData: false,
     data: JSON.stringify(payload),
     global: false,
     .done(function (response) {
       let responseData = JSON.parse(response);       
     .fail(function () {  
//Handle error!     

Validating Account associated with the Contact

Similarly, if in your Power Pages Portal the permissions are granted by Account in the table instead of Contact, you could retrieve the Contact record, so you can get the Account ID, and perform similar operation (comparing to the Company Name field ‘value’ in the Contact record):


Even though we initially can restrict Cloud flows usage only by Power Pages Web Roles, we can also add more rules based on the Contact and Account ID for a user in Power Automate.

Always be careful when running actions using Power Automate, be sure to always use the appropriate Web Roles and also to enhance validations in the Cloud Flows if the actions you are running need security validations. Adding rules with client side logic with JavaScript only is not enough to prevent misuse/unauthorized access.


Configure Cloud Flows integration in Power Pages – Microsoft Learn

Create and assign Web Roles – Microsoft Learn

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *