Implemented

Rules Engine: Do not trigger CTA if it has already been triggered in the last X days.


Userlevel 7
Badge +2
This has sort of been posted before, but as a question:  https://community.gainsight.com/gainsight/topics/prevent-new-cta-creation-when-one-has-already-been-...

This is a valid concern though.  I should be able to, within a Create CTA action, specify NOT to trigger the CTA if the same CTA has already triggered previously within X days - similar to how we have the ability within Co-Pilot to say "send email once in X days" where X is 30, 60, 90, etc.

For example, if my customer's healthscore has dropped, and I create a play for the CSM to engage in some way, it won't directly cause the customers healthscore to increase automatically (sidenote:  our healthscore is calculated by a state-of-the-art machine learning model that was trained on hundreds of variables collected from historical data.)  So once the CSM closes the CTA, if the same circumstantial criteria exists, it will re-trigger that CTA.

Saying "snooze the CTA to a later date" isn't a good solution either, because we still want that action to be carried out.  Because CSM actions are not one of the healthscore variables, the model cannot say whether or not a specific action will improve the health of an account. One of the goals of the CSM program is to standardize CSM actions so that, in the future, Red Hat can know the impact of different actions on an account’s probability of renewal. 

10 replies

Userlevel 7
Badge +4
Hi Jeff,

So I did this by adding a field to customer info that populates the last date an alert for that reason was completed, and then, added a filter to the rule to not generate another one if that date is x days from the rule date. Seems to have worked okay on our end. I know it's not ideal, but that was my workaround.
Userlevel 7
Badge +2
Thanks Heather good suggestion.  Though I do grow weary of having to create custom fields as workarounds.  
Userlevel 6
If you were to choose the unique identifier to not create a duplicate, what would be that? Account ID + Rule ID would be good enough in this case?

This is part of the roadmap, will keep you posted on the ETA.
Userlevel 7
Badge +2
Sorry Sundar, I am not getting emails from community for some reason so I did not know you responded to my post.

I think using the Account ID and Rule ID would be appropriate.  Thanks!
Userlevel 3
We use data triggers to do this and we use the account ID + playbook ID as the unique identifier.  This way, it can also look to see if there has been a manual CTA created with that playbook.  For these purposes, we don't care whether the CTA was created through the rules engine or automatically; if there is a CTA for that account with that playbook, that's good enough for us.  But doing it on Rule ID would be useful in other situations as well.  Would be good to have both options.
Userlevel 7
Badge +2
Good thought Sean!
Userlevel 4
We also did this similar workaround. The main rule looks to see if the last run date is < x days. If so, then the rule will fire. We then have a rule that populates the last time the CTA fires. It's important to keep in mind that with this workaround, the rule will not work if the "last run date" field is null, so you will have to do "last run date < x days OR null". Hope this is helpful.
Userlevel 7
This capability is available now.

Thanks,
Nitisha
Userlevel 3
Has anyone else had their rule execution fail with the use of the new Create CTA once in X days function on the set-up action? Nitisha, are there any specific restrictions to the use of this new capability that might be causing the fail? Just wanted to check with the community before submitting a support ticket.
Userlevel 7
Hi,

No, their are no restrictions in this functionality. Can you please share with us (or raise a support ticket) the scenario in which this functionality is not working and we will look into it.

Thanks,
Nitisha

Reply