According to this article: https://docs.microsoft.com/en-us/connectors/sharepointonline/ the calculated column should count as a text column and text columns are able to delegate. Still, I get delegation warnings when trying to filter on a calculated text field.
Any suggestions?
Solved! Go to Solution.
@WarrenBelz is correct, calculated columns are not delegatable. I've had a similar experience trying to use them.
The docs on this are a little fuzzy. Yes, they say Calculated columns are treated as 'Text' but that is only inside the app. This is why it says this in the 'mapping' table of the docs. When you try to delegate PA functions to calculated columns they are no longer treated as text, but as calculated columns, if that makes sense?
In a database sense, you are best trying to avoid them where possible. I'll add another tip, if I may, try to avoid Yes/No columns as well. If you need a Yes/No column, use a Choice column and only use Yes/No as options.
@aldenniklas , no need for Flow, @WarrenBelz 's response is all you need.
I've started using extra date columns in my SP lists which are double ups for any date format columns I may have, using the principals that @WarrenBelz set out.
The only difference is that is use the format yyyymmdd. As per @WarrenBelz response, I set this as a number column. Numbers are delegatable which means you can use '<', '>', etc on these columns, essentially filtering dates how you want.
Only '=' is delegatable in Date columns so this makes date ranges much more accessible.
I also include these columns in any Patch, Collect, etc back to SP. For example, this is the formula I use for one of these fields (usually hidden) when making reference to a DatePicker in Form:
Value(Text(DatePicker1.SelectedDate, "yyyymmdd"))
Note: to retrofit these columns in my SP lists I did use Flow but that was only to set them up, not use on a continual basis
I also think @WarrenBelz solution is worth a tick, you can tick more than one response as the solution 🙂
Hi @aldenniklas ,
My experience with SharePoint calculated columns is that they are not delegable, however as the calculation is generally available with connected PowerApps data sources, you should be generally be able to do the same filter in PowerApps.
Also here is a post I did earlier this week on the same issue.
Please click Accept as solution if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider giving it Thumbs Up.
Can you show us what your filter statement looks like? It might not be that the column is calculated that is causing the issue. Also, when you created the calculated column was it created to hold a value of text. you can choose what kind of data type the calcuated column will hold. Text is the default, but its not the only option. The screenshot below shows the options available when creating the calculated column.
@WarrenBelz is correct, calculated columns are not delegatable. I've had a similar experience trying to use them.
The docs on this are a little fuzzy. Yes, they say Calculated columns are treated as 'Text' but that is only inside the app. This is why it says this in the 'mapping' table of the docs. When you try to delegate PA functions to calculated columns they are no longer treated as text, but as calculated columns, if that makes sense?
In a database sense, you are best trying to avoid them where possible. I'll add another tip, if I may, try to avoid Yes/No columns as well. If you need a Yes/No column, use a Choice column and only use Yes/No as options.
Ok @aldenniklas ,
Glad to hear you have fixed it.
Another thought with dates is that a numeric column based on yymmdd either on a hidden card reset, defaulted and submitted or Patched can be set whenever a date is entered or changed in a date picker. This gets around all date delegation issues.
@aldenniklas , no need for Flow, @WarrenBelz 's response is all you need.
I've started using extra date columns in my SP lists which are double ups for any date format columns I may have, using the principals that @WarrenBelz set out.
The only difference is that is use the format yyyymmdd. As per @WarrenBelz response, I set this as a number column. Numbers are delegatable which means you can use '<', '>', etc on these columns, essentially filtering dates how you want.
Only '=' is delegatable in Date columns so this makes date ranges much more accessible.
I also include these columns in any Patch, Collect, etc back to SP. For example, this is the formula I use for one of these fields (usually hidden) when making reference to a DatePicker in Form:
Value(Text(DatePicker1.SelectedDate, "yyyymmdd"))
Note: to retrofit these columns in my SP lists I did use Flow but that was only to set them up, not use on a continual basis
I also think @WarrenBelz solution is worth a tick, you can tick more than one response as the solution 🙂
User | Count |
---|---|
230 | |
101 | |
98 | |
56 | |
33 |
User | Count |
---|---|
282 | |
111 | |
109 | |
64 | |
62 |