Someone posted in the Domo community asking how to send a dataset from their prod environment back to QA. That question is backwards. You don't QA after you push to prod. The fact that they were asking it at all told me they didn't have a clean way to manage assets across environments.
The Problem with One Instance
If you're running a single Domo instance — the one instance to rule them all — you're fighting entropy. You can't look across hundreds of dashboards and datasets and reliably answer: is this dev? Is this a proof of concept? Is this a "delete me" file someone forgot about? Or is this a real production asset?
Some teams try naming conventions. Others do "12 Days of Domo Cleansing" events. Neither works long-term. Naming conventions decay. Cleansing events are manual, infrequent, and incomplete.
The Model: Departmental Dev + Read-Only Prod
Here's the model that works:
- Departmental instances — developers log in here, build dashboards, create datasets, iterate freely
- Domo Publish — finished content gets published from dev instances into a read-only environment
- Read-only environment — everyone else in the company accesses dashboards here
This gives you a clean separation: anything that's published is production. Anything that's not published is development (or garbage).
Why This Saves Money
On the consumption model, every dataset that runs costs credits. Most Domo developers schedule everything to update daily — proofs of concept, test files, "delete me" datasets that nobody has looked at since creation. That's wasted credits.
With the publish model, you can enforce a simple policy: if it's not published, it's not scheduled. And if it's not scheduled and hasn't been touched in 20 days, delete it. You can script this. You should script this. Stop doing it by hand.
Access Control Gets Easier
In a single-instance world, you're constantly wrestling with who gets manage-all-datasets, who can see HR data, who can see sales data. It's a mess.
With separate instances:
- HR developers build in the HR instance with full access to HR data
- Sales developers build in the Sales instance with full access to sales data
- Finished dashboards get published to the read-only environment with the appropriate PDP (Personalized Data Permissions) applied
- Nobody in the read-only environment needs manage-all anything — they just view dashboards
You could even run the read-only environment entirely through service accounts. No human admins needed.
Sandbox + Publish
Publish is not the only gate you need. Domo Sandbox is version control for your dashboards. Use it alongside Publish:
- Sandbox handles iteration — v1 to v2 of a dashboard within the same instance
- Publish handles promotion — dev instance to read-only prod environment
The person asking "how do I send a dataset from prod back to QA?" was probably using Sandbox to push from dev to prod, then realizing they needed to test the prod version. The answer is: do your QA in the dev instance. Sandbox there. Publish only goes one direction.
What's Next
The next video covers the script for mapping published assets and automating the delete-unscheduled policy — so you can actually enforce "if it's not published, it's not scheduled" without lifting a finger.
