by The “workflow function” is one of Power Automate’s most useful functions, especially when you need to reference information about your current Flow. While not immediately apparent, this function provides information about the run that can be super useful; for example, you can send an email with the run details in case of a failure. You can check the “Try, Catch, Finally” article with a strategy and a template to help you.
A quick note before we begin. This article will have a lot of blurred screenshots. The information is related to my tenant, and although sharing the ID information wouldn’t be a problem, one can never be too careful. The functions are there, and you can run them in your environment quickly and check their results. It’s not ideal, but blame the people doing crappy stuff over the internet 🙂
Let’s explore how to use it effectively and some recommendations.
Where to find it?
You can find the function in every action where a formula is supported. For example, let’s look at a “Compose” action:
As you can see, we can auto-complete by using the “tab” key (old UI) or “enter” key (new UI). Let’s look at how to use it.
Usage
The “workflow function” follows a simple pattern with no parameters required:
workflow()
This function returns an object with all the information about your current Flow.
There’s a lot of data returned so let’s break it into pieces:
Global Metadata
The global information of the Flow itself. It doesn’t change between runs.
- id: The unique identifier (resource path) of the workflow.
- name: The internal unique identifier of the workflow instance.
- type: Specifies the resource type (Microsoft.Logic/workflows).
- location: The Azure region where the workflow is deployed (e.g., westeurope).
Tags
The tags associated with the Flow. They complete the information above with some more information about the Flow. This also doesn’t change between runs.
- flowDisplayName: The human-friendly name of the workflow.
- environmentName: The environment where the workflow is deployed.
- logicAppName: The internal unique name of the workflow in Logic Apps.
- environmentWorkflowId: Encoded ID linking the workflow to its environment.
- xrmWorkflowId: Unique identifier of the workflow in the Common Data Service (Dataverse).
- environmentFlowSuspensionReason: Status or reason for suspension (if applicable).
- sharingType: The type of sharing method used (e.g., CommonDataService).
- state: Current state of the workflow (Enabled).
- createdTime: Timestamp when the workflow was created.
- lastModifiedTime: Timestamp of the last modification.
- createdBy: Unique identifier of the user who created the workflow.
- triggerType: The type of trigger for the workflow (Instant, meaning manually triggered).
Run Specific information
- run.id: The specific workflow run’s unique identifier (resource path).
- run.name: The unique name of the workflow run instance.
- run.type: Specifies that this is a workflow run (Microsoft.Logic/workflows/runs).
Let’s explore some of the most common use cases for this function.
Get the Flow name
One of the most common uses is to get the name of your Flow. This is especially useful when you’re sending notifications or logging information:
workflow()['name']
Let’s create a sample Flow with a “Compose” action to demonstrate this:
Here’s the result:
Get the Run ID
Each time your Flow runs, Power Automate assigns a unique identifier. This can be extremely useful for tracking and debugging:
workflow()['run']['name']
Here’s the “Compose” action to show this.
Here’s the result:
Get the Flow URL
Another helpful piece of information is constructing the URL to your Flow. This can be helpful when sending notifications that include a link back to the Flow. Unfortunately, no formatted URL has been built, so we need to do some concatenation magic using the “concat” and “split” functions.
concat('https://make.powerautomate.com/environments/', workflow()['tags']['environmentName'], '/solutions/', split(workflow()['tags']['environmentWorkflowId'], '-')[1], '/flows/', workflow()['tags']['xrmWorkflowId'])
Here’s an example:
And the result:
Get the Flow Run URL
There’s another URL we can generate if needed (see examples in the next section). We can generate the Flow Run URL using a strategy similar to the one used before.
concat('https://make.powerautomate.com/environments/',
workflow()['tags']['environmentName'],
'/flows/',
workflow()['tags']['xrmWorkflowId'],
'/runs/',
workflow()['run']['name'])
You’ll get a URL to copy-paste and quickly see a specific run’s result.
Practical Examples
Here are a few pre-defined example of things that you can do:
Creating a standardized error message
When your Flow encounters an error, you can use the “workflow function” to create a standardized error message that includes information about the Flow and the current run:
{
"flowName": @{workflow()['name']},
"runId": @{workflow()['run']['name']},
"errorTime": @{utcNow()},
"error details": @{concat('https://make.powerautomate.com/environments/',
workflow()['tags']['environmentName'],
'/flows/',
workflow()['tags']['xrmWorkflowId'],
'/runs/',
workflow()['run']['name'])},
"errorMessage": "Failed"
}
We’ve used a combination of some of the examples before. I like this example because it’s something that we can quickly put in an email and would provide much information to the person developing and managing the flows. So, for example, if a Flow fails, we have a link to the Flow that failed and can check what went wrong. Imagine that your Flow runs hundreds of times per day; having a link to the failed one would save you much time.
Change things depending on the environment
Since we know the environment information, you can have different branches of your Flow depending on the environment. For example:
equals(workflow()?['tags']['environmentName'], 'Production')
This way, you can deploy your Flow in different environments without changing it. I don’t recommend using this all the time. However, I could be interested, for example, in cases where you’re developing on top of fake data but when deploying to production using the final data.
Non-intuitive behaviors
Here are some non-intuitive things to remember when using the “workflow function”.
Case sensitivity with properties
The properties returned by the “workflow function” are case-sensitive. Make sure you’re using the correct case when accessing properties:
workflow()['Name'] // This will return null
workflow()['name'] // This will return the Flow name
Environment information
The “workflow function” doesn’t directly provide information about the environment where your Flow is running. You need to extract it from the ID:
split(workflow()['id'], '/')[2] // This will give you the environment ID
Flow URL limitations
The Flow URL construction shown earlier works for most scenarios but might not work for all types of environments, especially custom domains. Always test your URL to ensure it’s correct.
Limitations
There are a few things to be aware of when using the “workflow function”.
No trigger information
It does not include trigger details like inputs or outputs. You cannot use it to access dynamic run-time data beyond the metadata, so you will always need to access the Flow’s run (check the example above) to check that information.
Performance considerations
If used excessively within a workflow, it might cause unnecessary processing overhead. Large workflows with multiple instances running simultaneously may have inconsistent results if workflow states change rapidly.
It counts thoards your limits
To use it, you need an action, so if you have tight limits on the number of actions, use this as sporadic as possible while providing value.
Common Mistakes
Here are some common mistakes people make when using the “workflow function”:
Using dot notation instead of square brackets
A common mistake is trying to use dot notation to access properties:
workflow().name // This will not work
workflow()['name'] // This is the correct way
Not handling null values
Some properties might be null depending on your Flow configuration. Always handle potential null values to avoid errors. You can use the “coalesce” function like this:
coalesce(workflow()['tags'], 'No tags')
Accessing nested properties incorrectly
When accessing nested properties, make sure to use the correct hierarchy:
workflow()['run']['name'] // Correct
workflow()['run.name'] // Incorrect
If you do it you’ll get an error like this:
Unable to process template language expressions in action 'Compose_1' inputs at line '0' and column '0': 'The template language expression ' workflow()['run.name']' cannot be evaluated because property 'run.name' doesn't exist, available properties are 'id, name, type, location, tags, run'. Please see https://aka.ms/logicexpressions for usage details.'.
Recommendations:
Here are some things to keep in mind when using the “workflow function”.
Use “debug” compose actions
Since the “workflow function” returns an object with multiple properties, it’s useful to use a “Compose” action to see the full structure. This way, you can understand what properties are available and their values.
Cache values in variables
If you’re going to use the same “workflow function” property multiple times in your Flow, consider caching it in a variable to improve readability and performance.
Always add a comment
Adding a comment will help avoid mistakes. Indicate why you are using the “workflow function” and what information you’re trying to extract. It may look obvious initially, but it will not be in a few months or years. It’s essential to enable faster debugging when something goes wrong.
Sources:
Microsoft’s workflow Function Reference
Back to the Power Automate Function Reference.
Photo by Will Porada on Unsplash
