Microsoft Power Apps

Ambiguity in Power Apps

Recently I was asked about issues related to ambiguity in Power Apps code. In this post I will look at how to avoid any ambiguity issues in Power Apps.

Ambiguity

First of all what is ambiguity? According to the dictionary, it is all about things not being clear as multiple explanations can be given to the same thing.

Ok, that’s all great! But what does that have to do with Power Apps.

Power Apps and Ambiguity

I’m going to start by creating two collections. Using the following code I’m going to create a collection called colFruit:

ClearCollect(
    colFruit,
    {
        Type: "Apple",
        Colour: Green
    },
    {
        Type: "Apple",
        Colour: Red
    },
    {
        Type: "Plum",
        Colour: Red
    },
    {
        Type: "Plum",
        Colour: Yellow
    },
    {
        Type: "Banana",
        Colour: Yellow
    }
);

And for my second collection I’m going to created a collection of cars

ClearCollect(
    colCars,
    {
        Type: "Nissan",
        Colour: Red
    },
    {
        Type: "Volkswagen",
        Colour: Yellow
    },
    {
        Type: "Ford",
        Colour: Green
    }
);

Now using the colour of the cars, I want to suggest the fruits that share the same colour as the car.

Using the Ambiguity operator

A first attempt might give you code like this:

But the above code of course will not work.

Colour is the same as Colour as I’m not specifying where the Colours are coming from ( either the colFruit or colCars collections ) the expression doesn’t make much sense.

We can now let the expression make sense by changing the code a bit.

ClearCollect(
    colSuggestFruitByColour,
    ForAll (
        colCars,                    
            First(Filter(
                colFruit,
                Colour = colCars[@Colour] 
            ))
        )
    );

Using the above code, I can specify, the colCars collection used in the ForAll using the following syntax

Collection[@Property]

Using the above construction we can specify which of the datasources we want to use within the nested lines of code.

Share
Pieter Veenstra

Business Applications and Office Apps & Services Microsoft MVP working as a Microsoft Productivity Principal Consultant at HybrIT Services. You can contact me using contact@veenstra.me.uk.

View Comments

  • That's really useful, I've always used rename columns in instances like this to rename one of the Colour column and had no idea about this. I've never really fully understood the use of the @ in PowerApps. Although I've seen posts in forums with answers that say use [@] I've never understood why and it's use is never covered in any online tutorials. This is the first time I've actually seen a use case for it, similarly for Power Automate, lots of examples of using it but never accompanied by an explanation of why or what it actually does. Does it have any other uses other than this kind of ambiguity?

    • Hi Rob,

      It can in general be used when you want to be specific about what you want to select. Typically that happens in ForAll loops where you want to do something inside the forall loop.

    • ThisRecord will refer to the datasource in the most inner function. So if you want to reference the other datasource then ThisRecord would not do the job.

  • Hi Pieter,

    You can also do this

    ClearCollect(
    colSuggestFruitByColour,
    ForAll(
    colCars As aCars,
    LookUp(
    colFruit,
    Colour = aCars.Colour
    )
    )
    )
    )

    • Hi Warren, that is indeed an alternative. This especially a great option when you use the same datasource/collection twice within the same set of nested functions.

  • The disambiguation operator is pretty handy, but we also have the ThisRecord and As operators – https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/functions/operators#thisitem-thisrecord-and-as-operators.
    I highly prefer them over the [@…] notation, as it results in more readable code.

    Are there in your opinion situations where the disambiguation operator is the only solution or the better solution? As I cannot easily think of a scenario.

    • The as operator I can see as a good option quite often although I prefer to keep the original names of the collections/datasources. Using multiple names for the same thing can be confusing.

      Also in general the @ signs do take the attention of the reader. This tells me often, watch out there is something complicated here.

Recent Posts

3 steps to implementing a better date picker in Power Apps

One of the biggest annoyances of Canvas Apps in Power apps is the date picker.…

3 days ago

Power Automate Flow run failed: Connection not configured for this service

Today I was battling with the Connection not configured for this service error. Background Iv'e…

3 weeks ago

Open Word documents in the desktop app from Power Apps

When you open Word documents from Power Apps you might have noticed that Word Online…

2 months ago

Introducing Portal Apps in Power Apps

Power Apps has three types of apps. One of them is the Portal app. In…

2 months ago

NEVER give your SharePoint fields the displayname of Value!

After an hour of banging my head against a brick wall when my Patch command…

2 months ago

Collect flow runs of your failed child flows

When you use child flows, you might need to collect the flow runs of your…

2 months ago