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 to discover products, what a listing shows, and how to request access.
Discover 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.
Review a product listing
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.
Choose a product or an individual asset
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 doesn’t 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.
Request 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 don’t 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 |
Watch for two states. A product in sunset is scheduled for retirement. Building on it means planning a migration you haven’t scheduled yet. A product with no contract may still be fine for exploration, but you don’t have an agreed schema. A change upstream can therefore 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. This 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.
Gate (the external access-management service Dawiso integrates with) has its own approval policy. For a product where Gate grants access, the duration you receive follows that policy, not Dawiso’s cap on the requested period. Gate may approve a shorter duration than you asked for.
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.
If checkout uses Gate
When your organization grants access through Gate (the external access-management service Dawiso integrates with), clicking Checkout opens a dedicated Checkout page instead of a dialog.
The Checkout page opens with a Request details panel. It collects why you need access, the use case, and the duration once, shared across every product below. One card then covers each product in the cart:
| Field | What it covers |
|---|---|
| Ports | Which ports the request covers. All offered ports are selected by default, so leaving them all checked requests the whole product. |
| Personal data access | Masked access (the default), unmask basic PII, or unmask sensitive PII with a choice of which protected categories to unmask. |
| Row-scope limit | An optional switch, shown only when Gate requires the request to be limited to a subset of rows, such as your own business unit. |
| Existing access | A notice on the card when you already hold access to some or all of the selected ports. For example, blocking a duplicate request or offering to extend what you already have. |
| Outcome | A live preview of what Gate would grant: immediate access, access after approval, awaiting an approver, blocked, or no preview available. Includes the approvers, the validity period, and the contacts. |
A product you can no longer see in Dawiso, or that Gate no longer holds, shows as blocked. It can’t be requested here, and the card instructs you to remove it from the cart. An approver step still waiting for someone to hold the role shows as Not assigned.
A summary panel counts the products by outcome and holds the single Submit all button. The button stays disabled while any card is blocked, and states the reason. A card with no port selected is one example of a blocked card. The button stays enabled, with a warning, when the Gate integration itself can’t produce a preview.
After you submit, a banner reports the created requests with a link to My Access.
| Outcome | What happens |
|---|---|
| Created | Opening My Access expands the product with its new request rows carrying a New label. The same happens when a request only appears after My Access refreshes. |
| Partially succeeded | The product stays in the cart, and the banner explains which items were rejected and why. Only the created part becomes a request, so only that part is tracked under My Access. The rejected part is visible solely in the banner. |
| Failed entirely | The product stays on the Checkout page with the reason shown, so you can adjust it and submit again. |
For the other checkout targets (JSM and ServiceNow), the dialog is unchanged, except it no longer offers a protection-level (sensitivity) picker.
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.
Follow two practices:
- Depend on the port and its documented schema rather than on the underlying tables. The producer can change what sits behind the port without breaking their promise to you.
- Watch for version changes on the product. A MAJOR version means something you rely on may have changed. See Versioning and breaking changes.
Troubleshooting
If a product almost fits your needs
Contact the owner before building a parallel copy. A product that almost fits is often one other consumers have asked about before, so the owner may already be considering the change you need. 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 doesn’t 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’re building a data product of your own on top of this one, don’t 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.