I mentioned this in a comment in a separate post a few months ago, but thought it worth calling out again here.
In Bionic Rules, you can filter on specific IDs throughout a rule, including in Case statements like the below:
(The redacted parts are SFDCIDs)
In Horizon Rules, that is no longer possible as any ID field just becomes a lookup. It looks like this:
Note that not only is it a lookup, but if you want to add another field or see your full result you’d need to scroll over, but I digress>
The issue with the lookup, is if you need to key in a specific ID. In my case, I need to intercept data from an SFDC account and change the SFDC AccountID before my actions. Now, I need to use the contains operator (haven’t tested if that works) or filter for one of the many possible account options (there are duplicates, hence the issue) and test until I’m confident I’ve got the right one selected.
I’m guessing that this behavior isn’t going to fundamentally change, but my ask here is can we find some ways to make the functionality more similar? We’re likely not the only ones using these filters in rules or expecting Horizon Rules to be at least as capable as Bionic Rules.
Some ideas that would help (if not outright having the same functionality):
- Allow an ID to at least be input into the search to retrieve the named record
- As part of the search result, display the ID so you know it’s the one you want
- In areas like this where there is a lack of functional parity between the two options, have it well documented. Not just the exciting “new workflow” and “Snowflake as a Data Source” headliners, but actual “Here’s how you used to do X in Bionic Rules, here’s the workaround in Horizon Rules”.
Thanks!
This is a real problem. I’ve also encountered it when trying to load a static string to an ID field as a Custom Field mapping - it won’t let you handkey a value in.
Agree this is a need. We also have a lot of similarly named accounts so it makes finding the correct one a lot more challenging if I can’t use the ID.
Jumping on the bandwagon. The ability to key in an ID into all parts of the Rules Engine, achieving parity with Bionic rules, is essential.
In rule building and testing, it’s extremely common to filter into a specific record ID, and the simplest way to accomplish that is keying in an ID. Without this capability, there’s a substantial negative impact to rule building and testing.
Just as an update, I have done some limited validation with just using “contains” and it does seem to work, though the original point still stands and I’m curious to know how rule migrations work, as the previous experience I’ve had with this just breaks the rule.
Thank you all for your feedbacks, I will pass it on to my team for evaluating the most suitable solution for this use case.
Agreed.. We do have few rules setup using the ID fields and its important for us to have the same functionality in the Horizon rules.
Adding another hangnail related to this I found: you can apply an operator for “starts with” to a filter on an ID field to avoid the lookup, but when you attempt to run the rule (or generate a preview) the task will fail with an “invalid operator” error.
Just as an update, I have done some limited validation with just using “contains” and it does seem to work, though the original point still stands and I’m curious to know how rule migrations work, as the previous experience I’ve had with this just breaks the rule.
True, “contains” works. But I’ve noticed that in some cases “contains” isn’t even available for ID filters at all. I haven’t found the rhyme or reason yet. Either way, it’s a frustrating experience for sure.