Monitoring the Power Platform: Power Automate – Run Time Part 1: Triggers, Workflows and Actions
Summary
is a service allowing makers to create business processes, orchestrations and workflows to help achieve common and even complex business requirements. Within the Power Platform, Power Automate represents one of the most important pillars of the platform. It provides a no to low code solution to process automation. From sending , to complex flows, Power Automate can be used in virtually any workload.
The goal of this article is to describe how to implement a monitoring strategy for both Microsoft Power Automate and the Azure Logic App services. Every Microsoft Power Automate Flow or Azure Logic App contain functions and objects which can help designers capture and troubleshoot run time information. Within this article we will explore triggers and how they can be configured to reduce runs with conditions. From there we will go into the various workflow and run time objects that help deliver meaningful run time insights into our flows. Finally we will wrap with actions and their outputs, which can be used as determining factors for conditions or for monitoring integration responses.
Triggers
Triggers are used to fire off a Microsoft Power Automate flow. They can be triggers that are invoked, triggers that reoccur and triggers that poll for a specific event. For more information regarding different types of triggers such as poll and push triggers, please refer to the ““ article.
Trigger settings consist of custom tracking identifiers, secure input and outputs, concurrency settings, schema validation and trigger conditions.
NOTE: CLICK ON AN IMAGE TO ENLARGE TO SHOW DETAIL
Secure Inputs and Outputs
Secure inputs and outputs can be used to hide input and output data on triggers and actions. Keep in mind , when using secure inputs and outputs. I’ll cover this more in the following article for reviewing run time data.
Concurrency and Parallelism
The concurrency control is a feature enabling designers to handle queued runs in the Power Automate pipeline. As described in the feature description, this can’t be undone once enabled. The , while out of scope of this document, are well documented. For may come in handy when dealing with concurrency in loops.
Schema Validation
Schema Validation is a useful feature when dealing with triggers that handle custom inputs, such as HTTP requests. Within these requests can reside any payload with different types of serialization. To help enforce and ensure delivery of meaningful data to downstream actions, schema validation can be used.
Typically, when working with HTTP requests in Power Automate, a sample JSON payload can be provided to help describe what data needs to be provided and what format. Within this description, designers can provide a . does a great job showcasing how this feature can be used.
Schema Validation, coupled with trigger conditions, provide designers robust techniques to ensure that a Power Automate flow is triggered only when needed data is available.
Trigger Conditions
Trigger conditions are used to enforce conditional policies to ensure Power Automate flows will fire only once all conditions have been met. They can consist of trigger body or headers properties that can be used in conjunction with expressions and functions in flow.
The following image shows a trigger condition that will keep the flow from firing unless the correlationid and body fields are present in the triggerBody object.
Trigger Object
Triggers can contain inputs, outputs, timings, keywords and statuses. Depending on the type of trigger you may or may not receive specific properties. Keep this in mind when attempting to read from the trigger object as some, such as recurrence, will not contain inputs and outputs.
The below image is the trigger for a Recurrence:
Here’s an example of the trigger object for Recurrence:
The below image is the trigger information for the Common Data Service, which unlike the Recurrence contains the Retry Policy feature:
Notice the host contains the specific operation id, but more important is the dataset parameter which shows which environment the trigger is listening to. In this case this represents the “(current)” environment. Additionally the correlation and client request identifiers (x-ms-correlation-request-id and x-ms-client-request-id) are shown which can help track and troubleshoot flows.
Workflow
The Power Automate run time information can be found in the workflow method which contains information about the flow, the environment, and the specific run. This object can be stored as a variable in the Power Automate flow and even can be passed as a response from the flow itself. The below image shows how the output when setting the “workflow()” function as an object.
The Workflow Time Stamps and Tracking Identifiers
Within the root of the workflow object lies properties that can help administrators track the specific workflow run. The , a tracking Id, start time and end time are displayed here. Looking into the time stamps I don’t see them lining up with the data provided for solution aware flows using the Get-FlowRun cmdlet, but more to the trigger timing. That said, Tracked Properties can help for stand alone action and/or flow duration tracking.
The Workflow Run Object
To find out more about the specific run, you can cast the workflow().run object as a variable and view the properties. Run properties include the id, the name, and the type. This information, specifically the “name” property, can be correlated to the ClientTrackingId found in the Get-FlowRun cmdlet which we cover in the next article.
For Azure Logic Apps, please refer to .
The Workflow Tags Object
Additionally, the flow is further described in the tags object. The tags object contains the display name (flowDisplayName), the environment it belongs to (environmentName), if its part of the common data service (solution aware) (sharingType) and the logic app name (logicAppName).
The tags object is extremely important for Power Automate Flows as it stores the information needed to find a specific flow in an environment. Using this tags object, coupled with the run object properties, will allow for deeper insights and analysis.
Capturing Connection and Action Responses
One of the greatest capabilities of Microsoft Power Automate is the ability to connect systems in a no code approach allowing makers from all sorts of background to develop integrations. Most of these integration connections perform some sort of action to gather and manipulate data, invoke a process, and return some value. Each of these actions includes some output which can be read and stored for further examination natively within a Power Automate flow.
The Action and Actions Functions
To begin working with Actions responses within other actions, . The Actions functions (both and ) can be used but work a bit different depending on how they are to be used.
The current action output at runtime can be read from using the action function. The function is limited to specific action types such as unsubscribe or do-until actions. They can also be added to Tracked Properties which are discussed in a following article.
To read information from previously run actions within a Power Automate flow, use . When using the actions function, the entire action object is presented. Included are shorthand functions , and .
Action Outputs
The output for a particular connector action can be read by using the expression outputs(‘<name of the action>@outputs(‘Update_a_record’)“.
You can see the top action is called “Update a record” and is a Common Data Service connector action.
The image above shows a comparison of the Common Data Service Trigger against the Action. Notice how the action includes the status code as opposed to the status of succeeded that the trigger produced. This status code along with the header and body is essential to finding out the outcome of our integration.
Output Header
The output, if using a connector, will include the header properties from the response of the connector. Inside here we can find information pertaining to accepted and expected formats. Session and cookie information including correlating identifiers such as “REQ_ID” or “x-ms-service-request-id“, can also be found here to troubleshoot. For Common Data Service calls, the aforementioned identifiers and API throttle headers can be used to help shed light on potential issues.
Output Body
The output body contains the response data from the connector request. Depending on what connector and action used, we’ll see various values. Typically, when designing Power Automate Flows, values from the output body are what are used downstream in other conditions and actions. For the Common Data Service, this could be list of records, responses from custom actions, or possibly empty.
For outputs, just like inputs, keep in mind the considerations when using the secure inputs and outputs feature.
Next Steps
In this article we have covered the beginnings of controlling and monitoring Power Automate Flow runs. Configuring triggers using Schema Validation and Conditions to reduce noisy flows were examined. Using functions such as workflow and actions to expose run time information was also discussed. This information, exposed from these functions and objects, will prove useful as we continue down the following articles for monitoring run time information in Microsoft Power Automate.
In the following articles covering Microsoft Power Automate Flow run time, we will explore tracked properties, secure input and output and how they can be used to extract and pass data between actions. We will also look at techniques for error handling. Finally we will discuss pushing events to Application Insights and reviewing previous flow runs for monitoring and governance.
If you are interested in learning more about , which includes a , please contact your Technical Account Manager or Microsoft representative for further details.
Your feedback is extremely valuable so please leave a comment below and I’ll be happy to help where I can! Also, if you find any inconsistencies, omissions or have suggestions, .
Index