How to – Hide Approve / Reject Button in Approval Email in Power Automate Approval Workflow


Recently we had a requirement to remove or hide the Approve and Reject buttons from the approval email as we wanted the user to manage it all from the Approval Center.

The way we implemented this is by replacing the Start and wait for an approval action with Create an approval, Send email notification and Wait for an approval action.

For Create an approval action, set Enable notifications as No this makes sure no email is sent.

Followed by– in the body, specify Send an email notification the Approval Center link.

Followed by Wait for an approval, specify the Approval ID there.

And the Condition control and the required logic.

After running the flow, the user will get the email and can click the link to navigate to the Approval center.

The user can then take the required action from within the Approval center.

The flow will wait for the user

Also, check – Implementing approvals with Teams notifications

https://powergi.net/2021/07/11/use-power-automate-approvals-with-teams-notifications-only-no-emails/

Check other articles on Power Automate Approvals 

Approvals – Power Automate & Dynamics 365

Hope it helps..

Advertisements

How to – configure Facebook Webhook Validation with Power Automate Flow (Dataverse / Dynamics 365)


Recently we were working on Facebook Leads integration with Dynamics 365. Webhook for Leads can be configured to send real-time notifications of the Leads ads changes.

The first step of setting up Webhook requires creating an HTTPS endpoint that can process 2 types of HTTP Requests – Verification and Event notifications.

Here we will see how to configure the Power Automate flow for verification.

Login to Meta for Developers – Facebook and create an app.

https://developers.facebook.com/

Select Business for the app type.

After the App is created, select Webhooks to be added to the app. Click on Set up.

Next click Subscribe to this object. Here we have User selected.

For getting leads notification we need to select Page 

FBPagePreview in new tab

And subscribe to leadgen object

leadgen

It asks us to specify the Callback URL and Verify token.

Back in Power Automate create a Flow with Request type Trigger, followed by Parse JSON and Response actions.

For HTTP Request, select GET as the method, as FB will send a GET request to the endpoint URL, with the verification requests included in the endpoint of the URL.

Next, Parse the JSON and specify the Content and Schema

Content – 

 triggerOutputs()['queries']

Schemajson

 

Lastly in Response, set Status Code as 200 and Body as hub.challenge.

Here FB expects the Endpoint to verify the hub.verify_token (which we haven’t set up yet) and respond with hub.challenge value after verification.

Save the Flow, and copy the URL generated for the HTTP Request trigger.

Back in Meta for Developers, in edit user subscription paste the Callback URL and for now in place of token specify any value and click on Verify and Save.

We should now have a Webhook endpoint (Flow) successfully configured

We can also see our Flow ran successfully.

Here in the example we configured the webhook validation for User events, for Facebook Lead we need to configure it for Page, the other options available are Permissions, Application, Instagram etc.

Please check – 

https://powerautomate.microsoft.com/nl-nl/blog/connect-facebook-workplace-to-sharepoint/

 

Hope it helps..

{
    "type": "object",
    "properties": {
        "hub.mode": {
            "type": "string"
        },
        "hub.challenge": {
            "type": "string"
        },
        "hub.verify_token": {
            "type": "string"
        }
    }
}
Advertisements

Fixed – change the owner of the Flow or Flow client error returned with the status code “Forbidden” and ConnectionAuthorizationFailed in Power Automate


Recently while trying to change the owner of the workflow we were getting the below error 

Flow client error returned with status code “Forbidden” and details “(“error”:X [“code”: “ConnectionAuthorizationFailed”, “message”: “The caller object id is ‘ffcdd1fc-2858-4019-9a96-19d73ae124c8″. Connection ‘providers/Microsoft.PowerApps/APIs/shared_commondataserviceforapps/connections/shared-commondataser-87229e07-1003-4e05-8172-fdaf112ceb98’ to ‘shared_commondataserviceforapps cannot be used to activate this flow, either because this is not a valid connection or because it is not a connection you have access permission for. Either replace the connection with a valid connection you can access or have the connection owner activate the flow, so the connection is shared with you in the context of this flow.”}}”.

Below are the steps we were following to change the owner of the cloud flow –

https://learn.microsoft.com/en-us/power-automate/change-cloud-flow-owner

Select Edit for the flow, specify the owner and save.


In our case, the owner had left the organization and the user’s record was not available in the CRM. Finally, we managed to change the owner and fix the issue, by assigning the new owner to the corresponding modern flow record through the below steps – 

  • Open Advanced Find
  • Search for Process Type equals Modern Flow


  • Select the flow, click on the Assign Process button and specify the new owner.


This way we were able to change the owner without any error and got the flow working properly.

Hope it helps..

Advertisements

Fixed – Resource not found for the segment in Power Automate


You might get this error while writing a flow –

Fixed – Resource not found for the segment – ‘GUID’

The error was for the below field – Owner (lookup)

To populate a lookup field, we need to specify the plural schema name of the entity /table, followed by the GUID –

Both the option worked –

Hope it helps..

Advertisements

Run as option in When a row is added, modified or deleted trigger – Power Automate


Let us see Run As option of When a row is added, modified or deleted trigger in action, to understand its behavior.

Below is our example flow – it triggers when a field on the case is updated and then it updates the lead record.

Here we have not specified any value for Run as for When a row is added, modified or deleted trigger step.

On updating a case record using the User 1 account who is also the Flow Owner, we can see the modified user as User 1 for the lead record.

Let us trigger the flow this time through User 2.

This time also modified by for the lead record is User 1, even though the Modifying User and Row Owner were different.

So if Runs as is not specified, the Microsoft Dataverse actions are performed using the context of the Flow Owner.

To test it further let us remove the update rights of User 1, who is the flow owner, and trigger the flow again using User 2.

As expected the flow run fails this time.

Principal with id 7252e222-c07f-ec11-8d22-000d3a98d479 does not have WriteAccess right(s) for record with id 8ce6c6de-1bff-e411-80d4-c4346bac4730 of entity lead

Not let us specify Run as = Modifying User this time, and trigger the flow using User 2 again. (we have restored the rights of User 1)

This time also we can see the modified by the user as User 1 (Nishant Rana) the flow owner.

For it to run under the context of the user set as “Run As” in When a row is added, modified or deleted trigger, we need to select the Use invoker’s connection setting for the Update a row step.

Let us trigger the flow again through User 2, remember we have Run As set as modifying user.

Interestingly it still shows User 1 as the Modified By user.

Let us again remove the write rights of User 1 and trigger the flow using User 2.

This time flow is successful. If you remember it failed last time when we removed the User 1 rights and the Run as was default Flow Owner.

And this time, it shows modified by as User 2. (as we can see for user 1, the record is read-only as we have the rights removed)

This time it worked because had set Run As as Modifying User and specified Use invoker’s connection for the subsequent step i.e. update a row in this case, so it used User 2’s context which modified the case record to trigger the flow, which in turn updated the lead record using user 2’s context.

Now it will fail if User 1 updates the case record and triggers the flow because it will try to update the lead record using its context i.e. Run as = modified by

We will observe a similar behavior with Run As = Row Owner.

In case the owner of the record is a team, instead of a user, then it falls back to the flow owner option.

Get all the details here – https://docs.microsoft.com/en-us/power-automate/dataverse/create-update-delete-trigger#user-impersonation-using-run-as

Also check – https://d365demystified.com/2020/10/30/run-as-context-in-cds-current-environment-flow-trigger-power-automate/

Hope it helps..

Advertisements

Fixed – Flow client error returned with status code “Forbidden” and details – MissingAdequateQuotaPolicy, the user does not have a service plan adequate for the non-Standard connection in Power Automate


Recently one of the users reported this error while trying to Test a flow.

Request to XRM API failed with error: ‘Message: Flow client error returned with status code “Forbidden” and details “{“error”:{“code”:”MissingAdequateQuotaPolicy”,”message”:”The user ‘8a47d139-662e-4b73-bca3-53a59e8bebeb’ does not have a service plan adequate for the non-Standard connection ‘Microsoft Dataverse’. https://go.microsoft.com/fwlink/?linkid=2123710″,”extendedData”:{}}}”. Code: 0x80060467 InnerError: ‘.

As here the Premium Dataverse connection was being used, the resolution was to either purchase a Per User plan or Per Flow plan or to enable the trial of Power-Automate per user plan.

After the trial was enabled for the user, the error got resolved.

Hope it helps..

Advertisements
%d bloggers like this: