The Data Market is where the data products published in the Data Product Standard application become available to everyone in your organization. It works as a self-serve marketplace: consumers discover products, evaluate their terms, and request access in a governed way. This page covers how discovery works, what a product shows, and how access is requested.
Discovering data products
After a data product is documented and published, it appears in the Data Market for the whole organization to browse. From there, consumers can:
- Discover data products across Spaces, without knowing in advance which team owns them.
- Search by platform or technology — for example, every product that uses a specific cloud platform.
- Open a product to review its terms and request access in a structured, governed way.
The market makes trusted data discoverable and reusable, so a team can adopt an existing product instead of rebuilding the same data. Each listing shows the product’s description and value proposition, and surfaces its output ports and input ports and its owner. The Data Market can also surface relevant products in a recommended section.
Only products in the Production workflow state appear in the Data Market. A product still in design or development stays hidden until its owner publishes it. For how this workflow tracks a product’s lifecycle, see What are data products.
What a product shows
Opening a product shows what it delivers and on what terms, so a consumer can judge fit before requesting access. Each product presents:
- Its purpose and value proposition — what the product is for and who benefits from it.
- Its output ports — how the product’s data is delivered to consumers.
- Its data contract and terms — the schema and the agreement covering use.
- Its pricing plan and license — the cost model and the usage rights.
These four together let a consumer decide whether to request the product, without contacting its owner first.
Products and individual assets
The Data Market supports two ways to get the data a consumer needs:
- A whole data product — the recommended unit, because the product carries its own ownership, contract, and terms.
- An individual data asset — where the owner allows it, a consumer can request a single data asset that a product contains.
A raw data asset on its own does not carry the data contract, service-level agreement (SLA), or terms that make data safe to depend on. The data product does.
To get the full schema and not just the underlying data, a consumer should request the whole data product rather than an individual asset.
Requesting access
Access to a data product is requested, not taken. Reading a product’s terms carefully before requesting is worth the few minutes — an access request commits your team to the product’s license and usage terms, and switching sources later costs far more than checking now.
Find a product
Browse or search the Data Market across the organization. You do not need to know which team owns the data you want. Three approaches narrow a large market:
- Search by subject — the terms you would use for the data itself, such as churn, revenue, or inventory.
- Filter by domain — when you know the business area that would own it, such as Marketing or Finance.
- Filter by technology — when your use case constrains the platform, such as needing data already in BigQuery.
If two products look similar, the value proposition is the field that distinguishes them: it states who each product is for.
Evaluate before you request
A product listing carries everything you need to judge fit. Check these six things before requesting access.
| What to check | Why it matters | What good looks like |
|---|---|---|
| Workflow state | Only a product in production is safe to build on | Production — not draft, development, or sunset |
| Owner | Your route for questions, changes, and incidents | A named person, not a service account |
| Data contract | Tells you the schema and terms before you read a row | Present, active, and covering the port you need |
| Service levels | Whether the freshness and availability fit your use case | Explicit freshness and availability figures |
| Quality checks | Evidence the data is tested, not just described | At least one check, on a dimension you care about |
| License and pricing | What your team is agreeing to | Terms your team can accept |
Two states deserve particular attention. A product in sunset is scheduled for retirement — building on it means planning a migration you have not scheduled yet. A product with no contract may still be fine for exploration, but you have no agreed schema, so a change upstream can break you without warning.
The contract’s schema is the most useful part of the listing. It lists the fields, their types, and what they mean, which lets you confirm the product answers your question before you have access to any data.
Submit the request
Submit an access request against the published product and include a justification. State three things:
- The use case — what you will do with the data.
- The level of access — how much you need, rather than everything available.
- The duration — how long you need it.
Dawiso routes the request to the product’s approver and records both the grant and the reason behind it. The underlying data platform enforces the permission on the data itself, so approval and enforcement stay connected. Requesting the narrowest access that covers your use case is usually approved fastest, because it gives the approver less to weigh.
After approval
Once access is granted, you consume the data through the product’s output port. What you agreed to is the contract: its schema, its service levels, and its usage terms.
Two habits protect you from surprises. Depend on the port and its documented schema rather than on the underlying tables, since the producer can change what sits behind the port without breaking their promise to you. And watch for version changes on the product — a MAJOR version means something you rely on may have changed. See Versioning and breaking changes.
If the product does not fit
Contact the Owner. A product that almost fits is often a product whose owner has heard the same request before, and asking is cheaper for both teams than building a parallel copy. Three requests are reasonable to make:
- A field you need is missing. Adding an optional field is a backward-compatible change for the producer.
- The freshness does not meet your need. The owner can tell you whether a tighter SLA is feasible.
- You need a different delivery format. This is usually a new output port rather than a change to an existing one.
If you are building a data product of your own on top of this one, do not copy the data. Consume the output port through an input port on your product. That records the dependency, so the upstream owner can see you as a consumer before they change anything.