Most problems when building a data product come from a rule doing its job. Dawiso blocks a product from advancing when it would be incomplete or would break another team’s product, and the block is usually the fastest explanation of what is missing.
| Symptom | Likely cause | Fix |
|---|---|---|
| Cannot move the product out of draft | It has no output port | Add an output port |
| Cannot publish — a port is flagged as empty | An output port has no assets attached | Attach at least one asset to every output port |
| Cannot publish — an input port is flagged | An input port has no upstream source | Wire it to an upstream output port, or remove it |
| An asset is missing from the port | Another product already holds it | Consume the upstream port instead |
| An asset cannot be added to a port | Its technology differs from the port’s | Put it on a separate port |
| A contract cannot be attached | The port already has one | Reuse or replace the existing contract |
| The product is not in the Data Market | It is not in production, or visibility is too narrow | Publish it, then check visibility |
| The domain is missing in the wizard | The Space has no Data Product Standard application | Add the application to the Space |
| OSI YAML is missing from the export dialog | The application or space is not set up for data products, or the object is not one | Export from an application set up for data products, or select a data product |
| Export says nothing was exported | Every selected object was either not a data product, or one with no exportable tables | Select a data product with tables attached to its output ports |
| The OSI export fails on the specification version | The configured value breaks the character rule for the version | An administrator sets a valid value, such as 0.1.1 |
The product cannot leave draft
Cause. The product has no output port. A product with nothing to deliver has nothing to build toward, so this rule is enforced.
Fix. Open the Ports step or tab and add an output port, then attach the assets it publishes. See Working with ports.
Publishing is blocked by an empty port
Cause. An output port exists but carries no data assets. An empty port would appear in the Data Market as a delivery promise with nothing behind it.
Fix. Attach at least one asset to every output port. If a port is a placeholder you no longer need, delete it instead of leaving it empty.
Publishing is blocked by an unwired input port
Cause. An input port has no upstream source. Input ports record where your product reads from, so an unwired one is an unfinished dependency.
Fix. Wire the input port to the upstream product’s output port, or delete it if the dependency no longer exists. A product with no input ports at all passes this check.
An asset is missing from the port
Cause. The asset already belongs to another data product. A product cannot re-expose another product’s data, so the asset is left out of the port’s asset table on the wizard’s Ports step. It still appears on the Data Assets step, where the CONTAINED IN column names the product that holds it.
Fix. Consume it instead of republishing it. Add an input port pointing at the upstream output port, which records the dependency and keeps the upstream owner accountable for their data. If you believe the asset is in the wrong product, talk to that product’s Owner rather than working around it — see Data product anti-patterns.
An asset cannot be added to a port
Cause. The port’s technology is set by the first asset attached to it, and every other asset must match. A BigQuery port cannot also carry a Power BI report.
Fix. Create a second output port for the other technology. This is deliberate: one technology per port keeps each port’s delivery format, contract, and access model consistent for consumers.
A contract cannot be attached to a port
Cause. Each output port can be covered by only one data contract.
Fix. Remove the existing contract from the port before attaching a different one, or reuse the contract that is already there. One contract can cover several ports that share the same guarantees. See Data contracts.
The product does not appear in the Data Market
Cause. Either the product has not reached production, or its visibility restricts who can see it.
Fix. Check the workflow state first — Save For Later parks a product in announcement, which is not published. If the state is correct, check the visibility setting on the Basics step. See The data product lifecycle.
The domain does not appear in the wizard
Cause. The Space you selected has no Data Product Standard application, or the domain has not been created yet.
Fix. Add the application to the Space, then create the domain. The wizard only lists Spaces that have the application, and only domains that already exist — it does not create either for you.
Wizard progress seems lost
Cause. You left the wizard before finishing.
Fix. Reopen it. The wizard autosaves your progress and offers to resume the draft or start over. Choose Resume draft to continue where you stopped.
A proposal link discards my draft
Cause. You opened the wizard from a data product proposal link. What you can recover depends on which of these happened:
- You had an unfinished draft, then opened the proposal link. The proposal replaced it immediately: there’s no Resume draft dialog, because opening the link is itself your answer to resume or start over. The replaced draft is gone.
- You reloaded or navigated away before touching the loaded proposal. The wizard drops the proposal from the address bar as soon as it loads, and only starts saving a draft once you edit something or select Save for later. With neither done, reopening the wizard gives you an empty form, not the proposal. Open the original link again to reload it.
- You reopened the same link later, after working on something else. Proposal links are never deleted, so it still works, but reopening it re-applies the proposal and discards whatever draft you built up since. Treat the link as a one-time starting point, not a bookmark.
Fix. See Open the wizard from a data product proposal for the full walkthrough.
The OSI YAML option is missing from the export dialog
Cause. There is one OSI format, OSI YAML, and the Export objects dialog offers it only where a data product can be reached. When the export covers a whole application or space, the option appears only if that application or space is set up to hold an object type marked as a data product. When the export covers a single object — its detail page, or its row menu in the left panel — that object’s own type must be the data product type. Two surfaces never offer an OSI export at all: a dashboard or page that belongs to neither an application nor a space, and the Download objects dialog on the space header.
Fix. Run the export from an application set up for data products, such as the Data Product Standard application. When you export a single object, select a data product. Excel, Word, and PDF stay available regardless. See Export a data product as OSI YAML for the full walkthrough.
The export failed saying nothing was exported
Cause. The message Nothing was exported — none of the selected objects is a Data Product with exportable tables. means every selected object was skipped. An object is skipped when it is not a data product, or when it is a data product whose output ports were all skipped — and an output port is skipped when no tables are attached to it. The notification reports the outcome only. Which objects and output ports were left out is recorded against the export task in Settings > General > Task log — open the task and read the Message column.
Fix. Select at least one data product, and attach the tables it publishes to its output ports. See Working with ports. An empty output port also blocks publishing, so fixing the port clears both. See Export a data product as OSI YAML for the full walkthrough.
The OSI export fails on the specification version
Cause. The configured be.module.object_export.settings.osi_spec_version breaks the rule for the version identifier: 1–64 characters using only digits, letters, dot, hyphen, plus and underscore. The export fails with OSI specification version '<value>' is not usable: expected 1-64 characters from [0-9A-Za-z.-+_]. In practice the value comes from an environment variable, because the Settings field applies the same rule before saving. A value that satisfies the rule exports successfully, whatever version it names.
Fix. An administrator sets a valid value in Settings > General > Features, under OSI export, in the OSI spec version field. 0.1.1 is the default and the version Snowflake’s SYSTEM$CREATE_SEMANTIC_VIEW_FROM_OSSIE_YAML procedure accepts. The field cannot be left blank, so type the value in full. When an environment variable supplies the value, Settings refuses to save and the change has to be made in the deployment configuration.
Prevent most of these
The blocks above cluster at two moments: leaving draft and publishing. Both are checkable in advance — running through the Pre-publish checklist before you start the review step catches the enforced rules while they are still cheap to fix.
If a block does not match anything here, the product’s Completeness panel on the review step lists what is missing, and each item links back to the step that owns it.