Hook
Promoting Domo content from a DEV instance to PROD without breaking existing workflows — or accidentally overwriting live logic — is one of the trickier operational challenges in Domo development. Sandbox with Linked Repositories solves this cleanly.
Why It Matters
Without a structured promotion workflow, DEV changes get manually replicated to PROD, QA happens in production, and rollback means reconstructing DataFlows from memory. Domo Sandbox brings version control semantics to Domo content — commit, branch, and promote — so teams can maintain a clean separation between development and production environments. Linked Repositories specifically solve the case where a new DEV component needs to be wired into an already-deployed PROD workflow without rebuilding from scratch.
What You'll Learn
- Set up a Sandbox repository and connect it to your Domo instance for version-controlled content promotion
- Use Linked Repositories to attach DEV workflows into existing PROD workflows
- Understand how Domo Sandbox models CI/CD patterns — what maps to Git concepts and what doesn't
- Structure a DEV → QA → PROD pipeline for Domo DataFlows, datasets, and related content
- Avoid common promotion pitfalls when content dependencies span both environments
Wiring DEV Work Into Live PROD Pipelines With Linked Repositories
The core pattern here is that Sandbox gives you commit history and controlled promotion — think of it as Git for Domo objects. You can snapshot your DEV environment, submit changes to a repository, and then publish those changes to a PROD instance in a controlled, reviewable way.
The more nuanced capability is Linked Repositories. In practice, PROD workflows are often already built and running. When new development work needs to extend or integrate with those live workflows, you don't want to redeploy the entire PROD pipeline from a DEV snapshot — that's high risk and high friction. Linked Repositories let you attach a DEV repo into a PROD repo relationship, so newly developed components can be merged into the live environment selectively.
The QA step sits between these two states: before promoting from DEV, you can validate logic, test DataFlow outputs, and confirm dataset schemas against expected results — without touching production data or pipelines. This maps to the staging/QA lane in a standard CI/CD pipeline.
A few things to keep in mind when implementing this pattern: Sandbox version control tracks Domo content objects (DataFlows, datasets, cards), not arbitrary code — so the mental model is closer to infrastructure-as-code than application Git. Promotion conflicts arise when PROD content has drifted from the last snapshot, which is why consistent commit discipline in DEV matters from day one.
For teams already using Domo heavily and feeling the pain of manual promotion or "works in DEV, broken in PROD" incidents, this is the workflow to standardize on.
