TL;DR - The “contains” operator when creating filters in a rule behaves differently across the Rule Setup section and the Rule Action section in a rule build. “contains” is case sensitive in Rule Action where it isn’t in Rule Setup. Please upvote to change this logic and make it consistent across rules.
Hi All,
Our company is using Gainsight for multiple departments, including our implementation org. As any company, we have multiple Customer Success Tiers to cater to, and our rule automations are based off associating a specific success plan template to a specific success plan shell based on our product sold and customer success tier they fall into.
Our Enterprise segments are broken down into “Large ENT” and “Enterprise”. When our rules were build for the Setup Action for each of our Enterprise Products, we used the operator of “Contains” to catch all enterprise accounts by simply doing “Customer Success Tier (contains) “ENT””
What ensued over the last month and a half since we launched this was sporadic implementations being missed with no failures as to why.
I lodged a support ticket (Ticket # 203093 Automated Success Plans missing creation with no Rule Failure) where support confirmed that the contains operator in the Rule Action of a rule is Case Sensitive. That is not the case in the Rule Setup section of a rule.
The inconsistency in this logic lead to us now updating our rules with 2 filters to catch Enterprise accounts. However the logic inconsistency between two sections in a rule build is not ideal and not easy to catch without some out of the box trial and error that the average admin does not have time for, and is not documented to see.
Can we please create consistent operators within a rule? (I haven’t done an impact assessment for the other operators, so there could be more. 
)
Thanks so much!
When Roxanne brought this up, I refused to believe there would be such drastic inconsistencies within the same module of Gainsight. It truly gave me heartburn. There must be something that should be done about this.@ophirsw ?
I’ve done this for 7+ years, and “today I learned” of this product behavior. Consistency here (1) would be more intuitive and (2) would have saved what looks like a lot of troubleshooting time for both@RoxConroy and Gainsight Support. I’d put this on any Admin “Quality of Life” list that’s forming, and I’m upvoting in 3...2...1.
Also going to note that my org is on Gainsight NXT. Not sure about the behaviors in other versions of Gainsight.
At the very least, this is the type of thing that needs to be documented and proactively communicated to admins in the meantime.
Currently still the case in Horizon Rules FYI
This one bit us yesterday. Spent an hour trying to figure out the issue. We were running a report with the exact same filters and comparing to the preview and execution of the rules. Report returned data and rule didn’t. Then matched the case in the horizon rule and it worked.