Can a CTA field be made "Mandatory" only for CTAs with specific CTA Reasons? And if so, how is that configured?
I know I can add a CTA field and make it Mandatory for specific CTA [i]Types, but I'm interested in learning if I can make a field Mandatory for specific CTA [i]Reasons.
My use case here involves our interest in classifying the outcome of CTAs created for certain reasons. For example, if the CTA is for a Support Escalation, after we have conducted the motion of the escalation, we want to record the customer's sentiment. Are they now positive because we handled the escalation well, or negative because the escalation was particularly painful?
Making that Sentiment field mandatory for all Risk CTAs (the logical CTA Type for this example) means we're completing that field for all Risk CTAs, rather than just the CTAs for Support Escalations.
Can a CTA field be "Mandatory" for only CTAs with specific Reasons?
+11Making people their best....currently disguised as a CS Ops Architect. How can I contribute to your success?
+5I don't think this is possible but if this gets converted to an Idea I will vote for it! Ran into this recently and this would be a valuable enhancement.
Jeff Kirkpatrick
Hi Matthew & Jeff,
Currently, the layouts are defined per CTA Type & there is no way to make a field mandatory based on the reason selected. So you would want to have different the field setting (mandatory/read-only) per reason? Would you also need this for other things such as Status, Priority?
@jeff: Could you share your use case as well.
Ill change this to an idea post so that other customers who need this can upvote
Regards
Currently, the layouts are defined per CTA Type & there is no way to make a field mandatory based on the reason selected. So you would want to have different the field setting (mandatory/read-only) per reason? Would you also need this for other things such as Status, Priority?
@jeff: Could you share your use case as well.
Ill change this to an idea post so that other customers who need this can upvote
Regards
+11As of now, my need is focused squarely on the field setting for CTA Reason, and does not extend to Status nor Priority. But of course, given enough time, I'm sure I could think of reasons I would use that too. =)
I think the reason that Reason is a great one is we may need to record a specific set of metadata, trapped as fields, for specific Reasons, especially regarding the Outcome of the CTA. For a Sponsor Change CTA, we may need to record if we were able to reach the Contact with the change (yes/no). For a Support Escalation, it may be the Sentiment (positive/negative). For an Upsell opportunity, it may be "Was a SFDC Opportunity created?"
These are all pieces of data which aren't applicable to all CTAs of a specific type, and represent especially data that isn't available at the time the CTA is created. Making them Mandatory for a Type is a little confusing and a lot of extra time completing fields that don't apply. Making them Optional likely means they aren't completed at all by the end users.
I think the reason that Reason is a great one is we may need to record a specific set of metadata, trapped as fields, for specific Reasons, especially regarding the Outcome of the CTA. For a Sponsor Change CTA, we may need to record if we were able to reach the Contact with the change (yes/no). For a Support Escalation, it may be the Sentiment (positive/negative). For an Upsell opportunity, it may be "Was a SFDC Opportunity created?"
These are all pieces of data which aren't applicable to all CTAs of a specific type, and represent especially data that isn't available at the time the CTA is created. Making them Mandatory for a Type is a little confusing and a lot of extra time completing fields that don't apply. Making them Optional likely means they aren't completed at all by the end users.
Making people their best....currently disguised as a CS Ops Architect. How can I contribute to your success?
+5Spot on Matthew.
@Aditya - use case is very similar to Matthew's. We need to be able to capture various details/responses from CSMs based on the reason a CTA was created and it's a lot of overhead to create a custom CTA type for each.
Also - Success Plans only allow you to use one CTA type: Objective. If you need to add fields to capture various results, you have to add them to the Type and then every single Objective CTA contains all the fields. If you make them mandatory, as Matthew says, a lot of time completing fields that don't apply.
This was the key reason we opted not to leverage Success Plans right now in favor of regular CTAs/CTA Types.
@Aditya - use case is very similar to Matthew's. We need to be able to capture various details/responses from CSMs based on the reason a CTA was created and it's a lot of overhead to create a custom CTA type for each.
Also - Success Plans only allow you to use one CTA type: Objective. If you need to add fields to capture various results, you have to add them to the Type and then every single Objective CTA contains all the fields. If you make them mandatory, as Matthew says, a lot of time completing fields that don't apply.
This was the key reason we opted not to leverage Success Plans right now in favor of regular CTAs/CTA Types.
Jeff Kirkpatrick
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.