Access to a data product in the Data Market 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.
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.
The Use case options can be customized: an administrator can designate an object type whose objects (sorted by name) populate the list instead of the built-in options. The field stays optional with no value preselected; if the configured list is empty, no options are shown. The selected use case is saved with the request for Gate, or passed to the ticket for JSM or ServiceNow. If the customer package also defines the has_checkout_use_case relation type between the data product and use case item types, checkout creates that relation too.
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. The panel also has two optional fields that apply to the whole order, not to each product:
| Field | What it covers |
|---|---|
| Link to supporting document | A link to a document that supports your request. It must be an absolute address starting with https:// and can have at most 2048 characters. Spaces around the link are ignored, and an upper-case HTTPS:// is accepted. |
| Access to set up | Free text describing the access you need set up. It can have at most 4000 characters, and a counter shows how many you have used. A value with only spaces counts as empty. |
Leaving both fields empty doesn’t block Submit all; the request then carries neither.
| Problem | What happens |
|---|---|
| Link isn’t a valid absolute address | Field shows Enter an absolute address starting with https://. |
| Link exceeds 2048 characters | Field shows Link can be at most 2048 characters. |
| Text exceeds 4000 characters | Field shows Text can be at most 4000 characters., the counter turns red, and your text stays in place. |
In each case, the summary panel tells you to fix the field, and Submit all stays disabled until you do.
If the server refuses the link or the text anyway, it refuses the whole order and sends nothing. The page shows a message such as The link to the supporting document must be an absolute https:// address. Nothing was sent. The form stays editable, so you can correct it and submit again.
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. Hidden when every selected port is on a source that cannot mask columns. |
| 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. Hidden when every selected port is on a source that cannot filter rows. |
| 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, noting a request still in progress, or offering to extend what you already have. The notice also appears when you selected several ports and only some of them are affected. |
| Outcome | A live preview of what Gate would grant: immediate access, access after approval, awaiting an approver, set up by an administrator, blocked, or no preview available. Includes the approvers, the validity period, and the contacts. The approver can differ per output port: Gate uses the port’s own Business Owner if it has one (see Working with ports). |
Some sources, for example an external source such as EDH Hive, cannot mask columns or filter rows. When every port you selected is on such sources, the Personal data access and row-scope sections are hidden. On a product with ports on several sources, they stay and show the note “Applies only to ports on sources that support column masking.” (and the matching note for row filtering). Selecting or clearing ports updates this at once.
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.
For ports on an external source, Gate doesn’t grant access itself, so no masking is promised. The card shows a grey Set up by administrator chip and the summary panel has a Set up by administrator row with a count. The outcome reads one of:
- “No approval needed. A platform administrator sets up your access.”
- “After approval, a platform administrator sets up your access.” (the card badge then stays Awaiting approver until then)
A product split across sources shows one outcome row per source, labeled with the connection name (for example “EDH Hive”); the external part reads “A platform administrator sets up access to these ports.”
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.
See Tracking your data product access requests for what happens to a request after you submit it.
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.