In Blindata Marketplace, a Provider plays a central role in managing data product accessibility. Providers are designated users responsible for evaluating and responding to data access requests submitted by Consumers. This responsibility includes reviewing the purpose and scope of each request, ensuring alignment with organizational data governance standards, assigning access levels appropriately, and revoking previously granted permissions when necessary.

Providers also serve as stewards of the data products they oversee, maintaining metadata and documentation, and ensuring that data products remain understandable, reliable, and governed throughout their lifecycle.

Understanding the Provider Role and How Permissions Work

Being a Provider is more than simply having the ability to approve or reject requests—it is a responsibility within the broader data governance framework. Providers act as gatekeepers, balancing the need for data accessibility with the imperative of regulatory compliance, risk management, and data security.

A user is considered a Provider for a data product when both of the following criteria are met:

1. They are assigned a responsibility (e.g., owner, steward, approver) for the data product via Blindata’s Stewardship Model.
2. They possess the appropriate system permission, namely the MARKETPLACE_EDITOR role, which authorizes interaction with access requests.

There are two setup steps required to enable users to act as Providers in Marketplace:

1. Assign Data Product Ownership – Clearly define responsibility for each data product and assign it to the appropriate user.
2. Map Roles in Marketplace Settings – Configure the user’s role in Marketplace Settings to align with their assigned responsibilities.

Once both of these are done, any user with the designated responsibility for a data product and the MARKETPLACE_EDITOR permission will be able to see and manage access requests for that data product directly within the Marketplace module.

For a full breakdown of role permissions and configuration, refer to the Marketplace Configuration guide .

Finding Requests That Need Your Approval

Once configured, Providers are automatically notified whenever an access request targets one of their assigned data products. These notifications ensure timely response and minimize the risk of delayed approvals.

When a request is submitted, Providers receive an in-app alert and, optionally, an email notification (depending on system notification settings). Notifications include a direct link to the request detail page for immediate review.

In addition to notifications, you can view all pending requests awaiting your approval on the marketplace list page. Click the Pending My Approval button to see all requests that are awaiting your review. This toggle will automatically apply the necessary filters to view all requests that have been submitted and that you have not approved or denied yet.

How to Approve an Access Request

Once you open the Access Request Detail Page, you will be presented with a comprehensive overview of the access request submitted by a Consumer. This includes all the metadata associated with the request, such as the data product being requested, the justification provided by the Consumer, and any custom metadata fields required by your organization (e.g., cost center, intended usage).

If you are recognized as a Provider for the requested data product—meaning you have both the required responsibility assignment and the MARKETPLACE_EDITOR permission—the Review button will be visible in the interface. This button initiates the formal approval workflow. Users who lack either the required permission or the relevant responsibility will not see this button and therefore cannot proceed with the review process.

Clicking Review launches a guided approval flow, which is designed to ensure that access decisions are made in alignment with your organization’s data governance policies and stewardship framework. This workflow is composed of two sequential steps:

1. Review Access: Initial approval or denial of the request

   

At this stage, you should carefully examine all relevant information associated with the request. This includes:

• General information about the Access Request (name, start/end date, requester user, etc.)
• Specific Ports of the data product being requested
• Consumer Justification detailing the reason for the access request
• Required Custom Metadata: These are additional fields that your organization has configured to capture important contextual information about each access request. Custom metadata can include a wide range of attributes, such as the intended usage of the data (e.g., analytics, reporting, machine learning), the business justification for the request (explaining why access is needed and how it aligns with organizational goals), project or cost center identifiers to facilitate tracking and auditing, expected duration of access, data sensitivity classification, or any other information your governance policies require. Reviewing these fields is crucial, as they provide the necessary context to assess whether the request is appropriate, compliant, and aligned with both business and regulatory requirements.

After evaluating the request in full, you must choose one of two possible outcomes:

• Approve: Click Save to record your approval decision and return later to complete the access granting process, or click Next to proceed immediately to the second step, Grant Access, and finalize the access delivery to the Consumer.

• Deny: If the request lacks sufficient justification, violates policy, or is otherwise not acceptable, you may deny it. In this case, your only available action is to click Save, which updates the status of the request to reflect its rejection and ends the approval flow for this request.

Once you have saved your decision—whether approval or denial—the Consumer will receive a notification detailing the outcome.

2. Grant Access: Complete the access granting process

   After reaching the Grant Access step, you will be able to complete the actual grant process. This can be achieved in two different modalities: Manual Grant or through the DataOps Platform, as explained in detail in the next section.

How to Grant Access

Once the access request has been approved, you will enter the Grant Access phase. You can access this step immediately after approving the request by clicking Next in the approval modal, or later by selecting the Grant action from the Provider section of the access request detail page.

There are two distinct ways to grant access, depending on your organization’s operational model and the level of automation available in your environment:

1. Manual Grant

This approach is suitable for organizations that manage access provisioning manually or through separate systems. In this mode, you confirm that access has already been granted through external processes, and Blindata simply records this state for auditing and notification purposes.

A list of all requested ports will be displayed. Review the list and select the ports for which access has been successfully provisioned through your external systems or manual procedures.

After saving, the selected ports will have their status updated to Granted, and the Consumer will receive a notification indicating that access has been granted.

2. Automated Grant via DataOps Platform

For organizations that have implemented a fully integrated access management workflow, the Platform Grant option enables you to trigger access provisioning directly from Blindata using the Marketplace Executor integration. This approach allows Blindata to interact with external systems—such as data platforms, identity and access management (IAM) tools, or ticketing systems—to execute the actual access provisioning for the requested ports.

In the Grant Access modal, you will need to select the Agent and the corresponding Platform that will process the request. Blindata will then submit the access instructions through the configured integration.

Once the grant process is initiated, the status of the selected ports will be updated to subscribed. As the system receives responses from the integrated platform, each port’s status will be updated to reflect the actual outcome—such as successful provisioning or any encountered errors. Additionally, each port will display a status message that provides clear context, including confirmation of access or details about any issues.

All relevant users, including both the Provider and the Consumer, will automatically receive notifications summarizing the results of the grant operation.

How to Revoke Access

Access revocation is an essential part of the data lifecycle, allowing Providers to remove access when it is no longer required or when circumstances change. The revocation process is a critical control mechanism that helps maintain data security and compliance with data governance policies.

The revocation process consists of two main steps:

1. Revoke the Access Request

To initiate the revocation process, locate the access request you wish to revoke and click the Revoke button (which replaces the Review button for approved requests). This will open the revocation modal where you can:

• Review the current status of the request
• Choose to either:
  • Save: Immediately update the request status and notify the Consumer
  • Next: Proceed to the port revocation process

2. Revoke Port Access

Similar to the grant process, you can revoke port access in two ways:

1. Manual Revocation

   For organizations managing access through external systems:

   • Select the ports for which access has been revoked through your external processes
   • Confirm the revocation by clicking Save
   • The system will update the port statuses and notify all relevant parties

   

2. Automated Revocation via DataOps Platform

   For organizations with integrated access management:

   • Select the appropriate Agent and Platform
   • Submit the revocation request
   • The system will process the revocation through the configured integration
   • Status updates and notifications will be sent automatically

   

After the revocation process is complete, the access request status will be updated to Revoked, all affected ports will show their new status, and the Consumer will receive a notification about the revocation.

What Happens When a Consumer Unsubscribes

When a Consumer unsubscribes from a data product, the Provider receives a notification. It is then the Provider’s responsibility to manage the revocation of access to the associated ports.

This process follows the same pattern as the standard port revocation flow: You can either manually revoke access to the ports or submit a revoke request to the platform using the automated workflow, using the same modal used in the revoke process.

Once the revocation is processed, the status of each port will be updated accordingly, and the Consumer will receive a notification confirming the result.

All Notifications Received by the Provider

This is a reference list of all notifications that are sent to the Provider during the lifecycle of an Access Request:

Event	Description
New Access Request	Notification sent when a Consumer submits a new access request for a data product you manage.
Consumer Unsubscribe	Notification sent when a Consumer unsubscribes from a data product, requiring you to handle port access revocation.
Platform Response	Notification sent after the external service completes processing a port grant or revocation request. This notification details the result for each port (granted, denied, error, or revoked). Each port will also display a clear status message with additional context, accessible from the access request details page, next to the status.