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?
Good question you don't need to merge record types. Add filtering at the data model level instead:
Add a field on Demo_Unit__c to tag which record type(s) it applies to
- Applicable_Record_Types__c - multi-select picklist (values = your dozen Demo Request record type API names/labels), since some equipment types might genuinely apply to more than one record type.
- Business users managing units just check the relevant boxes when adding/editing a unit no extra complexity for them.
Then filter the lookup by record type two ways, depending on which route you picked:
- Declarative (Lookup Filter) - works if you kept it as a plain lookup field: Standard Lookup Filters can reference the parent record, including RecordType. Set the filter on the Demo_Unit__c lookup field: Demo_Unit__c.Applicable_Record_Types__c contains {!$RecordType.DeveloperName} (referencing the Demo Request's own record type). This is fully clicks-not-code — no LWC needed for this part.
- LWC picker route (if you went that way for the "active only" UX): pass recordTypeId into the Apex controller alongside Active__c = true, and filter Demo_Unit__c records where the multi-select picklist contains that record type's developer name. A few extra lines in the controller, but same underlying model.
Why this beats converting all record types into one:
- You keep your dozen distinct page layouts/fields per equipment type exactly as-is zero disruption to existing automation, validation rules, or reports tied to those record types.
- The "which units show for which record type" logic lives entirely in the Demo_Unit__c data (business users can self-serve this too, not just unit name/active status) not in Apex or Flow branching.
- If a new equipment type/record type shows up later, it's just a new picklist value on Applicable_Record_Types__c plus a new record type no redesign.
I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.
