Imagine you are a data analyst assigned with the job to generate a report on ‘Q4 Profit and Loss’ for your organization. To do this, you need access to ADLS blob storage, Oracle tables as well as Snowflake views. Now these data sources are managed by different teams, data owners and IT Admins in your organization, and you must reach out to them individually to get access. Also, in some cases data access might require approvals from multiple business owners, and you are responsible for reaching out to them, getting approvals, and providing all that supporting documentation to IT Admins/DBA’s to get data access.
The above process is manual, error prone and causes a lot of frustration to data consumers. How much easier would it be for a data consumer to just go into a tool, click on ‘Request access’ and not worry about the process on who the approvers are, how to get approvals and who the IT Admins/DBAs are for various sources to grant them access? This is where Azure Purview streamlines the entire process by allowing a workflow to be defined to manage self-service data access to improve speed, automatic approvals, and efficiency for all the data sources scanned and populated in Azure Purview.
Last November, we released Azure Purview’s policy capability. The above workflow also interacts with policy store for sources Azure Purview’s policy features support to create self-service policies automatically once all the business approvals are met so that IT Admin/DBA don’t have to do anything.
For sources not supported by Azure Purview’s policy capability, a task can be created as part of workflow for IT Admins/DBA’s to provide access. This is completely transparent to data consumer who is requesting access and Azure Purview becomes a one stop shop where all the data access requests can be submitted, tracked, and managed for your entire data estate.
To get started with self-service data access workflow creation experiences, Azure Purview provides a request data access templates which can be used as is by just populating the user ids or AAD groups in approval and task actions or you can customize the template to suit your organizational needs.
Once you have defined a workflow, you can bind it to a collection. The workflow engine always triggers the workflow directly applied to a collection when a request to access data is made for any asset in that collection. If no workflow is directly applied to the collection, the workflow engine travels upwards in the hierarchy path to find a nearest workflow applied either to collection’s parent or even higher level in collection hierarchy. This allows you to define a default workflow at a higher level and override the same with a different workflow at a lower level in collection hierarchy.
Manage Requests and Approvals
A user who has either assigned an approval action to approve or reject a data access request or a task action to complete data access request can view them in Azure Purview Studio. In addition to viewing these requests in Azure Purview Studio, they also get emails to act on these requests.
Who can create self-service data access workflows?
A new role ‘Workflow Admin’ is being introduced with workflow functionality. A ‘Workflow Admin’ defined for a collection can create self-service workflows and bind to the collection they have access to.
How to trigger self-service data access workflows?
A data consumer can click on ‘Request access’ button in asset details of Azure Purview’s asset details page to trigger a workflow to get access to the data.
Learn more by reading the docs on Azure Purview Workflows