How do you decommission a Salesforce custom object with 100+ workflow rules tied to it without breaking quarterly pipeline reporting?
Decommissioning a Salesforce Custom Object With 100+ Workflow Rules Without Breaking Pipeline Reporting
Decommission in phases, not one cut. Audit every dependency — reports, dashboards, Apex, flows, and workflow rules — before touching prod. Freeze the object first (read-only), migrate data to the replacement structure, run parallel reporting for one full quarter, then delete. Skip any phase and you break pipeline numbers mid-quarter.
---
THE DETAIL
This is a 6–8 week project minimum. Rushing it is how RevOps teams blow up a board-level pipeline call. Here's the exact sequence:
1. Full dependency audit (Week 1) Run Salesforce's Setup → Object Manager → [Object] → Where Is This Used? plus a metadata scan via Salesforce CLI (sf dependency commands) or a tool like Elements.cloud or Metazoa Snapshot. A change in object configuration can have an enormous impact on millions of records of data stored across standard and custom objects. You're looking for: reports, dashboards, Apex triggers, validation rules, flows, process builders, and all 100+ workflow rules. Log every one in a dependency matrix (object, rule name, business owner, last fired date).
2. Triage the 100+ workflow rules into 3 buckets
- Kill: rules that haven't fired in 90+ days (pull
LastModifiedDate+ field history logs to confirm) - Migrate: active rules that map to a surviving object → rebuild in Flow Builder now. Migrating from Workflow Rules and Process Builder to Flow is not always a simple 1:1 replacement — Salesforce recommends a comprehensive assessment of existing automations grouped by object and business process.
- Defer: rules owned by another team that need sign-off before touching
3. Protect pipeline reporting first If a sales team changes stages on the Opportunity object, a business analyst equipped with process documentation would point out that the field is also used by the finance team in financial forecasting and by marketing to track campaign success. Map every pipeline report/dashboard back to its source fields. Build replacement reports off the new object or standard Opportunity fields before you deactivate anything. Run both versions in parallel for a full quarter-close cycle.
4. Label → Restrict → Archive → Delete Label the customization so it's clearly visible in the UI that it's being decommissioned. Update labels with "OLD" or "TBR" (To Be Removed). Then:
- Rename object to
[ObjectName]_DEPRECATED - Remove from page layouts and nav menus
- Back up metadata and data — use Salesforce CLI or Force.com IDE to download metadata as XML, and store in Git or a source control system.
- Export data via Data Loader to CSV cold storage
- Hard-delete the object after 30-day freeze window
5. Critical timing rule: Never cut during active quarter-close Lock the decommission window to the first two weeks of a new quarter. Pipeline snapshots, board decks, and forecast calls all pull historical data — a mid-quarter deletion can corrupt trend lines in Tableau CRM / CRM Analytics even if the live reports look fine.
---
Workflow Rule Decommission Sequence
---
Decommission Phase Benchmarks
| Phase | Timeline | Key Risk | Tool |
|---|---|---|---|
| Dependency audit | Week 1 | Missing Apex references | Elements.cloud / SF CLI |
| Flow migration | Week 2–4 | Governor limit violations | Flow Builder + sandbox |
| Parallel reporting | Weeks 4–8 | Data drift between objects | CRM Analytics / Tableau |
| Freeze & label | Week 6 | User confusion, workarounds | Change management comms |
| Hard delete | Week 8+ (post quarter-close) | Historical report corruption | Data Loader backup first |
---
One more flag: Salesforce ends support for Workflow Rules and Process Builder after December 31, 2025 — existing automations may continue to operate but will no longer be eligible for bug fixes or official support. This decommission is also a forcing function to get off legacy automation entirely. Use the migration to consolidate 100 workflow rules into 3–5 well-structured Flows. You'll cut org complexity and eliminate a whole class of future governor limit errors.