The deleted sites are retained for 93 days and an Admin can restore them. In this blog post let us see how to get the deleted SharePoint site details using Microsoft Graph API application permission.
Step 1: Register an application in Azure AD and obtain the client id, client secret & tenant id for the registered application. Add Sites.Read.All Microsoft Graph application permission
Step 2: Find the list GUID of the Hidden List DO_NOT_DELETE_SPLIST_TENANTADMIN_ALL_SITES_AGGREGA which has all the deleted site information from the tenant.
Make a GET request to the following Graph API endpoint with the token generated from the above AD app using PostMan or using Graph Explorer if you are an Global or SharePoint administrator
There are activity alerts which you can setup from Security center for Deleted Site but it will send you information on the Site URL and the name of the user deleted the site, as of now it does not provide the Title, Site ID etc. So this API can provide you additional details. Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.
In SharePoint Online sites, Audience targeting feature enables you to target relevant content to specific audiences enabling personalization through Microsoft 365 group, Azure AD Security group, Mail Enabled Security group or any combinations of these. The Membership type of the groups can be both Assigned and Dynamic. Target audience(s) can be defined on modern SharePoint pages, News post, Navigation links and as well as items on document libraries. I have used this feature for my customers on many instances to target News articles to specific audiences, but the challenging part is the content creator or Author of the News post should remember the name of the groups. In this post, let us see how to make the audience targeting for SharePoint online News post easier using
Term Store
Power Automate Cloud Flow
Find below the snapshot from the Page Details section of the News page
Isn’t the above easier than remembering name of the groups to target content?
Pre-requisite:
Access to create Power Automate cloud flow
SharePoint
A SharePoint site with Audience Targeting enabled
Site Owner or Administrator access
Access to Create terms @ tenant level or site collection level
Azure AD Groups
Service account with the permission level Full Control or Contribute on the SharePoint site with the Audience Targeting enabled
Term Set Creation & Group Mapping:
The first step is to create a Term set at tenant level or local (Site Collection) level for storing the group information based on your organizational hierarchy. The term set will be used to target content in SharePoint News post. Find below the term set Audiences I have created at tenant level under the term group People
Based on the hierarchy or needs, you can enable or disable tagging at any term level
After you identify the Azure AD groups to be mapped against each term, have the group object id in the below format
Select the appropriate term which is available for tagging, click Edit to add the group object id in the above format in the description field as shown below
After the mapping of term set & groups are done in the Term Store Management interface, copy the Unique Identifier (GUID) of the Term Group (People) and Term Set (Audiences) and keep it handy which will used in the Power Automate flow later
Settings in SharePoint Online site for Audience Targeting:
In the SharePoint online communication or Teams site
Step 1: Enable the audience targeting feature on the page library as per the instructions in this article. As soon as the feature is Enabled, there will be a column Audience added to the Site Page content type at the Page Library level. There can be a maximum of 50 groups added to the audience field.
Step 2: Create a Managed Metadata site column by the name Audiences with the setting Multiple Value Field mapping to the termset Audiences created above from the Term Store management. The managed metadata column can also be created at a Term level instead of a Term set. Once the site column in created, add the site column to the content typeSite Page as shown below
Step 3: Hide the default Site Column Audience from the Site Page content type at the Pages Library settings as shown below
Click the Audience field and make it hidden as shown below
Step 4: Grant the Service account access to the SharePoint site, either as a Site Administrator or Site Owner. The Service account will used in the Power Automate flow to update the Audience field from the values obtained from the Managed metadata column.
Automated Power Automate Cloud flow:
The Power Automate cloud flow will be used to get the claim information of the group stored in the description field of each Term in the Audiences Term set. This flow will be triggered after the News Post is published by the author.
Step 1: Create an Automated flow with the SharePoint trigger When an item is created or modified. The trigger Created or Modified is to make sure it fires whenever there is a change in the Audiences managed metadata column information. Enter the site address of the SharePoint site in context and the Library Guid of the Site Pages Library.
Step 2: Add the action Initialize variable of type Array as shown below
The Array variable will be used to create an array of group claim values selected from the Term description field.
Step 3: This step is to create the array of group claims based on the users selection from the Managed metadata column.
Add a Compose Action and add the property Audiences TermGuid from the trigger When an item is created or modified. This step will automatically create the Apply to each control, since the Managed metadata column allows multiple selection
Add the action Send an HTTP request to SharePoint with the below parameters
Replace the term group and term set guid on the Uri based on the information copied earlier from the Term Set Management interface. In the Uri, after terms it is the output of the compose action added in Step 2. If your Term Set is at the Site collection level, the site address should be the site URL
For references on the API endpoints, refer to the Graph API documentation for Taxonomy
Add a compose action to store the term description (Group Claim) extracted from the Term set api response. To directly get the description value from the response, the following expression will work
Step 4: The information to update the audience field is available in the array variable targetAudiencesClaims. So the next step is to update the Audience property in SharePoint News post, to do so add the action Check out file, Update file properties and Check in file as shown below
Enter the Site Address and Library Name information, the Id field should be from the dynamic content of the trigger When an item is created or modified. The Audience property in the action Update file properties should be the output of the Array variable targetAudiencesArray
Note: Click the button T on the property Audience to switch to input entire array from the variable.
Trigger Conditions:
There is an issue with the above update, the flow will result in infinite trigger loop due to the trigger type When an item is created or modified. To overcome this problem, the update must be done using a service account and Trigger conditions. Find below the connection setting using a service account for Update file properties action, replicate the same setting for the Check out file and Check in file
Add the following Trigger Conditions from the settings of the trigger When an item is created or modified for
To trigger only when a News post with major version is published
Target audience feature is SharePoint is one of the most useful feature in setting up intranet leveraging Microsoft 365 services and I hope this can complement the rich features Microsoft 365 already has. I will write in future how to deploy this flow automatically to different SharePoint sites. Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.
Do you like this article?
Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I publish them.
SharePoint Online Pages library is a container for different type of pages (News post, Page, Space, News Link) created in a Communication or Team site. There can be various scenarios to have a Power Automate Flow associated to a SharePoint Site pages library to handle additional processes after a Page or a News post is published. In this blog post, let us see how to
Trigger the flow if a News post is published
Trigger the flow only for Major versions
Trigger the flow for a specific Content Type
Avoid infinite trigger loop on an Item Created/Modified trigger if a page/list item is updated by the flow
using Trigger Conditions. Trigger conditions can be used on a trigger to stop your Automated Flow from running if the conditions are not met. Unnecessary flow runs can spend your quota limits based on the license types without providing any value. To begin with, create an automated cloud flow with the SharePoint trigger When an item is created or modified and configurations for the Site Pages Library. Once you provide the Site URL where your Site Pages library exists, you will notice the Site Pages library doesn’t show in the drop-down. In the List Name property, just provide the guid of the library instead.
To get the guid, browse to the Site Pages library on the SharePoint site, go to Library settings and select the value after the List= parameter on the URL after decoding.
Trigger the flow if a News post is published
There can be scenarios to trigger the Flow when a News post is created or modified. A SharePoint property PromotedState can help identify if the SharePoint page is a News post or a normal page since all the different types of pages are stored in the same library.
Label
Value
What it means
NotPromoted
0
Regular Page
PromoteOnPublish
1
News post in draft mode
Promoted
2
Published News post
The trigger condition will make sure the trigger is fired only when ever there is a News Post is published or Saved as draft (All Major and Minor versions).
The following trigger condition will make sure to fire only for Major versions (1.0, 2.0, 3.0 etc) and not for minor versions aka draft version (0.1, 0.2 etc)
@contains(triggerBody()?['{VersionNumber}'],'.0')
Trigger the flow for a specific Content Type
Content types in SharePoint are a set of columns that are grouped together to serve a specific type of content (Crisis News, Marketing News etc). A Page or a News post in a SharePoint site can be associated with content types. The trigger condition for the flow to be triggered only for a specific content type is
@equals(triggerOutputs()?['body/{ContentType}/Name'], 'Name of the Content Type')
Avoid infinite trigger loop on an Item Created/Modified trigger if a page/list item is updated by the flow
In your Automated cloud flow, if you have the Created or Modified trigger with an action to update the same item then there will be an infinite trigger loop.
The Flow checker will provide you a warning Actions in this flow may result in an infinite trigger loop. To overcome the above warning, trigger condition to the rescue.
How it will be done
The update item action on the flow should use a different connection (Service Account) in the flow, other than the user who will be using the site to create or update pages. The trigger condition will make sure the flow run will not happen if the update to the Page or News post is done by the service account using the Update item action. SharePoint Library and List has the out of the box column Modified By which holds the information on who has recently updated the item be it from the SharePoint UI or through program. The trigger condition will be written based on this column Modified By, if the column value has a different value other than the service account then the flow will be triggered.
Step 1: Create a service account with password never set to expire. Licenses are not required for this account if the flow connection is going to be used only on SharePoint connectors. Password setting Never Expires will make sure the connection is not invalidated due to a password change on the account.
Step 2: Grant edit access for the service account to the SharePoint site. This step allows the account to updates to the List or Library item.Step 3: Add a new connection to the service account
Step 4: Add the following trigger condition to the SharePoint trigger if the service account does not have an Exchange Email License
Before adding the condition to the trigger, evaluate the condition on a compose action using expressions and data fields selected from Dynamic content.
After the condition is added on the compose action, click Peek code
Copy the expression from the inputs parameter
The condition to be added on the trigger must be True for the trigger to fire.
Summary:
Trigger conditions are powerful if used wisely to avoid unnecessary runs. I’ve shown some examples from the SharePoint pages library but it can be used on List trigger as well. The trigger can be written based on any data available on the trigger output. Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.
Do you like this article?
Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I publish them.
Postman collections makes the creation of custom connectors in Power Automate easier & quicker. As of time I am writing this article, to create a custom connector using Postman collection in Power Automate the version of Postman collection has to be V1. The current version of collections exported from Postman is V2. There is a NPM package by the name Postman Collection Transformer to rescue which helps converting the collection to V1 and vice versa.
Step 4: V1 Postman collection is ready, you can now proceed with the creation of custom connector in the flow portal.
As pointed out by Richard Wilson, there are third party portals (Requires Registration) available which helps in converting the format of the Postman collection.
Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.
Do you like this article?
Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I publish them.
Content type multipart/form-data is used to send both text and binary data to the server and x-www-form-urlencoded is used more generally used to send text data in a query string in the form of name value pairs separated by ampersand. In this blog post, let us see how to use the content-type
multipart/form-data
x-www-form-urlencoded
in a Power Automate or Logic apps HTTP action to post data with an API which has implemented the content-type. Find below the screenshot from postman with a sample API
multipart/form-data in HTTP Action:
From the above screenshot, the API is called using the content type multipart/form-data. The multipart refers to the data (in the above screenshot it is To, From & Body) which is divided into multiple parts and sent to server. For each key value pair aka part, you will have to construct something like
{
"headers": {
"Content-Disposition": "form-data; name=\"KEY\""
},
"VALUE": "what ever value you would like to send"
}
Backslash is used close the Content-Disposition header value else you will get Invalid-JSON.
To call the API displayed from the above screenshot on the HTTP Action, the body of the HTTP action should have the two attributes $content-type and $multipart as shown below
{
"$content-type": "multipart/form-data",
"$multipart": [
{
"headers": {
"Content-Disposition": "form-data; name=\"To\""
},
"body": "whatsapp:+123456"
},
{
"headers": {
"Content-Disposition": "form-data; name=\"From\""
},
"body": "whatsapp:+178910"
},
{
"headers": {
"Content-Disposition": "form-data; name=\"Body\""
},
"body": "Your appointment is coming up on July 21 at 4PM"
}
]
}
You can upload files using the form-data content type
The file content can be the output of the SharePoint or OneDrive connector.
x-www-form-urlencoded in HTTP Action:
The x-www-form-urlencoded content type has its form data which is encoded and sent in a single block on the HTTP request body. To call the sample API from the screenshot posted at the top of this post in the HTTP Action, the form values must be encoded & the values be separated by ampersand. Expression encodeUriComponent can be used to encode the form values
Headers:
Key: Content-Type
Value: application/x-www-form-urlencoded
Body (Separated by &):
Key=Value&Key=Value
Find below screenshot for your reference
Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.
Do you like this article?
Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I publish them.
SharePoint connector in Power Automate is very rich with various actions that can make the developers or makers life simple when it comes to interacting with SharePoint data. There might be some actions like
Breaking permission to a list item
Creating a site
Adding user to a SharePoint group etc
which is not possible through the SharePoint standard connector or MS Graph API as of the time I am writing this article, SharePoint REST API to rescue. The SharePoint online REST API enables developers to remotely interact with SharePoint data. There is an action Send an HTTP request to SharePoint which could come handy in many scenarios, the point to note here is the action uses the context of user aka flow creator while executing the API. In this blogpost, let us see how to call a SharePoint REST API to create a Modern SharePoint communication site as an application in a Power Automate cloud flow using the HTTP connector with the help of a Self-Signed certificate. Find below the list of steps to enable calling the SharePoint REST API using certificate credentials
Creation of Self-Signed certificate
Application Registration in Azure AD Portal
Creation of Power Automate cloud flow with the HTTP Connector
Method 1: Without using Azure Key Vault
Method 2: Azure Key Vault to store Certificate
Pre-Requisites:
Access to HTTP Premium Connector in Power Automate
Register an application in Azure AD and obtain the client id & tenant id for the registered application. In this example I have added the Sites.Read.All Application permission with Admin Consent to create the SharePoint communication site, this permission is more than enough to create the site as an Application. Grant appropriate permission based on the requirements, for e.g to break permission on list items grant Sites.Manage.All. Find below screenshot for your reference for granting permissions
To add the above created self-signed certificate, click Certificates & secrets under the Manage blade. Click Upload certificate > Select the certificate file MSFlow.cer > Add
Creation of Power Automate cloud flow with the HTTP Connector:
Let us see below how to access the SharePoint REST API to create a SharePoint site with & without using the Azure Key Vault.
Method 1: Without using Azure Key Vault
Method 2: Azure Key Vault to store Certificate
Method 1: Without using Azure Key Vault
In the cloud flow, add a Compose action to store the PfxBase64 value copied during the creation of the certificate. Now add the HTTP action to create a Modern Communication site
Password: Certificate password given during the creation
Find below screenshot for your reference
Run the flow, it should be able to create the Site. Find below screenshot of the flow run
Method 2: Azure Key Vault to store Certificate
Azure Key Vault is a cloud service for storing and accessing secrets enabling your applications accessing it in a secure manner. Follow my blog article which I have written to call a Microsoft Graph API with Certificate using a Azure Key Vault to store the certificate
Custom Connector can be used to call a SharePoint REST api in the context of the user. If you are visiting my blog for the first time, please do look at my other blogposts.
Do you like this article?
Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I publish them.
In this blog article, let us see how to call a Microsoft Graph API as an application in a Power Automate HTTP connector using a certificate credentials instead of a secret from the Azure Active directory application. Microsoft recommends using a certificate (instead of a client secret) as a credential for a higher level of assurance. Find below the list of actions to enable calling the Graph API using certificate credentials
Creation of Self-Signed certificate
Application Registration in Azure AD Portal
Creation of Power Automate cloud flow with the HTTP Connector
Method 1: Without using Azure Key Vault
Method 2: Azure Key Vault to store Certificate
Pre-Requisites:
Access to HTTP Premium Connector in Power Automate
The first step is to create a certificate. A self-signed certificate can be created by using the Windows PowerShell command New-SelfSignedCertificate or PnP PowerShell command New-PnPAzureCertificate. The self-signed certificate will be used in the Azure AD application. Find below PnP PowerShell command to create the certificate with the default validity of 10 years and secured with a password.
From the above screenshot, the certificate files MSFlow.pfx and MSFlow.cer will be available on C:\Users\ashiq\Desktop\Projects\PowerAutomate. Copy the PfxBase64 and the password which will be used in the HTTP connector while calling the Graph API. To get the details of an existing certificate, the PnP command
Register an application in Azure AD and obtain the client id & tenant id for the registered application. In this example I have added the Application permission with Admin Consent to access all the recent events of a user from Outlook.
To add the above created self-signed certificate, click Certificates & secrets under the Manage blade. Click Upload certificate > Select the certificate file MSFlow.cer > Add
Once the certificate is added successfully, you would be able to see the certificate Thumbprint with the Start date & Expiry date
Creation of Power Automate cloud flow with the HTTP Connector:
Let us see below how to access a Microsoft Graph API with & without using the Azure Key Vault.
Method 1: Without using Azure Key Vault
Method 2: Azure Key Vault to store Certificate
Method 1: Without using Azure Key Vault
In the cloud flow, add a Compose action to store the PfxBase64 value copied during the creation of the certificate. Now add the HTTP action to get the users events from the default calendar
Password: Certificate password during the creation Find below screenshot for your reference
Find below screenshot for your reference
Run the flow, it should be able to get the outlook events as an application for the given user.
Method 2: Azure Key Vault to store Certificate
Azure Key Vault is a cloud service for storing and accessing secrets enabling your applications accessing it in a secure manner. Follow this article to upload the above generated certificate to the Azure key vault.
After the certificate is uploaded to the Azure Key Vault, with the help of the premium Azure Key Vault connector you would be able to access & use the secret in your cloud flow or logic app.
Step 1: Add the action Get secret in the flow. After entering the name of the Key Vault and the sign button is clicked, the connection would be established.
There are different authorization flows available in Microsoft Graph which could be leveraged based on needs. If you are visiting my blog for the first time, please do look at my other blogposts.
Do you like this article?
Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I post them.
If the HTTP request you make in Power Automate cloud flow gets a 200 OK response, all is good but if the HTTP response has the status codes like 408 – Request Timeout, 429 – Too many requests, 522 – Connection Timeout, 404 – Not found, 400 – Bad request etc there is a problem which needs attention. This post will show you how to handle HTTP request failures using
Retry Policy
Custom Retry for requests which cannot be handled by Retry Policy
Take actions based on HTTP status code
Retry Policy:
A Retry Policy specifies how the action or trigger retries a request when the original request times out or fails. The retry policy handles the following HTTP status codes
408 – Request Timeout
429 – Too many requests
5xx – xx refers to any number like 500 – Internal server error, 503 – Service Unavailable, 522 – Connection timed out etc
HTTP Action supports retry policy and by default the action retries 4 times at exponentially increasing intervals if there is a request failure. To view or update the Retry Policy configuration settings for the HTTP action, navigate to settings as shown on below screenshot
If you have to retry the request for more than 4 times or set some custom interval between retries, you can do so by changing the retry policy from Default to Fixed interval or Exponential interval as shown below
The policy waits for a specified interval before sending the next request.
There will not be any retry if the policy is set to None. For more details on the retry policies, go through this documentation from Microsoft. Find below screenshot of a Fixed Interval Retry Policy which attempts to make a HTTP request 5 more times after the first failed request with a 10-minute delay between each attempt.
The retry interval accepts value in ISO 8601 format. In the above screenshot for the interval field with value PT10M
P is the duration designator and T is the time designator, where M is the minute designator. PT5S translates to 5 seconds. For testing the policy with the HTTP action you can get sample http request links with different status codes request url’s from https://httpstat.us/.
The retry information will be logged in the flow Run history as shown below
Custom Retry for requests which cannot be handled by Retry Policy:
The retry policy handles only HTTP status codes 408, 429 and 5xx. On this section let us see how to handle the other types of HTTP status codes or non-retry-able errors. Let us take an example with a requirement to retry HTTP request with status code 400 – Bad request till the request succeeds.
Step 1: Initialize a boolean variable ExecuteHTTPAction with the default value true. For the Boolean value use the expression true.
Step 2: Add a Do until control. The loop runs for a maximum of 60 times (Default setting) until the HTTP request succeeds or the condition is met. The Left side placeholder should have the ExecuteHTTPAction variable as a value and the right side should have Boolean variable False. Use Expression to enter the Boolean variable false.
Toggle between Edit in advance mode and Edit in basic mode if the right side placeholder to enter value is disabled.
Step 3: Add the HTTP request action and an action to Set variable ExecuteHTTPAction named as Set Variable – HTTP Action Success. Set the value of the variable to boolean false which means on HTTP action success (200 OK), there should not be any retry.
Step 4: Once the Set variable action is added, just above the action click + and Add a parallel branch as shown in the above picture. On the other side of the branch add an action Set variable named as Set variable – HTTP Action Failure to set the ExecuteHTTPAction variable to true which means there should be retry
Step 5: The last step is to configure Run after for the action Set variable – HTTP Action Failure. Find below screenshot for the Run after configuration
No change is required for Set variable – HTTP Action Success, just ensure the Set variable – HTTP Action Failure has the Run After has failed. You can add a Delay action after the parallel branch to make sure the HTTP request is made after certain interval based on scenario. You can also add scope controls for TRY, RETRY etc.
Alternative Method:
The other way to do this without adding the parallel branch is as shown below
Take actions based on HTTP status code:
If you have to take different actions based on the HTTP status code, for example call a different API when there is an HTTP 404 – Not found etc. The quick way to do this is get the HTTP status code of the HTTP request by adding the Compose action below the HTTP request action and select the Status code from the Dynamic content which is an Output of the action HTTP.
Now configure the run after for the compose action as shown below
The compose action would now be able to capture all type of HTTP status code. With the status code in hand, add a switch control to take different actions based on HTTP status code.
Summary:
On this post we have seen how to handle different HTTP request failures codes with options to Retry in your Power Automate flow. You can apply this technique to handle HTTP request made via custom connector, SharePoint Connector etc. Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.
Power Automate Management connector enables interaction with Power Automate management service to manage your flows with different actions to create, edit and update flows. If you want to do more but you were not able to find an action with this connector for e.g. get details on the Runs the flow has made, as of now there is no action which gets the run details of a flow with the Power Automate Management connector. So how to get the Runs the flow has made and even more actions like turning on/off/disable a flow etc? There are REST APIs with different endpoints for Power Automate, as of now there is no documentation from Microsoft on these API’s but there is documentation for Azure Logic Apps REST API. It is quite easy to convert the Logic Apps REST API for Power Automate operations. The APIs are secured with Azure AD OAuth 2.0, in this blog post let’s see how to call these API’s using
Custom Connector
Authorization code flow
Implicit flow
Let’s start this post with the API endpoint to list the flow runs for Azure Logic Apps & Power Automate. Find below the API endpoint for Azure Logic apps as per this documentation to list the Workflow Runs
The API version for Power Automate can be different in Microsoft 365 when compared against Azure Logic Apps. This information can be identified using fiddler or any browser-based developer tool (Network) by analyzing the http request traffic the portal makes to API endpoints for different operations after logging in to the Power Automate Portal. Find below screenshot regarding the API version on the home screen of the portal
As a first step towards accessing the API endpoint for Power Automate, there must be an Azure Active directory app registered in the AD tenant of the Microsoft 365 environment which has the Power Automate environment.
Azure Active Directory App Registration:
Register an application in Azure AD and obtain the client id, client secret & tenant id for the registered application. After the app is registered, follow the below steps to grant permission for the app to call the Power Automate Flow APIs:
In the App, click the API permission under the Manage blade and then click + Add a permission. Under the Microsoft APIs tab, click Flow Service as shown below
The flow API as of now supports only delegated permission (User Context). Now select the Permission based on the requirement. For this post, I have selected the permission Flows.Manage.All for listing the runs of the flow
The app is registered with the necessary configurations, let us now see how to call the Power Automate API using a custom connector. The custom connector takes care of generating the authorization token required to access the API using the authorization code flow.
Custom Connector to call the Power Automate APIs:
A custom connector is a wrapper around a REST API (Logic Apps also supports SOAP APIs) that allows Logic Apps, Power Automate or Power Apps to communicate with that REST or SOAP API. In the Power Automate portal expand Data on the left panel > Custom connectors > + New custom connector > Create from blank
After entering the connector name, in the General information enter the description and Host name to api.flow.microsoft.com
Now click Security on the right bottom corner to enter the Azure AD application information for the OAuth 2.0 authentication type. Under the section OAuth 2.0
Change the Identity provider to Azure Active Directory
Enter the Client id & Client secret of the Azure AD application
After the above information is filled in, click Create connector which autogenerates the Redirect URL https://global.consent.azure-apim.net/redirect. This is the URL we have added as a Redirect Web URI in the Azure AD application. The connector is now ready for the actions to list the flow Runs with the help of Power Automate REST API endpoint.
Action to List Flow Runs:
The Power Automate REST API endpoint to list the flow runs is
After the custom connector is created in the above step, now click the Definition tab of the Custom Connector > click + New action to enter Summary, Description & Operation ID of the action > Click + Import from sample to enter the above API endpoint to list the flow runs in URL box and Verb as GET > Click Import
Click Update connector. To the test the action, click Test at the bottom right corner. In the following screen, create a connection and then pass the parameters for Power Automate Environment, Flow GUID & API Version of the Power Automate REST API. Flow GUID & Environment ID can be obtained from any of your existing flow in the environment. To get these information navigate to the My Flows section in the Power Automate portal and click any flow, the information will be on the URL as shown on the below sample
After entering the details, click Test operation to get the list of run details the flow had till now. You can get details like the status of the flow, flow start time & endtime, flow run id etc on the response
Copy the Response body from the above screen to add it to the default response for the action. Click the + Add default response on the action definition screen > Click + Import from sample > Paste the copied value to the Body section > Click Import.
The above step is recommended to parse the information of the response either in Power Automate or Power Apps. The sample Custom connector used for this blogpost can be downloaded from here.
Find below some REST API endpoints for different operations:
The above operations are just some samples, if you would to get the REST API endpoint details for different operations, go through the Logic Apps rest API documentation. You can also use Fiddler tool or browser developer tools to help you in finding the corresponding API endpoints after logging in to the Power Automate portal and then performing various operations within the portal interface.
Custom connector takes care of generating the token automatically to call the Power Automate REST APIs secured with OAuth but if you have to call these API programmatically in an application, you can use any one of the below authentication flows to generate the token.
Authorization code flow for token generation:
As the first step to generate the token using Authorization code flow, add the Redirect URI in the Azure Active directory app for your application. For this example, I have added http://localhost/ as a Redirect URI for the Web platform as shown below
Make the above change on the Azure AD application which was registered initially in this post to access Power Automate REST API. Construct the following URL after replacing the tenantId and azureAppId to generate the code in any browser for generating a token
After the above URL is accessed in the browser, you will be prompted to sign-in. Once the sign-in is complete, a code will be generated in the below format on the browser address bar as a response to the sign-in
The code can be used to redeem for an access token. Make the following HTTP request to generate the access token after replacing the tenantId on the request URL
Replace the AzureAppId, code value copied from the above request and the appClientSecret.
Headers:
Key: Content-Type
Value: application/x-www-form-urlencoded
Find screenshot below for the Postman request
The generated token can be used to access different Power Automate REST API endpoints based on the permissions you have consented to the Azure AD application by passing the token on the Authorization header as Bearer.
After any of the above URL is accessed in the browser, you will be prompted to sign-in. Once the sign-in is complete, access token will be generated in the below format on the browser address bar as a response to the sign-in
Also go through this documentation from Microsoft which has information of the different types of connectors to automate tasks with Power Automate.
Summary: On this post we have seen how to use Power Automate REST API to manage your cloud flows. These APIs works for both individual flows (My Flows) and flows which is part of the solutions. Power Automate REST APIs are very powerful to manage your cloud flows. I can think of scenario where in you can resubmit all your failed flows programmatically leveraging these API endpoints. Microsoft has documented WEB API for Power Automate flows included in solutions. If you are visiting my blog for the first time, please do look at my other blogposts.
I had a recent requirement to call a GraphQL based API secured with OAuth2 in Power Automate, this blog post is to share my learnings on GraphQL & how to call them in Power Automate. Let us quickly see some introduction to GraphQL
GraphQL is an open-source query language for your APIs with a service-side runtime for executing the queries based on pre-defined schema. It is not tied to any specific database but rather backed by your existing code and data.
A GraphQL API is different from a REST API in that it allows the client application to query for certain fields of resources. Send a GraphQL query to your API and get exactly what you need, like the name of a user and only receive that data.
GraphQL APIs get’s all the data a client needs in a single request.
It replaces multiple REST requests with a single call to fetch the data you specify.
Provides an abstraction layer to the client, which means that clients do not need to query multiple URLs to access different data.
Find some comparisons against REST
REST
GraphQL
HTTP Verbs (GET, POST, PATCH, PUT, DELETE) determines the operation to be performed
You will provide a JSON body aka GraphQL query whether you have to read or fetch values (GET) or a mutation (POST, PATCH, PUT, DELETE) to write values
When a HTTP GraphQL request is made with a query, the GraphQL server parses the query and respond back with data usually in a specific JSON format. There can also be variables in a query which makes it more powerful and dynamic. In GraphQL, the HTTP verb is predominantly POST but there can be implementations where Query & Variables are sent in URL encoded query parameters in the URL. I have used GitHub to learn & test GraphQL queries against my GitHub account.
GitHub GraphQL Explorer:
Github has GraphQL API that allows you to query and perform operations against repositories, users, issues, etc. To follow along this blogpost, sign in with your GitHub account on the GitHub GraphQL explorer URL https://docs.github.com/en/graphql/overview/explorer for testing some GraphQL queries
Create a Repository in your GitHub account
Get all your existing repositories
Let’s make first query on the explorer to get your GitHub Id for creating a new repo, the query is
{
viewer {
login
id
}
}
In Explorer
Type your queries on the left side panel and hit play to see the JSON response on the right side. Click the Docs link on the right top corner to go through the documentation. The GitHub graphql explorer can be a great starting point to learn and to write queries
Tip: Hitting Ctrl+Space on the explorer will show you all the available fields that you can query against the API.
Create a Repository in your GitHub account:
Find below the query & variables to create a Repo in your GitHub account. The ownerId on the query variables should be value copied from the previous query. The other observation on the query is we are using mutation since we are creating a repository
Query to create a Repo with out passing a query variable:
Find below the query to get all your existing repositories
{
viewer {
name
repositories(first: 100) {
totalCount
nodes {
name
}
}
}
}
Till now we have seen couple of example queries in GitHub explorer, let us now see how to consume them in Power Automate
Call a GraphQL query in Power Automate:
HTTP connector in Power Automate can be used to call a GraphQL query based API but you will have to first convert the GraphQL query (Query+Variables) to a HTTP request with raw body. You can use the Postman utility to help you with the conversion. To call the above mentioned GraphQL query to create a Repo in Postman, the first step is create a Personal Access token. Create the token as per the instructions given in the following documentation with the scope repo selected
Token value should be the Personal Access token you have generated above. Find below screenshot for your reference in order to set the authorization token
In the request Body tab, enter the Query and GraphQL variables for creating the repo after selecting the Body type to GraphQL from none
On the query tab, CTRL+Space also works in Postman which autoprompts with some suggestions for fields.
Execute the request by clicking Send button which will create a New repo by the Name GraphQLDemo-blog in your github account. To call this GraphQL query in Power Automate, click the Code button as shown above on the right panel of the postman request and then select HTTP to auto generate a code snippet for making a HTTP request with raw body
Copy the request body as shown above. On the Power Automate HTTP connector, enter the following details to create the Repo
Summary: On this post we have seen how to call a GraphQL query based API from Github in Power Automate using a HTTP connector to create a Repo, this can be replicated to consume any other GraphQL based APIs. You can also construct dynamic request body on the HTTP connector for various operations. Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.
Mohamed Ashiq Faleel 