Microsoft’s Power Automate gives a great low-code interface for creating and maintaining automation without having a strong background in development or a detailed knowledge of programming language syntax. It has a searchable interface to locate a suite of conditions and actions that, when used correctly, can be used to build a complex automation that’s almost as easy to read as a flowchart. But, as point-and-click as many of its features are, there are still some key areas that require knowledge of specific syntax and formatting requirements.
One of the first and most basic points flow authors are bound to run into this is when trying to figure out how to construct a condition statement against data in the Dataverse. Some types of data are straightforward to reference such as numbers or strings of text, but other data types require specific format knowledge in order to interact with them successfully. This blog post is intended to be a helpful reference for the latter.
Option Set Fields
Option sets are a natural fit for conditional checks in power automate since they’re built to categorize rows into distinct logical groupings. For reference, here’s how they look in Dynamics 365’s field configuration interface:
The primary components here are the “Label” (what the user sees) and the “Value” (what’s used programmatically). It’s the numerical “Value” that you need to use for this one (minus the comma formatting seen in the configuration UI). Here’s an example of a switch condition against an option set:
Two-Options (Boolean) Fields
When designing a condition, one of the most common field types to branch on is going to be a Two-Options field. However, the way these are displayed and configured in D365 makes the way you would reference these potentially not intuitive. As you can see below, a Two Options field in D365 looks a lot like an option set, only this time with exactly two choices in which only the label can be edited:
You might expect that we’d use the Value again here like last time, but that will actually fail here. Interestingly however, using the Label will also fail. What you actually need to use is “true” (for 1) or “false” (for 0). That’s because behind the scenes, this is actually being stored in what’s known as a “Boolean” data type. (A topic for another day, but this is one of many reasons I would recommend only using the Two Options field type to store actual true/false or yes/no data.) Here’s a working sample in practice:
Date Fields
The most common use case for these are easy to intuit the proper setup for, but there are a few scenarios that will require some formatting knowledge. If you want to compare two date fields against each other, there’s no mystery here. Say you want to check whether a record has ever been modified after creation- your flow would look something like this:
However, if you need to compare a date field against a static date, that’s when you’re going to need to think about how to format a date. Fortunately, from my testing, the system seems to have some pretty generous logic in place to try and deduce what you’re trying to express. In an extreme example, I entered “2021/29” as a date and it still ran with it. But, to avoid logical and regional guesswork for the system, I would suggest using a format here of (“yyyy/MM/dd”). Here’s a working example:
Conclusion
If you’re new to Power Automate, I hope this post saves you some trial and error in figuring these out. And, if you’re a veteran with Power Automate, I hope this saves you from having to open old flows as a reminder ? Feel free to bookmark it as a handy reference!
If you are interested to learn more about this topic, please feel free to Contact Us.