"Disjunctions not supported" - Why Custom Metadata and Flow Don't Mix
Salesforce has been focusing a lot on Flow recently, as they should. It splits the difference nicely between Process Builder and Apex code.
We recently used Flow to implement what I'd expect is a common use case - when a record is created, lookup a value from a table and update the record. In this case, it's a light lead score we call a "fireball" value.
This worked great since in most use cases we'd get one record at a time. But we found during Lead conversion, we would get a few records through at a time, which caused the process to break with a really odd error:
Error Occurred: This error occurred when the flow tried to look up records: Disjunctions not supported.
After some research it became clear that this is the error you get when you try to query a custom metadata table using an "OR" condition. But my Flow didn't use an "OR" condition in the metadata lookup.
The answer was lurking in this obscure documentation:
When you define multiple filters, the filter logic usually defaults to AND. However, if multiple filters have the same field selected and use the equals operator, the filters are combined with OR.
In other words, when multiple records go through the Flow in a transaction, the system will combine your queries into a single query behind the scenes, and when it does that, it likes to use "OR".
When this happens, you have a few options.
- Use a non-metadata type to store your data - a regular custom object, in other words. But this has a lot of drawbacks such as security and portability.
- Code it.
In my case, I chose to code it using a re-usable generic service. To get the code and see how to use it, check out my follow-up post.
Hey, great blog post! I wanted to just add on to this, that with the spring 22 release, we've gotten access to the new Collection Filter element which may prove useful here.
ReplyDeleteI encountered a similar error, and was able to solve the issue by getting more metadata than I actually need in my initial lookup, then using a collection filter to whittle it down to the collection I actually needed. Something to note is that you will have to specify which fields to store in the initial get, as the "automatically select fields" option will not work as before.
I then had to use an extra assignment element to assign the output of the filter collection to a record collection variable, as the loop did not like the collection filter's output variable for some reason.
Hope this helps someone else scrounging the internet for answers :)
Thank you, I have not tried this but @der_peter_ on Twitter let me know that this does indeed work. Thanks for the follow-up, always good to have a no-code solution.
Delete