cancel
Showing results for 
Search instead for 
Did you mean: 

Gaps which prevents Flow from being really useful with SharePoint

Hi,

this sort of goes to some other ideas/improvements I have logged, but thought I'd clarify it.

 

Lists with many fields

In real life SharePoint we have a lot of lists, and these lists have many fields (If you think 10+ is many). Fields with options are more often than not tied to taxonomies, and not using choice fields. Reasons for this include re-use of choices across lists/libraries and localization of choice values.

 

The issue comes when Flow tries to load up a SharePoint list as it expands all Fields in the list. If you have more than 8 taxonomy fields in a list, which is not that many for a list really, you will get the error 

The query cannot be completed because the number of lookup columns it contains exceeds the lookup column threshold enforced by the administrator.

This is perfectly fine, but if you choose not to expand all fields and only include the fields you need for the Flow, it would work just fine. Also, as taxonomy and lookup fields are not supported currently in Flow, this contradicts itself in a way 🙂 Why expand them in the first place(?)

 

I propose that the SP Get Item(s) action include an advanced option to limit which fields you want to bring back. This will also make the REST call more efficient as it loads less data. This is how we've been tought to query SPO in the first place, limit the data you need.

 

An interesting issue is that if you run a Update SP Item action, Flow reports failure on this list due to the above error, but it still updates the item. I'm guessing the action first retrieves the item, then updates it - which seems unneccessary if metadata about the list is stored in the Flow.

 

Field parity with SharePoint

We need support for taxonomy, lookup, choice and people fields. Even if Flow won't read the full taxonomy, it should support setting the main label manually at least as a work-around. Or I can pass in term/guid as a parameter to the Flow and use that.

 

Until this is in place I don't really see Flow as GA in terms of real use in SharePoint. It can work for simple cases like update alerts, but right now will often come short for enterprise production scenarios.

 

I hope a future roadmap will reflect a plan for these issues as I do like Flow and would rather use it compared to SP2013 workflows 😄

Status: New