Allow Dropdown Dependencies on standard fields

+1 I can’t even list the number of possibilities this would open up for fillable-form style content in Gainsight on CTA’s and Timeline Activities. It would be an exciting addition.

@anirbandutta @jake_ellis not sure who the PM is for this, but this idea, combined with the post below, would make CTA use even more useful and flexible.

• Cockpit: Custom CTA fields should be visible by default Development
• 38 Votes

I just started at a new company, and I’m having difficulty convincing people to use CTAs vs Timeline for managing risks (a process that was created before I joined) because the customized Timeline creation pane is more user-friendly, makes dependencies easier to use, contextually, and - in their words - “is easier and takes far less effort to use than creating a CTA… and if we have to add notes as Timeline entries with the CTA anyway, why bother with the CTA when we can just go straight to the Timeline?”

Even though CTAs provide additional capabilities that Timeline does not, looking at this from their perspective, they’re not entirely wrong.

Combining these two requests would be a major boost to CTA flexibility!

Finding out internally

Would definitely make reporting easier as well as the CTA experience for the user. 

@anirbandutta were you able to follow up on this?

@sriram pasupathi the more that custom fields are used on objects like CTA, the more the ability to establish dependencies on standard fields becomes necessary.

I am in the process of moving my company from using Timeline as a Risk tracker to CTAs. One of the things they don’t like is that now ALL reasons have to be listed in the Reason picklist where before on Timeline, we had a custom field called “Risk Theme” and when they picked an option from that field, there was a “SubReason” picklist that automatically aligned to choices that map to the RIsk Theme.

As @TMaier said, this would open up a number of possiblities.

@mpatra could you pl update the latest status on this request

FYI I had this exact use case (a subreason field controlled by the reason field) on this request as well
 

Hi team,

We will be evaluating the above request as it seems like it would add a lot of value. But we do not have a release timeline for this request yet. I will keep this group posted as and when I have more information on this request.

Thanks,
Monica 

This would still be great

Hitting this myself now. Just like @darkknight ‘s scenario, I’m facing the same. We want to get more granular on our risk reasons. My thought was to create a dropdown that allows a user to provide a more granular risk reason that would be dependent on the CTA Reason chosen. Then I find out that I can’t make dependencies off of CTA Reason (or CTA Type, for that matter).

This would go a LONG way in being able to get more details on our risks.

Example

CTA Type = Risk

CTA Reason = Implementation

Risk Detail (custom dropdown) has options of Customer resourcing constraints, Severely delayed or slow, Missing critical use case, Never instrumented properly, Product not live or delayed...etc etc

This couldn’t get in the backlog yet, but definitely on the radar of the PM. cc @mpatra 

Why is this not a thing? Salesforce can do it. 😭

Just ran into this today exact use case today - would be a huge improvement for our team and reporting.

​@revathimenon ​@jake_ellis could we get this looked at? it’s a fairly popular ask.

Thanks for the bump on this ​@darkknight. We’re going to look at how to make the UI more configurable this year (eg. mandatory fields, hiding fields, etc.) and this is another item that we’ll take a closer look at. 

​​​​​@AshutoshSingh ​@pgeorge 

We also have a use case for this feature! Thanks for considering!

We do not allow for modifying metadata for Standard fields as they would create unknown impact on existing implementations. The only workaround I can think about is to create custom dropdowns and create the dependencies. 

Meanwhile we will also evaluate the ask and the impact from our side ​

Thank you 

Preethi

​@pgeorge we already know the workaround, but it creates unnecessary redundancy.

Allowing a Standard field to be a “controlling” field modifies metadata?

I know they are separate platforms, but the concept is the same and Salesforce is able to make this work. I have to believe Gainsight can as well.