Preventing Metadata Loss in Shared Salesforce Sandboxes: A Lesson in Governance and Rebuilding

When two teams share a Salesforce sandbox, transparency isn’t optional; it’s foundational. We learned this the hard way after an unannounced sandbox refresh erased months of declarative development. Here’s what happened, how we recovered, and the operational changes that now protect us.  

‍

‍

‍

The Incident  

‍

Team 1 needed to refresh a shared sandbox to align with production data for User Acceptance Testing (UAT). Unaware that Team 2 was in the midst of development, they proceeded without notification. The refresh wiped Team 2’s work entirely, including custom objects, validation rules, page layouts, and—most critically—complex flows and schema relationships (master-detail and lookup links) that define the feature’s data behavior.  

Since the project was still in development, no technical documentation existed. Only a UI-focused user guide remained. Without backups or version control for declarative metadata, recovery was impossible.  

‍

‍

Why Declarative Work Is Especially Vulnerable  

‍

Unlike coded solutions (Apex, LWCs), declarative configurations like flows, custom objects, and automation rules exist solely within the Salesforce org. When a sandbox refreshes, these elements vanish unless they are explicitly backed up. In our case, three specific losses compounded the setback: the custom object schema, which structured the data model, the flow logic governing business processes, and the validation rules ensuring data integrity.

‍

The user guide allowed Team 2 to reconstruct the UI (record types, page layouts), but the backend logic had to be rebuilt from memory, subtly altering its behavior.  

‍

‍

Our Solution: Bridging Process and Communication  

‍

To prevent recurrence, we implemented a cross-functional strategy focused on governance, safeguards, and documentation.  

‍

First, sandbox governance tightened significantly. Sandbox refreshes now require a 72-hour advance notice to all impacted teams via Slack and email, with schedules centralized in Jira. We also restructured our environment strategy: teams now receive dedicated sandboxes, while a single shared “integration” sandbox syncs only weekly.  

‍

Second, we fortified declarative safeguards. Metadata loss is now mitigated through weekly backups of objects, flows, and relationships using OwnBackup. Schema integrity starts pre-build, with object relationships mapped in Schema Builder or Lucidchart. For version control, we track changes to declarative elements via Salesforce DX or Gearset, treating metadata like source code.  

‍

Third, documentation discipline became non-negotiable. Every custom field, flow element, and validation rule now includes embedded descriptions. We also conduct weekly lightweight audits using Salesforce Inspector to export critical metadata.  

‍

‍

Lessons Learned  

‍

Three principles now guide our work:  

‍

1. Metadata - flows, custom objects, and relationships require the same rigor as Apex: versioning, backups, and reviews.  

2. Visibility Prevents Catastrophe. Sandbox refreshes impact every team using the environment. Overcommunication is cheaper than rework.  

3. Rebuilding Exposes Gaps. Having to recreate flows revealed ambiguous logic. Now we diagram flow paths and document schema dependencies before development.  

Though rebuilding was resource-intensive, it refined our approach to declarative design. Team 1 coordinates refreshes now; Team 2 backs up work daily.  

‍

‍

Moving Forward  

‍

Finally, for teams working in similar environments to ours, these are the things to keep in mind:  

‍

• Back up declarative work weekly using tools like OwnBackup.  

• Map object relationships before configuring the schema.  

• Notify all stakeholders before refreshing any shared sandbox.  

• Describe every field and flow element during development, your future self will thank you.  

‍

In shared Salesforce ecosystems, proactive collaboration is as vital as technical discipline.  

‍