I'm having an issue with delegation and, after having read all of the documentation, I have yet to see a description of the exact issue that I'm seeing. I know that the PowerApps filter function can be delegated to SharePoint for SharePoint lookup columns, but it seems that this functionality is limited to when you use the ColumnName.Value and not the ColumnName.Id. Let me describe a simple example.
There are two lists, Projects and Project Statuses. The Project Statuses list has a lookup column named Project, and it looks up to the Title column of the Projects list.
Projects list
Project Statuses list
In this example, I want to have PowerApp that filters the Project Statuses based on the selection from the Projects list, thus using a gallery Filter to show the items from Project Statuses.
As described above, I have no problems if I do a filter like this using the Value attribute of the lookup column:
Filter('Project Statuses', Project.Value = "Project MNO")
Filter by Project.Value; no delegation warning
However, if I want to use the Project.Id this would then throw a delegation error. In the simple example that I'm using this is less of an issue if I just use the SharePoint settings to require a unique value for the title field, but this would not be a viable option if I had a list that couldn't enforce unique values on the column used in the lookup column. Here's the delegation error when I change to Project.Id:
Filter('Project Statuses', Project.Id = 5)
Delegation warning with Project.Id
For the purposes of the solution that I'm managing, the 2000 item limit will probably be met fairly quickly, and requiring unique values on the source list column is not an option. Does anyone have any ideas on how to work around this limit, or suggestions on what could be done differently?
Solved! Go to Solution.
I wasted a day on this and I'm sure you did too. Yes, it only works on the Value, and not the sharepoint ID. but this is not what the documentation says, at least that was my understanding that I could use ID.
What you could do, when you create the lookup in SharePoint, set the value of the lookup field to ID, and then use the additional lookup fields to add the other columns like Name and descriptions into your list
I wasted a day on this and I'm sure you did too. Yes, it only works on the Value, and not the sharepoint ID. but this is not what the documentation says, at least that was my understanding that I could use ID.
What you could do, when you create the lookup in SharePoint, set the value of the lookup field to ID, and then use the additional lookup fields to add the other columns like Name and descriptions into your list
Thank you very much for your response @Edwin-Abdalian! I did spend quite a long time researching options, but hadn't considered switching the ID on the SharePoint side. Do you know if making this change after the initial column creation would change the way that the column is referenced in PowerApps, or does this now make it possible to call ColumnName.Id without the delegation error?
Edit - I just looked at your screenshot again saw that you're saying it should be Columname.Value. Going to test now!
yes, please try it in you Dev environment. After applying these changes, your "Project" column in the Status list, will contain the ID of the projects, but now as a value, which you can use it in PowerApps without getting the delegation warning.
and as I explained in the picture, to display the project name in your list, you need to add the "Project Name" column to your lookup. you will have a new column called "Project:Project Name" in your list.
Yep, looks like it works! No more warning, though I did have to wrap the selected ID from the parent list in a Text() function so that it compared the values as strings. The below screenshots are different data from when I initially made the demo, but no more delegation warning. Thanks again!
Are we certain that this actually works even though the delegation warning is not there? I was recently made aware that the delegation warning is unreliable. Some functions like AddColumns() are not producing the delegation warning like it is supposed to, and the documentation about it is somewhat fuzzy saying "AddColumns, DropColumns, RenameColumns, and ShowColumns partially support delegation." ("partially" being the key word for confusion)
Could it be the the case in this instance?
Delegation warning unreliability is discussed here
yes, it works fine with this method. I have tested and used it in my apps.
Edwin
Thank you so much @Edwin-Abdalian, worked for me too! Something I noticed is that the delegation seems to only work on the value of the first column. The subsequent columns still give me an delegation warning. It was a gotcha that got me.
I have so many formulas with delegation warnings caused by this. The workaround will cause a massive rewrite in addition to changing the SP lookup columns. Please vote for this in the ideas section:
Hi I have a similar issue with my lookup column pointing to a fairly small lookup list. The main list has over 1000 items.
I have tried different compinations of the above look up column settings but I simply don't get passed this annoying warning:
Is it the case the lookup columns can give false delegation warnings.
Update: having the text box was proving a bit timewaster : no matter how I configured the lookup list settings ( I still got the delegation warning
Update: I never got the text book to work, no matter how I configued the look up list in in my client's tenant, so I settled for an alternative:
If(!IsBlank(cmbManagers.Selected.'Manager Name') ,
Filter('Approvals', ManagerName.Value = Managers.Selected.'Manager Name' And ApprovalStatus.Value
= drpApprovalStatus.Selected.Name))
The ApprovalStatus dropdown allows further refinement to the query: "Awaiting Approval", "Approved" etc
User | Count |
---|---|
120 | |
86 | |
83 | |
74 | |
69 |
User | Count |
---|---|
215 | |
179 | |
140 | |
108 | |
83 |