Allow Dropdown Dependencies on standard fields

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.

I upvoted this a while back and revisiting as the use case at this org is slightly different and so is the need, but the principle remains the same.

Closing Status on CTAs an Tasks typically will contain those options:

• Closed Success
• Closed Unsuccessful/Incomplete
• Closed No Action
• Closed Duplicate

Or something in that vein. 

We’re looking at capturing a closing reason for ONLY some of these options, specifically anything that’s not “Success”, both at the CTA *and* the Task level. 

However, at this org, we’re not quite ready to go for preset “closing reasons” in the form of a dropdown and would like to store that information in a string, so it can be analyzed and we can eventually, at some point, define picklist reasons. 

AND if we pick one of the status for which a closing reason is necessary, the Closing Reason field should be mandatory. 

Side ask (but expected since it comes from me): while the controlling dropdown (e.g. Status) is a single picklist, it should support single and multi picklists as dependent dropdowns…