Welcome to the tenth post in my series focused on providing a set of revision notes for the PL-400: Microsoft Power Platform Developer exam. Last week, we reviewed the various tools available to help diagnose and troubleshoot issues with our Power Apps. With that, we finished our focus on the Create and configure Power Apps area of the exam. We now move onto the Configure business process automation area, which has a minor weighting on the exam (5-10%). Nevertheless, in the first topic area, candidates are expected to demonstrate knowledge of the following:

Configure Power Automate

• create and configure a flow
• configure steps to use Dataverse connector actions and triggers
• implement complex expressions in flow steps
• implement error handling
• troubleshoot flows by analyzing JSON responses from connectors

Power Automate is perhaps one of the most powerful automation tools we have at our disposal within the Power Platform. Let’s dive in and see what we can do with them as developers.

As with all posts in this series, the aim is to provide a broad outline of the core areas to keep in mind when tackling the exam, linked to appropriate resources for more focused study. Ideally, your revision should involve a high degree of hands-on testing and familiarity working with the platform if you want to do well in this exam.

Note on Terminology

In late 2020, shortly before the PL-400 exam went into general availability, Microsoft made some significant changes to the core terminology in some aspects of the Power Platform, chiefly affecting many of the concepts discussed in today’s post. I discussed these changes as part of a blog post last year, but, in a nutshell:

• Microsoft Dataverse became the new name for what was previously known as the Common Data Service. This change was announced and discussed further by Ryan Cunningham in a blog post last year.
• Within Microsoft Dataverse, many of the core features were subject to terminology changes. For example, entities are now called tables. Microsoft has provided an excellent summary that you can use to refer to the previous and new terms.

Microsoft has recently updated the PL-400 exam to reflect the new terminology. However, references to the old language occasionally appear in the tools discussed in this post. Therefore, you should take steps to familiarise yourself with the previous terms.

Power Automate

Overview

Previously known as Microsoft Flow, Power Automate is the logical evolution of the traditional workflow experience from Dynamics CRM / 365 and - over time - we can anticipate Power Automate slowly replacing this functionality. As well as affording us near-total feature parity with workflows, Power Automate flows provide us with a modern and highly tailorable means to automate a business process, using the capabilities within Azure Logic Apps to power everything. Through a visual editor, developers can build out an entire business process from start to finish. Also, via the implementation of traditional programming flow controls, it’s possible to make incredibly diverse systems talk together in ways that you could not have imagined previously. Some of the benefits that Power Automate provide us include:

• Access to well-over 315+ connectors to various data sources and applications, including SQL Server, Salesforce, Twitter, MailChimp and SendGrid, to name a few.
• The ability to trigger flows based on specific trigger points or schedules.
• Through implementing an on-premise data gateway, data sources not exposed for access across the internet become surfaced for use within Power Automate.
• Integrates seamlessly with canvas Power Apps, thereby allowing you to trigger a flow based on a specific action point within a canvas app.
• Robust testing and debugging capabilities.
• Allowing us to implement complex or straightforward approval workflows.
• Full support for use alongside solutions, letting us quickly deploy Power Automate flows out to multiple environments and incorporate flow design as part of your Application Lifecycle Management (ALM) processes.
• When your solution needs to scale, you can easily extract your flow and migrate it into Logic Apps to take advantage of more enterprise-focused features.

Power Automate flows, as mentioned, are designed to fill the gap for workflows. But they can go so much further than that and, often, negate the need to look at implementing plug-in’s or custom workflow activities to achieve more complex integrations. Developers should always explore and attempt to use Power Automate flows wherever possible before resorting to other solutions. Having full awareness of all the available connectors for Power Automate and also on the products specific limitations, from an execution standpoint, will help you best in making this judgement call.

Creating a Power Automate Flow

The Power Automate portal is your go-to destination for working with Power Automate. Accessible from within the Office 365 portal, within here you can:

• Manage any approvals assigned to you by other users.
• View, manage, edit or delete any flows created by you.
• Manage the various connectors setup for your account or within your organisation.
• Interact and work with Microsoft Dataverse.
• View and utilise existing flow templates, covering common business scenarios.
• Access and leverage AI Builder capabilities.

From a Power Automate flow creation standpoint, the main focus of your time will be within the visual editor, as indicated below:

This experience provides a fully immersive mechanism for developing your flows without needing to install additional tools onto your machine. After completing and saving your flow for the first time, it will start executing based on the predefined trigger action chosen for it. You can then do the following with a completed flow:

• Share it with other users within the organisation.
• Submit it as a template to Microsoft for inclusion within the template gallery.
• Export its definition as a solution file or a Logic Apps template.
• View analytics relating to it and its execution, e.g. total runs per day, number of errors raised etc. This feature utilises Power BI tiles, providing an intuitive experience when analysing the metrics for your flow.
• Toggle whether your flow is on or off.
• View a list of all previous runs for the flow, including the input/output information for each step.

In short, whether you need to test, diagnose or figure out whether users in your organisations are still using a flow, there are tools here to help you along.

Power Automate flows are built up of various core components, all of which you will need to be familiar with for the exam:

Connectors

These are the fundamental components that make Power Automate such a versatile solution by giving you the ability to connect up to various services or solutions, with a range of corresponding actions then made available for use. Typically, you will need to authenticate with each service using a valid username or password; once created, it is stored and available to use across multiple flows, if required. Connections will also be shared out to users automatically whenever you do the same for the flow itself. Consider carefully what impact this may have from a permissions or data protection perspective.

As mentioned earlier, the list of available connectors is vast and is growing all the time. Note also that, similar to Power Apps, Microsoft classifies some connectors as Premium. Connectors of this type will only be available to you if you have been assigned a paid Power Automate license, and Microsoft mark these accordingly within the Power Automate portal:

Developers also can build custom connectors to either use within their current tenant or publish for availability to any Power Automate the world over. This topic, which has its specific exam area for PL-400, will be covered in a future post.

It is worth discussing the Microsoft Dataverse (AKA Common Data Service) connector in further detail at this stage - not only because it’s a topic for the exam but also because it may lead to a degree of confusion when you first open Power Automate. The reason for this is that there are two CDS connectors available:

The first of these connectors is a solution-independent connector that has the following triggers/actions defined for it:

This connector allows you to connect to any Microsoft Dataverse tenant, regardless of the Office 365 tenant it resides within. This connector is most useful when your flow will always target a single environment. As such, there is no need to manage it formally within a solution, and you would only use it to perform basic CRUD operations targeting your Dataverse environment.

The second connector - titled Common Data Service (current environment) - is the complete opposite of the above and built for scenarios where you need to include your flow as part of a solution. Doing so will ensure the flow correctly detects the correct Dataverse environment to target after importing your solution successfully. As such, there is a far greater list of available actions for this connector, and a single trigger action is provided that covers all potential scenarios within CDS:

Wherever possible, you should be using the Common Data Service (current environment) connector and managing your flows within a solution. This will significantly simplify the process for rolling flows into different Dataverse environments should the need arise. For the exam, I would recommend that you read up on the standard and the current environment connector to be familiar with each one’s capabilities.

Triggers

In a nutshell, these are the things that start a Power Automate flow. A flow must always have a single trigger, and there are, broadly, three different types available to us:

• Action: These will typically occur based on an event within an application or system - for example, whenever a user creates a new row in Dataverse. Your Power Automate flow will poll the data source frequently to detect when this action step occurs and then kick off the flow accordingly. In the screenshot below, we see an example of the Dataverse action for creating a new row:

  • 

• Schedule: Flows of this type will run based on a pre-defined schedule. We have a high degree of control over the various settings here, including frequency, interval, time zone and start time. The example screenshot below illustrates a schedule that runs every day at 10 AM GMT:

  • 

• Manual Trigger: Finally, it’s possible only to execute a flow only when you need to. As part of this, it’s possible to specify different user input parameters to further leverage within the flow to modify its behaviour. The various types of user inputs available are illustrated in the example below:

  • 

• You can find out more about using this trigger type from the portal or via a mobile app on the Microsoft Docs website.

Actions

We’ve just discussed the component that starts your flow; actions lead on from this by dictating what your flow does. You must have at least one action in your flow that leads on from your appropriate triggers. Depending on the connector you use, actions can range from performing simple CRUD type operations to more advanced tasks, such as sending an e-mail, creating a file or laying dormant until an approval is received. In the example below, we can see we have an action that retrieves the top 10 Contacts from the system, ordered by the createdon column in descending order, whenever an Account row is updated:

Control

Although technically an action type, it is worth studying the various control actions available to us, all of which allow us to implement programming-like logic flow into our Power Automate flows:

• Condition: These are akin to your traditional if programming tests, allowing you to perform different actions based on whether the condition is met successfully or not. You can specify multiple conditions as part of this, using AND/OR logic, and also group conditions together if needed. An empty condition within Power Automate resembles the below:

  • 

• Apply to each: You will use this condition type the most when processing multiple result sets and then work on a similar principle as your traditional foreach programming loops. By specifying an appropriate collection or list of items, you can then execute one or multiple actions affecting each record. This control type can be helpful if, for example, you need to update a list of CDS Contact records in bulk whenever an Account record is updated.
• Do until: This is useful for when you need to act until a condition is true, and they work on a similar basis as a while loop. You specify the control to keep checking each time any sub-actions complete and, once the condition is met, execution will stop. Using the built-in expression language within flow in conjunction with this (more on this shortly), it is possible to construct more complex conditions to evaluate continually.
• Scope: These provide a mechanism to group multiple related actions to be collapsed/opened more easily within the visual designer. They are a purely optional component but can help in the context of “grouping” or in triggering specific success/failure action steps for a set of co-dependent action steps.
• Switch: Out of all of these, the name of this one very closely mirrors its equivalent C# programming feature. Using it, you can evaluate a specific value and then call action(s) based on this value. Finally, if it’s impossible to determine a matching value, you can instead execute a default action. Depending on your scenario, a Switch could be a far more natural solution to use compared with Conditions.
• Terminate: Finally, this action lets you immediately stop the flow, with a high degree of control over how to end it. Their nearest programming equivalent would be a throw, but the main difference here is that there are three different statuses that you can terminate a flow at:
  • Failed
  • Cancelled
  • Succeeded
• You can also (optionally) display an error code or message as part of this. They can act as a valuable means of forcing bespoke errors within a flow if, for example, a business process or control has been violated by not including a specific field as part of creating a new record.

Control actions can be a potent tool, allowing a single flow to carry out widely different actions based on the data that traverses through it.

Working with Expressions

We saw previously how canvas apps have an expression language, allowing us to programmatically trigger actions or alter how an app behaves, using an easy to use range of formulas. Power Automate works on a similar basis by having a different expression language, which is a valuable tool for performing a complex evaluation of conditions. The language derives from the Workflow Definition Language (WDL) used by Logic Apps, and it is possible to start working with expressions via a dedicated pop-up dialog window that appears:

This view will display a list of the most commonly used expressions, along with their appropriate syntax, that you can then include in your flow by clicking each one, modifying it within the expression language bar and then pressing the OK button.

For the PL-400 exam, it is impossible to discuss, learn and demonstrate every possible function that is available to us - as indicated by the online reference guide, the number of currently available functions is well into the hundreds. Instead, it’s worth focusing on a few of the more commonly used ones in each category, so you can get a feel of what is broadly possible to achieve:

• concat: One of the many possible string functions available to us, this allows you to combine two or more strings. For example, using concat(“This “, “is “, “a “test.”) would return This is a test. Other functions in this category cover everyday situations such as converting a string to upper case or returning a selection of characters from a string.
• length: This will return a number indicating the number of items/records within a collection that you specify. Note that as a collection function, this can only be used with arrays or strings that conform to a JSON structure. Within this category of functions, you can also do things such as union joins or returning the very first item in a collection.
• and: As a logical comparison function, this function will evaluate all values supplied to it and, if matching, return true; otherwise, false. The full range of logical comparison functions ranges from greater than, less than, or and even if statement evaluations, allowing us to fine-tune the conditional nature of our flows further.
• int: Allows you to convert a string into an integer value, provided it is a valid numeric value. There are conversion functions aplenty within Power Automate, which int forms a part of, and other functions of this type allow us to create a brand new array value, decode base64 strings or create a URI-encoded version of a web URL.
• min: Based on evaluating an array or list of numeric values, this function will return the lowest value detected. Power Automate has many different mathematical functions at our disposal, allowing us to perform simple additions, divisions or even generate random numbers.
• utcNow: This function returns the current date and time within UTC format. It’s one of the many date and time functions available to us. Others include functions to add a specified number of days to a date, convert a date into any given timezone or return the day portion of a date.
• variables: Returns the value of a variable you have specified within the flow, which can be useful when performing conditional evaluations. This function is one of the workflow functions, with other functions available to return the individual results of actions within a scoped action, metadata relating to the flows execution, or an action’s output. To find out more about working with variables, you can check out this handy video from Matt “The D365 Geek” Collins-Jones, where he will show you how to set a variable within a Power Automate flow.
• uriPath: For situations where you need to extract the path value of a URL (i.e. the bit after the domain portion, such as /mypage.html), this function will let you achieve this. Other URI parsing functions are available that do similar things, such as returning the host, port, or query from a URL instead.
• removeProperty: Finally, this function will remove a specified property from a JSON object, returning the updated object for you to process further if required. This function is part of the small list of JSON/XML manipulation functions, with additional functions available to add or update the properties in a JSON object instead or execute simple XPath queries on an XML document.

Experienced developers should have little difficulty grappling with the type of functionality available here, which should closely mirror what you will typically find in languages, such as C#. This factor only emphasises further the importance of considering flow early on as part of designing your solution.

Demo: Creating a Power Automate Flow

To get a feel for how to work with Power Automate flows, check out the video below:

Power Automate is a worthy topic for many blog posts and videos, and I wouldn’t worry too much about becoming an expert for the PL-400 exam. Just take time to familiarise yourself with the use cases and broad capabilities they bring to the table. In next week’s post, we’ll round up our discussion on business process automation by looking at Business Rules and Business Process Flows. These excellent tools can help you get further mileage out of your model-driven Power Apps.