• Home
  • About Us
  • Contact Us
  • Privacy Policy
  • Special Offers
Business Intelligence Info
  • Business Intelligence
    • BI News and Info
    • Big Data
    • Mobile and Cloud
    • Self-Service BI
  • CRM
    • CRM News and Info
    • InfusionSoft
    • Microsoft Dynamics CRM
    • NetSuite
    • OnContact
    • Salesforce
    • Workbooks
  • Data Mining
    • Pentaho
    • Sisense
    • Tableau
    • TIBCO Spotfire
  • Data Warehousing
    • DWH News and Info
    • IBM DB2
    • Microsoft SQL Server
    • Oracle
    • Teradata
  • Predictive Analytics
    • FICO
    • KNIME
    • Mathematica
    • Matlab
    • Minitab
    • RapidMiner
    • Revolution
    • SAP
    • SAS/SPSS
  • Humor

Monitoring the Power Platform: Power Automate – Run Time Part 1: Triggers, Workflows and Actions

June 12, 2020   Microsoft Dynamics CRM

Summary

 

Microsoft Power Automate 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 push notifications to mobile devices, to complex robotic process automation 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 “Monitoring the Power Platform: Power Automate – Connectors, Connections and Data Loss Prevention Policies“ 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

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

Secure Inputs and Outputs

 

Secure inputs and outputs can be used to hide input and output data on triggers and actions. Keep in mind important considerations, including the obfuscation of data and the impact, when using secure inputs and outputs. I’ll cover this more in the following article for reviewing run time data.

2318.pastedimage1591822760077v2 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

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 advantages and limitations of using concurrency and parallelism, while out of scope of this document, are well documented. For Common Data Service, the change set feature 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 additional schema to set certain fields as required. Joe Gill‘s article “Json Schema Validation in Logic Apps and Flow“ 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.

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

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:

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

Here’s an example of the trigger object for Recurrence:

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

The below image is the trigger information for the Common Data Service, which unlike the Recurrence contains the Retry Policy feature:

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

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.

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

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 clientTrackingId, 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.

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

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.

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

For Azure Logic Apps, please refer to this document detailing the REST API.

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).

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

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, review the Actions function documentation. The Actions functions (both action and actions) 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 the actions function. When using the actions function, the entire action object is presented. Included are shorthand functions actionBody, actionOuputs and body.

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

Action Outputs

 

The output for a particular connector action can be read by using the expression outputs(‘<name of the action>‘). In these action outputs, specifically ones that perform an external connection, are headers, the status code and output body. The value of the variable is an expression “@outputs(‘Update_a_record’)“.

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

You can see the top action is called “Update a record” and is a Common Data Service connector action.

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

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.

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

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.

 Monitoring the Power Platform: Power Automate   Run Time Part 1: Triggers, Workflows and Actions

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 specialized guidance and training for monitoring or other areas of the Power Platform, which includes a monitoring workshop, 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, please go here to submit a new issue.

Index

 

Monitoring the Power Platform: Introduction and Index

Let’s block ads! (Why?)

Dynamics 365 Customer Engagement in the Field

Actions, Automate, monitoring, Part, Platform, Power, Time, Triggers, “Workflows
  • Recent Posts

    • C’mon hooman
    • Build and Release Pipelines for Azure Resources (Logic Apps and Azure Functions)
    • Database version control: Getting started with Flyway
    • Support CRM with New Dynamics 365 Field Service Mobile App
    • 6 Strategies for Achieving Your Business Goals in the New Year
  • Categories

  • Archives

    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • March 2020
    • February 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    • December 2016
    • November 2016
    • October 2016
    • September 2016
    • August 2016
    • July 2016
    • June 2016
    • May 2016
    • April 2016
    • March 2016
    • February 2016
    • January 2016
    • December 2015
    • November 2015
    • October 2015
    • September 2015
    • August 2015
    • July 2015
    • June 2015
    • May 2015
    • April 2015
    • March 2015
    • February 2015
    • January 2015
    • December 2014
    • November 2014
© 2021 Business Intelligence Info
Power BI Training | G Com Solutions Limited