We use picklists a lot they provide consistency for reporting and reduce clicks. However, we have some piclists that have constantly changing values. For example, on our custom demo request object we have a picklist to select the demo unit being requested. We get frequent requests from the business to deactivate values (taking a unit out of rotation for maintenance or repairs, or retiring it), renaming units, adding new units, etc.
We do releases every 2 weeks, so that can mean that sometimes their changes have to wait longer than they would like, and its also just a lot of piddly maintenance for us.
Is there a way to give a group of users a way to maintain the picklist values? I know I can give them delegated administration rights to a custom object, but that gives them rights to everything and we really want to restrict it to just the picklist values for particular fields. We have multiple business units sharing the same org, so there are a lot of record types, etc and it just seems risky to give product managers or other business users admin rights - too easy for them to inadvertently change something and cause a domino effect. Our org is also almost 20 yrs old, so there's a lot of complexity and historical development that adds to the risk.
Without having to write and maintain a bunch of code, has anyone found a solution to a problem like this? An app exchange app or some custom declarative development you've done to tackle a similar problem?
This is a very common 20 year org pain point. Native picklists don't support field level delegated admin it's all or nothing at the object level, which is why you're stuck. The standard fix is to stop using a native picklist for these specific values and replace it with a
custom object + lookup, since object level security is far more granular than field level picklist security.
Custom object + lookup (most common fix)Replace the picklist with a custom object (e.g. Demo_Unit__c) and a lookup field on Demo Request. Business users get a permission set granting CRUD on just that object.
- Full object-level security - users can add/deactivate/rename records without touching anything else
- Use an Active__c checkbox instead of deleting, so historical reports/records aren't orphaned
- Build a simple Screen Flow or List View for them to manage records no raw object Manage access needed
Custom object + Dynamic Forms/LWC picker
Same object-based model as above, but pair it with a small custom LWC on the record page so end users pick from Active units only, keeping the UX close to a picklist.
- Solves the "users select inactive/retired units" problem cleanly
- Slightly more build effort (LWC), but no ongoing dev involvement after that
- Can filter by business unit/record type via the LWC's Apex controller
AppExchange picklist management apps
Several free/paid AppExchange apps exist purely to let non-admins manage picklist values through a guided UI, without touching Setup.
- Search AppExchange for "picklist manager" - a few free options exist (quality/support varies, vet carefully)
- Worth evaluating if you have many picklists like this across objects, not just one buying beats building N custom-object solutions
- Still worth confirming the app respects your record-type/business-unit segmentation before adopting org-wide
My recommendation for your specific case: custom object + lookup, with reports switched to use the lookup's Name field. It's the cleanest fix for exactly your constraint restricting access to just this data, not full delegated admin and since this is one field on one object, contained migration rather than a big lift. Given your 20 year org's complexity/risk profile, I'd avoid anything that touches broader admin permissions (delegated admin, Setup access) entirely.
I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.
