Hi Guys,
We have a team of omnistudio developers around 5 to 10 who are working on multiple usecases on our project. Currently we have one dev sandbox where our developers are working and have a source control tool with Copado for deployments. The work is already partitioned in a way that there is no overlap on the components and each developer is working on their own module with no conflicts. We have leadership asking on why we cannot have individual dev sandboxes for each developer compared to one sandbox which is quite the norm on standard apex salesforce development. I have been told that there is a lot of manual config work which needs to be done for deployments if we have more sandboxes increasing the deployment time. I would like to know the pros and cons of having an individual sandbox compared to one sandbox with work managed to avoid conflicts and considerations I need to be aware of to manage deployment and code conflicts better.
Buyan
Hi Buyan - great question, and the honest answer is 'it depends on your OmniStudio storage mode' - that's the fork that decides whether the standard-Apex norm applies to you.
The core reason OmniStudio doesn't follow the one-sandbox-per-dev norm out of the box: its components (OmniScripts, FlexCards, DataRaptors, Integration Procedures) reference each other, and in the older managed-package model they're stored as DATA (records with internal IDs), not text metadata. So they don't Git-merge cleanly like Apex/LWC - moving a developer's work between orgs means running DataPack migrations and re-resolving cross-component references. Spread 5-10 devs across individual sandboxes and you multiply that migrate-and-remap overhead every time you consolidate. That's the manual config work you were warned about, and it's why a shared dev org is the pragmatic norm for OmniStudio.
But check which mode you're on first (Setup > OmniStudio Settings):
- If you're on OmniStudio Metadata (the newer standard-metadata model), your components ARE true metadata - source-controllable and deployable through the metadata API / Copado just like Apex. In that case individual sandboxes are far more viable and leadership's ask is reasonable; I'd pilot it.
- If you're still on the managed-package / DataPack model, individual sandboxes will genuinely add the overhead you described, and the single shared sandbox you have (clean partitioning + Copado + no conflicts) is a sound, efficient setup - you're not doing it wrong.
Trade-offs if you do go individual:
- Pros: isolation (one dev can't break another's work-in-progress), closer to standard DevOps, independent refreshes.
- Cons: per-dev migration/merge overhead (especially in DataPack mode), duplicated config/data setup per sandbox, cross-reference re-mapping, and more Copado pipeline complexity.
Middle-ground options that often beat all-or-nothing:
- A few 'workstream' sandboxes (2-3 devs each, grouped by module) instead of 1-per-dev or everyone-in-one.
- Individual sandboxes only for high-risk/experimental work, with routine work staying in the shared dev org.
- Or invest in moving to OmniStudio Metadata so you can adopt individual sandboxes cleanly.
Whichever way you go, keep a shared 'integration' sandbox where everyone's work merges and is tested together before it promotes - that matters more than how many dev sandboxes you have.
Hope that helps frame the conversation with leadership!
