Microsoft Purview, formally called Azure Purview (see Azure Purview is generally available) has recently released a number of new cool features. I wanted to call out a few of them:
- Data Sharing – in public preview, you can now share data in-place from Azure Data Lake Storage Gen2 and Azure Storage accounts, both within and across organizations. Share data directly with users and partners without data duplication and centrally manage your sharing activities from within Microsoft Purview. You can now have near real-time access to shared data. Storage data access and transactions are charged to the data consumers based on what they use, and at no more cost to the data providers (more info). Note this is using the same technology used with Azure Data Share, except Azure Purview data sharing does not support snapshot-based sharing, only in-place sharing
- DevOps policies – DevOps policies are a special type of Microsoft Purview access policies. They grant access to database system metadata (not user data) provided the data source is enabled for Data Use Management. For example, giving a person the ability to log in to dozens of Azure SQL logical servers to monitor their performance (more info)
- Data owner access policies – In public preview, enables you to manage access to user data in sources that have been registered for Data Use Management in Microsoft Purview (data use management needs certain permissions and can affect the security of your data, as it delegates to certain Microsoft Purview roles to manage access to the data sources). These policies can be authored directly in the Microsoft Purview governance portal, and after publishing, they get enforced by the data source (more info). For example, giving a user read access to an Azure Storage account that has been registered in Microsoft Purview
- Self-service data access policies – In public preview, allows a data consumer to request access to data when browsing or searching for data, which triggers a self-service data access workflow. Once the data access request is approved, a policy is auto-generated and applied against the respective data source to grant access to the requestor, provided the data source is enabled for Data Use Management. Currently, self-service data access policy is supported for storage accounts, containers, folders, and files (more info). As an example, an end-user can be browsing folders in Purview and finds one that contains files the end-user would like to use. That person would request access to the folder through Purview, and if the access is approved, that person would be able to use a tool outside of Purview to read the files. Behind the scenes, a workflow was setup in Purview to automatically grant a user access to that folder, so nothing manual needs to be done to give access (the workflows look like Power Automate). Click here to see how the process works. The difference between “data owner access policies” (DOAP) and “self-service data access policies” (SDAP) is that DOAP is for the data owner to grant access to user data in sources, while SDAP is a way for data consumers to request access to user data in a source. So with DOAP no one is requesting access and with SDAP they are. As an example, say a DOAP is created to give five people read access to FolderA. If a sixth person wanted access to FolderA, that person would request access by creating a SDAP
- Workflows – Workflows are automated processes that are made up of connectors that contain a common set of pre-established actions and are run when specified operations occur in your data catalog. Workflow actions include things like generating approval requests or sending a notification, that allow users to automate validation and notification systems across their organization. There are two kinds of workflows: Data governance – for data policy, access governance, and loss prevention (as used in the self-service data access policies mentioned above), and Data catalog – to manage approvals for CUD (create, update, delete) operations for glossary terms (more info). For example: A user attempts to delete a business glossary term that is bound to a workflow. When the user submits this operation, the workflow runs through its actions instead of, or before, the original delete operation. The deletions could then be prevented if certain conditions are not met
- Asset Types – In public preview, you can build a metamodel by adding asset types to a canvas and defining the relationships between them. Asset types allow you to describe parts of your business that are not technical assets. It is a template for important concepts like business processes, departments, lines of business, or even products. Metamodel tells a story about how your data is grouped in data domains, how it’s used in business processes, what projects are impacted by the data, and ultimately how the data fits in the day to day of your business (more info). For example, it can help answer questions like: What department produces this dataset? Are there any projects that are using this dataset? Where does this report come from? You can define an asset type “department” and then create new department assets for each of your business departments, as well as attach existing data source assets. These new assets are stored in Microsoft Purview like any other data assets that were scanned in the data map, so you can search and browse for them in the data catalog. Metamodel includes several predefined asset types to help you get started, but you can also create your own.
The post New Microsoft Purview features first appeared on James Serra's Blog.