Option to delete MDA dropdown list items

May be with an option to replace it to another existing picklist when delete available.

Seeing crossover from this post 

• Unable to Delete a Dropdown Associated w/ an Activity Type

I accidentally created a dropdown list (+ dependency)  in the wrong environment and would love to be able to delete it! 

Hi @kyle_handley,

Sorry for the late response.

Right now we cannot delete Dropdown lists, but you can make them inactive when you try to edit the dropdown list value.

Thank you,

Bhawya

@Bhawya is it on the roadmap? I don’t think this should be labeled as “workaround available”

Inactive is insufficient. It creates a horrible user experience, not to mention admin experience where we need to ensure any Inactives are at the bottom of the list. Users still see the greyed out options and we have to field unnecessary questions about them. 

@ana_g - We have received feedback on this earlier also but as a dropdown item list would have been used in multiple places, we need to thoroughly analyse this along with dependent teams for a final solution.

This is under consideration, I will update this thread once there is more clarity on the timeline.

@gunjanm - Agreed, hence we are analysing this for a better solution.

Thank you,

Bhawya

+1 for this - we should be able to delete if no dependencies are found (i.e. no records are using the value)

Alternatively let us update those records with a different value as part of the delete process.

Aside from examples of accidentally creating a picklist option, I don’t think I have many use cases to delete. But the user experience is terrible as-is. If a value is inactive, why can people still see it in the dropdown? (even if it is greyed out?) Even if I can’t delete it, at least let me hide it!!

Adding onto this - While updating the system to match a more standard way of naming, we’re finding there are a LOT of duplicated list because naming was off.  We want to delete those Dropdown lists to not cause confusion in the future. [Our current work around is adding DNU to the name of the actual Dropdown.]

Adding my use case - most of the time when I run into this it is a field we are syncing from Salesforce to Gainsight. I don’t have any control over what the SFDC admins add as values in a picklist, so there have been several times when they remove old values that I’m then stuck with in Gainsight. These values are not used on any record, so it’s really frustrating that I can’t either delete them completely or AT LEAST completely hide them from the UI (I understand graying them out in the UI if there are still records associated with the value, but this is not the case). There have been times where I’ve had to create a new field completely and replace it on all reports, etc. because the experience has become so bad for my users.

Everything is dynamic and we should be able to delete fields in a drop-down, provided that all dependencies have been accounted for. It’s a negative experience for the end user to see something outdated and a poor admin experience to have to recreate a list of get rid of some values that are no longer needed. Please make this possible!

I have the same use case as @cankney.  We recently migrated SFDC instances, and most of the dropdown values in SFDC changed to completely different ones, so ideally, I would be able to update them to match by deleting the ones no longer in use.

If I can create it as an admin, I should be able to delete it.

Let me try to get some PM attention to this.

We cannot track if the dropdown and the dependency has already been set in the data loaded to Gainsight and hence we do not have the capability to delete. If there is data and we delete the dependency, it could corrupt the data and create inconsistent behaviour across different areas

Until we have a fail safe way of identifying if an item has been used, we are evaluating how we can improve the user experience for Inactive Dropdown items.

Few suggestions I have are

1. Sort the Inactive items to the bottom of the list.
2. Hide inactive items while creating new records or editing existing data.
3. Rename the item to Append “Inactive” to the item name.

Open for any other inputs. 

Thank you

Preethi

@pgeorge We are having the same experience as others. It seems logical for admins to be able to configure the inactive list item to be visible or not.

Making unwanted picklist items inactive is not the most ideal since the inactive values are still visible. Agreed with @jochle - it makes perfect sense to provide admins the option whether to make these items visible or not.

Yes Please!

This is long overdue.  Something needs to be done, even if it’s a “soft” delete that doesn’t truly delete, but can’t have these options showing up in the UI, either for filtering purpose or otherwise.

Also, I get that there may be dependencies, but if you delete a picklist value that has a filter on a rule or something like that you could build in some checks, or put in a prompt that says this will break any rule / data designer / case statement / etc. if that value is used.  An Admin should be willing / able to go through affected items and remove appropriate references and deal with ramifications if something is missed.

Can this please be prioritized?

Hi @pgeorge Can we have some feedback on why the idea was parked? 

Thank you

A

Hi @alizee 

Addressing the impact of deleting a MDA Dropdown item requires significant investment on our end. Currently, this enhancement is not scheduled in our immediate roadmap and has been marked as parked.

However, we recognize that this is a highly requested improvement, and we will prioritize it as soon as we have the necessary bandwidth.

This remains an issue with admins looking for a solution.

Thanks,

Stuart

I understand that addressing the impact of deleting a dropdown item would require significant investment. Would a toggle to just hide inactive list items require the same investment?

The number of heavy-hitters commenting here versus the idea’s age contrast heavily with the fact that it’s been parked. Could we get an idea of what “soon” means here?

Here’s a live look at an example of the issues this problem causes:

Our “Email Communication Type” field has all the options below. There are multiple issues here.

1. Our JO programs only sent to accounts with either the “HTML - Live Links” or the “Plain Text - Defanged Link” options, so the “Plain Text - Live Links” and “HTML - Defanged Links” options are just noise (and noise that our end users don’t understand).
2. There is NO situation where the email communication type field should be null.

Due to both of the issues above, we have companies that are not receiving any of our JOs due to these unused fields being visible to our end users. These types of issues cause massive headaches for both admins AND end users, and seems to be a huge oversight in how these inactive options are handled.

So rather than spending a few minutes hiding options from view, we instead have to spend far more minutes tracking down and fixing the issues those visible and inaccurate options cause.