Approval Workflow

Managing the approval of access requests.

Access agreements represent the edges in the data mesh graph. They are the basis for granting access or revoking access to the actual data in the data platform. On approval, the access is granted, and on deactivation, the access is revoked. Access can be requested by data consumers and needs to be approved or rejected by data owners.

Entropy Data offers three ways to manage the approval of access requests:

No Approval Workflow

For uncritical data, no approval workflow is necessary. A data consumer simply gets the data they need, without the data owner having to approve manually.

Entropy Data supports this via the auto approve feature. When an output port has this feature enabled, all requested access requests to this output port get automatically approved. Additionally, in the special case of sharing data within a team, the access request gets automatically approved as well, regardless whether the feature is enabled of the output port.

In any case, an access resource is always created, and the data consumer has to provide a reason why they want to use the data. This is necessary to create lineage between the data products.

Organization owners can also switch auto approve on for every access request in the organization under Settings → Auto Approve. The same setting is the autoApprovePolicy field (always, or absent for the default rules) of GET/PUT /api/organization/features, so it can be applied to another instance together with the other organization features, see Sync Environments.

Simple Approval Workflow

For confidential and restricted data, an approval workflow is necessary. A data consumer requests access to the data they need, and the data producer approves or rejects the request.

Entropy Data supports a simple approval workflow in the web UI. After an access request has been requested by the data consumer, the owner of the providing data product can approve or reject the request within the web UI of Entropy Data.

Approval is a single step. Everyone on the providing team whose role holds the ACCESS_APPROVE permission can approve or reject (by default the Owner, Approver and Steward roles), and the same roles held on a domain above the team count too, so several people can be given the task. Whoever acts first decides, and the audit trail records who. New requests are emailed to the members of the providing team who can approve them. Multi-step processes, delegation to a named person, and escalation live in your workflow system and connect through the external approval workflow below.

The rules that should govern such a decision can be written down as governance policies. Before the owner decides, Data Governance AI checks the request against those policies and the terms of use of the data contract, and shows any potential violation next to the Approve and Reject buttons. The decision itself always stays with the owner.

External Approval Workflow

In many companies, there might already exist a complex approval workflow in a dedicated system.

Entropy Data supports the integration of an external approval workflow via its REST API. The access would still be requested in Entropy Data, but this would trigger an AccessRequestedEvent in /api/events which should start the approval workflow in the external approval system. The external approval system can add a link to where the current decision is being made back to Entropy Data adding to the access resource by updating the REST resource (/api/access/$id). Once a decision has been reached in the external approval system, the access can be approved or rejected via the appropriate API calls (/api/access/$id/approve and /api/access/$id/reject) to Entropy Data, including additional metadata about the decision.

Reach out to support if you need customized integration with your external approval system.

Approval and actual access

Whichever workflow decides, an approval only records that the consumer should have the data. The grant in the data platform is created by provisioning, and by default the consumer sees the access as granted as soon as it is approved. If every grant in your organization is reported back, you can let provisioning grant access instead, so the consumer sees a pending access until the grant really exists.