Hi everyone,
I’m looking for some architectural advice on Release Management strategy. I’ve recently joined a large-scale Salesforce implementation where multiple teams (internal and external) are working on the same Org.
We are using a professional deployment tool (like Copado/Gearset), but the current process requires a mandatory manual step: maintaining an Excel file where every metadata component must be listed before any deployment.
- The project involves an internal Client Admin and several external consultants.
- The Excel list is used as a 'communication bridge' to prevent overwriting metadata (like Picklist values) and to keep non-technical stakeholders informed.
- Sometimes, we need to 'audit' and migrate developments from isolated sandboxes where no initial Git tracking was used.
So, these are my questions:
- For those in complex, multi-vendor environments: How do you move away from manual spreadsheets without losing visibility for non-technical PMs?
- What is the best way to handle 'metadata conflicts' with a client’s internal Admin without falling back to a manual 'shopping list' approach?
- Are there any lightweight 'Audit' tools or strategies you recommend to quickly identify components created in an unmanaged sandbox to avoid hours of manual inventory in an Excel file?
Thanks for your insights! @Salesforce Administrators & Developers, @APAC Architects @Salesforce Administrators and Developers
Hi Lena, this is a really common challenge in large multi-vendor Salesforce implementations. I have worked through this exact scenario and here are practical answers to each of your questions:
Q1 - HOW TO REPLACE THE EXCEL WITH TOOL-NATIVE VISIBILITY FOR NON-TECHNICAL PMs
The key insight is that the Excel was serving two purposes: conflict prevention and stakeholder communication. You need to solve each separately.
For conflict prevention in Copado/Gearset:
- Copado: Use "User Stories" with proper branch policies. Enforce that every change must be tracked in a User Story before it can enter a pipeline. The User Story list IS your living inventory - replace the Excel with the Copado backlog board (which non-technical PMs can view)
- Gearset: Enable "Deployment Conflict Detection" - it automatically flags when two deployments touch the same metadata component. Pair this with Gearset's deployment history log (shareable via URL) for PM visibility
- Both tools: Set up Slack/Teams notifications that fire when a deployment is initiated and completed - PMs see activity in real time without a spreadsheet
For non-technical stakeholder visibility:
- Copado has a built-in "Release" view that shows all User Stories going into a release - share this URL with PMs
- Create a simple Salesforce Dashboard in your Salesforce org (or a Jira board) that maps to your deployment pipeline stages - PMs understand Kanban boards
Q2 - HANDLING METADATA CONFLICTS WITHOUT A SHOPPING LIST
- Use source-driven development: everything goes through Git first. Even the client Admin should commit changes via VS Code or SFDX before deploying. This makes Git the single source of truth, and conflicts surface in the branch/PR process, not at deployment time
- Enforce protected metadata policies: In Copado, set "Locked" metadata components (like Global Picklist values) as protected components that require a change request to modify
- For Picklist specifically: document a Picklist governance policy - only one team "owns" each Picklist - and use Copado's conflict resolution UI to manage conflicts visually instead of via Excel
- In Gearset: use "Deployment Monitoring" + "Org Comparison" to see exactly what the internal Admin changed in production since the last Git sync
Q3 - LIGHTWEIGHT AUDIT TOOLS FOR UNMANAGED SANDBOXES
These are the tools I recommend for quickly identifying components created in unmanaged sandboxes:
1. Salesforce Inspector (Chrome Extension) - FREE: Instantly shows all metadata in an org, lets you export object lists, field lists, etc. Great for quick inventory
2. SFDX CLI + "sf org list metadata": Run sf org list metadata --metadata-type CustomObject to get a full list of metadata by type - much faster than manual Excel inventory
3. Gearset's Org Comparison: Compare the sandbox directly against your Git repo baseline to see what's drifted - produces an exportable diff report
4. Copado's "Commit Changes" screen: Shows you everything in a sandbox that hasn't been committed to Git yet - essentially your untracked component list
5. Salesforce's own Setup Audit Trail: Export it (limited to 180 days) to see recent configuration changes
OVERALL RECOMMENDATION:
Make Git the mandatory first step for everything. The Excel shopping list exists because people bypass Git - once you enforce Git-first (via branch protection rules and CI/CD gates), the Excel becomes redundant. Start with Copado/Gearset's conflict detection and replace the Excel one team at a time.
Hope this helps your implementation!
