The first question that comes to mind is a "GUID". I wrote about it a while ago for Power Apps, but today I want to focus on Power Automate's "guid" function. A GUID stands for "Global Unique IDentifier," and it's what it says on the tin. It provides a way to have a long sequence of characters representing something unique.

So let's explore how to use the "guid" function in Power Automate.

The structure

I don't want to bore you with math and complex concepts, but it's essential to understand the guid's structure before continuing.

The standard structure for a guid is "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", but you can find as well the un-hyphenated version like "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" and it's always a sequence of 32 hexadecimal characters.

When we think about numbers, we always think about characters (0,1,2,3,4,5,6,7,8,9) or base 10. It's so ingrained in our minds that we don't even believe that there may be other ways to represent groups of things.

We start counting from 1, and when we go over 9, we go back to 1 and add another digit to the left. The same applies here, but we're using hexadecimal or base 16. It means that the representation of numbers has extra characters to go over 9, so (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F). So if we have 11 things, we represent it with 11 in base 10, but since we don't have to "go back" in base 16, we can represent 11 with "B".

It's the same if you think about it, but you can represent larger values with fewer characters. So, for example, 100 in base 10 is 64 in base 16.

There are a lot of videos explaining this in detail, but I wanted to give you a temporary structure on how it works.

Under the hood, Power Automate produces a version 4 GUID per RFC 4122 using pseudo-random numbers. The chances of generating the same one twice are so small they're effectively zero, which is why GUIDs are safe to use as unique identifiers.

Usage

The guid function will generate a random GUID each time you run the function. Therefore, it's essential to store the value somewhere, like a variable or a compose action, so that you use it in the future.

Common uses include creating unique filenames before uploading to SharePoint, generating dedup keys before inserting records, and creating correlation IDs to trace activity across related flow runs.

Let's start with a simple example by executing the function without parameters.

guid()

will return

592c31c0-5949-4af3-af80-840b417660c6

If you want to get the number without hyphens, you can use the "N" parameter.

guid('N')

will return

631e4aedc77749c49543884cccb3c113

Notice the quotes in the parameter. Without them, your function will return an invalid expression error.

Now let's look at another parameter:

guid('B')

will return

{de759c8d-4fc6-40ef-8c04-cdd6639bc013}

If you want to memorize it, you can associate the parameter with brackets.

How about if you want without the left and right curly braces? You can use the 'D' modifier, like this.

guid('D')

will return

df068212-804d-40cb-9241-5adcc8760af6

We already know what we'll get if you add a "P" as a parameter.

guid('P')

will return

(df068212-804d-40cb-9241-5adcc8760af6)

We have another value that is a bit stranger. Let's use the "X" and then understand what it returns:

guid('X')

Will return:

{0xe0929346,0x59b8,0x447d,{0xb6,0x26,0xfc,0x68,0xb7,0x10,0xa7,0x89}}

Super strange, right? I can bet good money that you would not need this parameter, but let's look at it anyway.

First, let's look at the "0x" part. A historical reason for this is quite technical and not important now, but by adding "0x" you know you're representing a hexadecimal number. Also, it removes ambiguity because if you represent "0x14" it's not the same as 14 in decimal. The example above contains three numbers and a subset of 8 digits.

So why does this format even exist? It's a leftover from old-school Windows programming. When developers write code for Windows in languages like C or C++, they sometimes need to paste a GUID straight into the source file, and that paste needs to be in this exact shape so the computer can read it. Power Automate inherits the format from the engine underneath, which is why we get it too. You'll almost certainly never need it from a flow, but now you know what it's for.

Edge Cases

Each call returns a new value

Every time you call "guid" in an expression, you get a fresh GUID. If you reference "guid" in two different actions without storing it first, you'll end up with two different values. So if you need the same value in multiple places, generate it once in a compose action or a variable and reference that everywhere.

The output is always lowercase

The "guid" function always returns the hex characters in lowercase. If you need uppercase (some downstream systems are picky), wrap the result in the "toUpper" function:

toUpper(guid())

Limitations

Depending on the size of your string, your expression may return an error, even if it's correct. So as you know, the expressions have a max size of 8,192 characters. If you have an expression even bigger than 1000, I recommend breaking it into smaller, manageable formulas.

Another limitation is that the parameters need to be in uppercase; otherwise, you'll get the following error:

Unable to process template language expressions in action 'Compose_N_lowercase' inputs at line '0' and column '0': 'The template language function 'guid' format parameter 'n' is not supported. The supported formats are: 'N, D, B, P, X'. Please see https://aka.ms/logicexpressions#guid for usage details.'.

Some people would like the guid to be used to format a string. For example, this enhancement request asks for the guid to have a parameter that accepts a string and the format and then formats it. Although programming languages support that, I would not like it to happen. Functions should have a single responsibility; in this case, it is to generate GUIDs. Having an extra parameter to format it is already a plus. Having it format the string would require the team to add GUID validation to understand if it's a valid GUID or not. If Microsoft decides to implement this, it would always be better to create another function. I would be more than happy to write another article covering it 😀.

Recommendations

Here are some things to keep in mind.

Use "debug" to compose actions

Since the comparison will return true or false, sometimes it's tricky to understand how the calculation is done, depending on how complex the expression is. So I recommend using Compose actions to have the values that go "in" the function. This way, if the value doesn't make sense, you can understand, based on the parameters, why it was calculated that way.

Don't nest

There's no real reason to do it, but you may find yourself tempted to nest "guid" functions in a formula. If you try to nest it, you'll get an error, so be careful with what parameters you pass to the function.

Don't use variables to provide parameters

Always define the parameters (the "X", "B", "N", etc.) manually in the function. Of course, you can have a compose action or a variable with the value, but that would make the function more opaque to the people who read it. For example:

guid('X')

It's much easier to analyze than:

guid(guid(outputs('parameter_with_the_type_of_output')))

Although it's clear that the compose action has the parameter's value, it's not clear that the parameter is correct. Having a Flow failing is bad enough, and if it's because we made a mistake in the parameter is even worse. Once we generate the ID, we should know why we want it and how to format it.

Final Thoughts

The "guid" function is small but mighty. Once you know which parameter to use for which format, generating unique identifiers for your flows becomes a non-issue. Pair it with a compose action and you have a reliable way to keep IDs handy whenever you need them.

Sources

Microsoft's guid Function Reference

Back to the Power Automate Function Reference.

Photo by Cristina Gottardi on Unsplash