I need the ability to suppress the creation of CTA "B" if the customer already has CTA "A" opened.
In our use case, the customer lifecycle is fairly linear, so until issue "A" is cleared up, of course issue "B" is going to be an issue because "B" is dependent on "A." (In real terms, if the customer hasn't loaded their users, for example, of course there is going to be an issue with their usage of the product.) Our CSMs do not want to see CTA "A" and "B" together. They just want to see CTA "A" ... and when that's closed out, the system can evaluate whether CTA "B" is now an issue.
I've built a bionic rule that does the following:
1. Data task identifies all customers where "B" is an issue.
2. Data task identifies all customers where CTA "A" currently exists in Open status.
3. Merge task combines the two data sets, keeping only the customers that are eligible for CTA "B" and do NOT already have CTA "A" raised.
Action: Raise CTA "B" for those customers
This isn't working. The Action is raising CTA "B" for all customers in Data set 1, so it would seem that my attempt to merge out the ones identified in Data set 2 is failing.
But my overarching question is, Am I approaching this in the best way, or is there a better way?
If this is the best way, perhaps I need help troubleshooting my rule.
I suggest two different rules/CTAs. Write one for situation A, then a second rule that monitors the conditions for situation B and assigns the new CTA. Deal with it in stages.
+2Hi Sarah,
I think you're on the right track, but you should flip your filter at step 2 to return all customers where CTA "A" is NOT in open status.
Then merge those two data sets keeping accounts where both conditions are true (inner join). This would give you all customers where "B" is an issue and for which CTA "A" is not currently open.
I think you're on the right track, but you should flip your filter at step 2 to return all customers where CTA "A" is NOT in open status.
Then merge those two data sets keeping accounts where both conditions are true (inner join). This would give you all customers where "B" is an issue and for which CTA "A" is not currently open.
I'm not understanding why the second data should look for customers where CTA "A" is not opened? Sure, it would return customers where CTA "A" was opened at one point but is now closed, but CTA "A" may never have been opened for the customer, and now CTA "B" is an issue. Those customers would not get CTA "B" raised.
I am not sure any of the Join Types will work for me because I am trying to EXCLUDE the accounts that appear in the data set at step 2, then raise CTA "B" for the customers who remain in the data set after the merge.
I am not sure any of the Join Types will work for me because I am trying to EXCLUDE the accounts that appear in the data set at step 2, then raise CTA "B" for the customers who remain in the data set after the merge.
Don't think of it as looking for when CTA "A" is not opened. Think about it in terms of separating the conditions. Have CTA A"A look for one set of conditions from the data and CTA "B" look for a different set of conditions.
+2@Sarah - the reason for filtering the second step in that way is that you want to exclude all customers that have CTA "A" open, right?
It's ok if your list on data task 2 includes customers that never had CTA "A" open or other reasons, as all that you want with this rule is to find customers who currently have CTA "B" condition but who do NOT currently have CTA "A" open.
You'll actually want to do a left join - start by looking for all customers who have condition "B" (the left data set) AND then only keep customers who do NOT have CTA "A" open (the right data set).
@David - there's not a need to separate this into two different rules, as the bionic nature of Bionic rules allows you to evaluate multiple different data sets and merge them into a single output comprised of multiple steps.
Bionic rules was actually created, in part, to eliminate the need to create multiple rules chained together to accomplish a single (complex) task.
It's ok if your list on data task 2 includes customers that never had CTA "A" open or other reasons, as all that you want with this rule is to find customers who currently have CTA "B" condition but who do NOT currently have CTA "A" open.
You'll actually want to do a left join - start by looking for all customers who have condition "B" (the left data set) AND then only keep customers who do NOT have CTA "A" open (the right data set).
@David - there's not a need to separate this into two different rules, as the bionic nature of Bionic rules allows you to evaluate multiple different data sets and merge them into a single output comprised of multiple steps.
Bionic rules was actually created, in part, to eliminate the need to create multiple rules chained together to accomplish a single (complex) task.
+4@Dan to your point on not needing to split them into separate rules: multi-tasked bionic rules are awesome and provide flexibility for when you have no other way to achieve an objective but to merge various data sources. But I am an advocate for splitting tasks up into separate rules whenever possible because it makes troubleshooting far less complicated and cumbersome.
Jeff Kirkpatrick
@Dan,
I'm following you now, on the reason for having task 2 pull customers where CTA "B" is not open.
Here's where I'm stuck. That second task has a source of CTA, not Account/Customer Info, so instead of returning me a list of customers without CTA "A", it's returning me nothing. I only have 2 customers with CTA "A" raised, to test this with. I know how I would do this in SQL 🙂 or even a Salesforce report, but I'm not sure how, in the GS Rules Engine, to query customers withOUT a particular CTA so that I actually get results in that data set to exclude in the merge?
Thank you!
I'm following you now, on the reason for having task 2 pull customers where CTA "B" is not open.
Here's where I'm stuck. That second task has a source of CTA, not Account/Customer Info, so instead of returning me a list of customers without CTA "A", it's returning me nothing. I only have 2 customers with CTA "A" raised, to test this with. I know how I would do this in SQL 🙂 or even a Salesforce report, but I'm not sure how, in the GS Rules Engine, to query customers withOUT a particular CTA so that I actually get results in that data set to exclude in the merge?
Thank you!
I edited my above comment because I was referencing the wrong CTA.
+2Hey Sarah, I built a sample out in a demo org to simulate your conditions:
First task is to look for all accounts where "NPS Product Comment" (CTA A) does not have a status of "Open" or "Work in Progress". The count aggregation ensures I have one record per Account ID.
The second task looks for all accounts that have a CTA of "Product Risk" type (Condition 😎. The count aggregation ensures I have one record per Account ID.
Next I merge the two data sets using the inner merge (retain common from both data sets) on ID. This will check every Condition B account to see if it also does not have CTA A currently open (but did have it open at one time).
This is the output results.
First task is to look for all accounts where "NPS Product Comment" (CTA A) does not have a status of "Open" or "Work in Progress". The count aggregation ensures I have one record per Account ID.
The second task looks for all accounts that have a CTA of "Product Risk" type (Condition 😎. The count aggregation ensures I have one record per Account ID.
Next I merge the two data sets using the inner merge (retain common from both data sets) on ID. This will check every Condition B account to see if it also does not have CTA A currently open (but did have it open at one time).
This is the output results.
VP of Customer Success at Forcepoint
1 person likes this
+2And if I wanted to include accounts for which CTA A may never have been opened and which is not open now, a simple change can get you that.
Change the filter on CTA A's task to includes instead of excludes.
Change your merge to a left merge and add a field to show the value for the CTA A merge (this will be null if the CTA A is not open, it will have the customer name if the CTA A is open).
And then add a filter task to exclude any records where the field we added in the previous step is not null.
Change the filter on CTA A's task to includes instead of excludes.
Change your merge to a left merge and add a field to show the value for the CTA A merge (this will be null if the CTA A is not open, it will have the customer name if the CTA A is open).
And then add a filter task to exclude any records where the field we added in the previous step is not null.
Hi Dan, Thank you so much for showing a step by step example!
I wish I could say that this worked, but I am not getting the same results as you are on the very first step.
When setting up the first task to find Accounts where the CTA does not exist, I built it exactly as you said (same fields, aggregation, criteria...), but I get 0 results when I preview.
Here is the task setup:
But the Preview shows 0 results, when I would expect to see a record for each Account where this CTA does not exist, right?
To force a result, I removed the Status field from the criteria temporarily so that it would return my only account with this CTA raised, and that preview did show 1 result as expected, but I see that COUNT of Created Date is empty ...
I understand how this rule is supposed to work in theory, but I have yet to be able to pull back a list of Accounts where a particular CTA does not exist.
I wish I could say that this worked, but I am not getting the same results as you are on the very first step.
When setting up the first task to find Accounts where the CTA does not exist, I built it exactly as you said (same fields, aggregation, criteria...), but I get 0 results when I preview.
Here is the task setup:
But the Preview shows 0 results, when I would expect to see a record for each Account where this CTA does not exist, right?
To force a result, I removed the Status field from the criteria temporarily so that it would return my only account with this CTA raised, and that preview did show 1 result as expected, but I see that COUNT of Created Date is empty ...
I understand how this rule is supposed to work in theory, but I have yet to be able to pull back a list of Accounts where a particular CTA does not exist.
+4Hi Sarah - yes, the Count doesn't seem to show in Preview, but it does actually end up with a count when the rule runs. Below, screenshot of rule preview, then screen shot of the dataset task exported to S3. Go ahead and enable S3 export on the dataset task try a test run of your rule and see if you get the same
Thanks, Jeff.
We don't have S3 set up, but I'll look into that for later.
If it's normal that the COUNT shows up blank in the preview, that's fine. Good to know to expect that.
My issue is that I have no results to preview at all. I only get results when I query Accounts where the CTA exists. I get 0 results when I try to query Accounts where the CTA does NOT exist, following Dan's instructions.
We don't have S3 set up, but I'll look into that for later.
If it's normal that the COUNT shows up blank in the preview, that's fine. Good to know to expect that.
My issue is that I have no results to preview at all. I only get results when I query Accounts where the CTA exists. I get 0 results when I try to query Accounts where the CTA does NOT exist, following Dan's instructions.
+4Gotcha. Have you tried pulling the list of accounts that HAVE the CTA (Count of CTA ID = 1), merge that with ALL your accounts. For accounts that don’t have the CTA, Count of CTA ID = 0. Then in your CTA create action, use filter Count of CTA = 0 to determine whether or not to trigger the CTA?
Yes, that was my original approach, and where the initial post stemmed from. When I tried that approach, I was able to get both data sets (list of Accounts eligible for CTA B, and a list of Accounts with an existing CTA A), but I couldn't figure out how to merge them so that Accounts with an existing CTA A would be excluded, meaning they wouldn't get CTA B raised in parallel. I'll keep playing with it!
+4Ah sorry I didn't catch that. I'm at Pulse this week but if I can carve out some time I will play with it as well. It's a good exercise! Let me know if you make progress.
+4Sarah I may have a solution for you.
Dataset 1: List of Accounts where B Is an ISSUE
Dataset 2: Show: Account ID, COUNT of CTA ID
Filter: CTA Reason Code = XYZ (or whatever identifies CTA A)
CTA Status includes New, Work In Progress (or whatever statuses you have that are not Closed/Complete)
Merge:
Action: Trigger CTA B if "CTA A EXISTS = NULL"
Below is the csv output from the Merge.
The first account "B is an ISSUE" and 1 CTA A is open
The second account "B is an ISSUE" and no CTA A is open
Give that a try and see if it works?
Dataset 1: List of Accounts where B Is an ISSUE
Dataset 2: Show: Account ID, COUNT of CTA ID
Filter: CTA Reason Code = XYZ (or whatever identifies CTA A)
CTA Status includes New, Work In Progress (or whatever statuses you have that are not Closed/Complete)
Merge:
- Dataset 1 <-> Dataset 2 - Retain all records from LEFT dataset (should keep all accounts where B is an ISSUE
- Account ID map to Account ID
- SHOW FIELDS: Account ID, COUNT of CTA ID (renamed CTA A EXISTS)
Action: Trigger CTA B if "CTA A EXISTS = NULL"
Below is the csv output from the Merge.
The first account "B is an ISSUE" and 1 CTA A is open
The second account "B is an ISSUE" and no CTA A is open
Give that a try and see if it works?
Jeff Kirkpatrick
1 person likes this
Thanks, Jeff! This looks like it works well and is really going to make our users happy! Appreciate all of the help. Have fun at Pulse.
1 person likes this
+4Very happy to help!
+2Thanks Jeff for the assist here. Your idea was exactly the next one I was going to suggest around use of the filter function.
Community Champion, Jeff K. saves the day again!!
Community Champion, Jeff K. saves the day again!!
VP of Customer Success at Forcepoint
1 person likes this
Reply
Sign up
If you ever had a profile with us, there's no need to create another one.
Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
Welcome to the Gainsight Community
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.