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

Table of Contents

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.

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.

Next Comparing collections, table variables and data sources in Power Apps »

Previous « Set the task priority in Microsoft Planner using Power Automate

View Comments

Rob Hall says:

January 13, 2022 at 1:08 pm

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?
- Pieter Veenstra says:
  
  January 13, 2022 at 1:11 pm
  
  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.
Ramesh Mukka says:

January 13, 2022 at 3:13 pm

Why not ThisRecord.Colour?
- Pieter Veenstra says:
  
  January 19, 2022 at 3:40 pm
  
  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.
Warren Belz says:

January 20, 2022 at 12:16 am

Hi Pieter,

You can also do this

ClearCollect(
colSuggestFruitByColour,
ForAll(
colCars As aCars,
LookUp(
colFruit,
Colour = aCars.Colour
)
)
)
)
- Pieter Veenstra says:
  
  January 20, 2022 at 9:04 am
  
  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.
Egbert Roelofsen says:

January 21, 2022 at 11:05 pm

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.
- Pieter Veenstra says:
  
  January 21, 2022 at 11:20 pm
  
  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.