# How to change a Salesforce picklist without breaking automation. > Changing a picklist safely with SyncOnAI 360 means listing the Flows, validation rules, Apex and components that reference the field, counting live how many records hold each value, drafting the change, and shipping it as a proposal with named checks, validation against the org and approval, with rollback for the metadata. Source: https://synconai360.com/use-cases/picklist-impact ## Key facts - **Live**: Record counts per value - **12**: Affected components named on the proposal - **0**: Guessed dependencies - **1**: Approved path to production ## Why picklist changes cause outages Picklist values are compared as text all over an org. Change one, and a Flow decision, a validation rule or a line of Apex quietly stops matching. - **Text comparisons everywhere.** Values are hardcoded in automation, rules and code. - **Records left behind.** Old values stay on records after the picklist changes. - **Reports and integrations.** Downstream consumers expect the old values. - **Changed at quarter end.** Sales stages change exactly when the pipeline matters most. ## What references a Salesforce picklist field? Ask what uses the field, or open it in Lineage, and see the Flows, validation rules, Apex and components that reference it, from an evidence-based dependency graph. Where source could not be read, the answer says so. Open each referencing Flow in the Flow builder to see, in plain sentences, how it uses the value. - Every evidenced reference - Flows explained in plain sentences - Unreadable source reported ## How many records use each picklist value? Ask for a count of records by value and the query runs live against the org. Retiring a value used by thousands of open records is a different decision from retiring one nobody chose. - Counts per value, live - Open versus closed records - Records never stored ## How do you ship the picklist change? Draft the change and update the references, in the builders or through the chat, as one set of proposals. Each carries named checks, its blast radius and a validation against the org before approval. Freeze windows in the deploy policy can stop changes landing at quarter end, and every deploy leaves a receipt with rollback for the metadata. - References updated together - Validated before approval - Freeze windows respected ## What about records holding the old value? Rollback restores metadata, not data, so plan how existing records will be handled before the change ships. Anything that would update records from the chat waits for a person to press Allow. - Data plan first - Data changes need Allow - Metadata rollback only ## How do you confirm nothing was missed after the change? Components deployed through SyncOnAI 360 are read back straight after a successful deploy, so lineage reflects the change at once. Ask again what references the old value: anything still listed was missed and can be fixed before users find it. Run the audit again to check that no new overlapping automation or broken references appeared. - Read back after deploy - Ask again for the old value - Re-audit ## How do validation rules and Flows need to change with the picklist? Any validation rule or Flow decision that compares the field to the old value needs the new value too, or it will stop matching. Open each referencing Flow to see its decisions in plain sentences, and ask the chat to draft the matching updates as proposals alongside the picklist change. Shipping the references and the picklist together means there is no window in which automation runs against values that no longer exist. - Find every comparison - Draft the matching updates - Ship them together ## How to change a picklist safely 1. **Find references.** List everything that uses the field. 2. **Count records.** See how many records hold each value. 3. **Plan.** Decide on existing records and update references. 4. **Ship.** Propose, validate and approve outside freeze windows. ## A picklist change, hopeful versus checked | Without | With SyncOnAI 360 | |---|---| | Change the value and wait | Every reference listed first | | Records left with old values | Counts per value, live | | Flows silently stop matching | References updated in the same change set | | Changed at quarter end | Freeze windows enforced | ## Before you change a picklist - [ ] List every Flow, validation rule, Apex class and component that references the field. - [ ] Count the records holding each value you plan to change. - [ ] Decide how existing records will be handled before the change ships. - [ ] Draft the picklist change and its reference updates together. - [ ] Check the deploy policy's freeze windows, especially near quarter end. - [ ] Test the full set in a sandbox. - [ ] After deploying, ask again what references the old value. ## Who changes picklists - **Revenue operations.** Change stages and values without stalling the pipeline. - **Salesforce admins.** Retire values with proof of what depends on them. - **Developers.** Find hardcoded values in Apex before they break. ## Frequently asked questions ### Can it find hardcoded picklist values in Apex? It lists Apex that references the field from parsed source; open each class to see how it uses the value. ### Can it count records by value? Yes, live against the org. ### Can it update old records? Anything that changes data waits for a person to press Allow, and rollback cannot reverse it. ### Can we block changes at quarter end? Yes, with freeze windows in the deploy policy. ### Does it check record types and dependent picklists? Record types and value sets are synced metadata; the dependency answer states what was examined. ### Is the change validated first? Yes, against the target org, before anyone approves it. ### Can we roll back? The metadata, yes, from the receipt. Data changes cannot be rolled back. ### Is this on every plan? Yes. Every plan includes every feature. ### Can it show which Flows compare the value? It lists the Flows that reference the field, and the Flow builder explains each one's decisions in plain sentences. ### Should the change go to a sandbox first? Yes. Members can deploy to sandboxes freely, so test the picklist and its references there first.