Merge pull request #190999 from MicrosoftDocs/release-preview-purview-workflows

Release preview purview workflows--Scheduled release at 4AM of 3/10

Author: huypub

articles/purview/catalog-permissions.md

@@ -5,7 +5,7 @@ author: viseshag
 ms.author: viseshag
 ms.service: purview
 ms.topic: conceptual
-ms.date: 11/22/2021
+ms.date: 03/09/2022
 ---
 
 # Access control in Azure Purview
@@ -28,6 +28,7 @@ Azure Purview uses a set of predefined roles to control who can access what with
 - **Data readers** - a role that provides read-only access to data assets, classifications, classification rules, collections and glossary terms.
 - **Data source administrator** - a role that allows a user to manage data sources and scans. If a user is granted only to **Data source admin** role on a given data source, they can run new scans using an existing scan rule. To create new scan rules, the user must be also granted as either **Data reader** or **Data curator** roles.
 - **Policy author (Preview)** - a role that allows a user to view, update, and delete Azure Purview policies through the policy management app within Azure Purview.
+- **Workflow administrator** - a role that allows a user to access the workflow authoring page in the Azure Purview studio, and publish workflows on collections where they have access permissions.
 
 > [!NOTE] 
 > At this time, Azure Purview Policy author role is not sufficient to create policies. The Azure Purview Data source admin role is also required.
@@ -45,8 +46,9 @@ Azure Purview uses a set of predefined roles to control who can access what with
 |I need to enable a Service Principal or group to set up and monitor scans in Azure Purview without allowing them to access the catalog's information |Data source administrator|
 |I need to put users into roles in Azure Purview | Collection administrator |
 |I need to create and publish access policies | Data source administrator and policy author |
+|I need to create workflows for my Azure Purview account | Workflow administrator |
 
-:::image type="content" source="media/catalog-permissions/collection-permission-roles.svg" alt-text="Chart showing Azure Purview roles" lightbox="media/catalog-permissions/collection-permission-roles.svg":::
+:::image type="content" source="media/catalog-permissions/catalog-permission-role.svg" alt-text="Chart showing Azure Purview roles" lightbox="media/catalog-permissions/catalog-permission-role.svg":::
 >[!NOTE]
 > **\*Data source administrator permissions on Policies** - Data source administrators are also able to publish data policies.
 
@@ -58,7 +60,7 @@ When an Azure Purview account is created, it starts with a root collection that
 
 Sources, assets, and objects can be added directly to this root collection, but so can other collections. Adding collections will give you more control over who has access to data across your Azure Purview account.
 
-All other users can only access information within the Azure Purview account if they, or a group they're in, are given one of the above roles. This means, when you create an Azure Purview account, no one but the creator can access or use its APIs until they are [added to one or more of the above roles in a collection](how-to-create-and-manage-collections.md#add-role-assignments).
+All other users can only access information within the Azure Purview account if they, or a group they're in, are given one of the above roles. This means, when you create an Azure Purview account, no one but the creator can access or use its APIs until they're [added to one or more of the above roles in a collection](how-to-create-and-manage-collections.md#add-role-assignments).
 
 Users can only be added to a collection by a collection admin, or through permissions inheritance. The permissions of a parent collection are automatically inherited by its subcollections. However, you can choose to [restrict permission inheritance](how-to-create-and-manage-collections.md#restrict-inheritance) on any collection. If you do this, its subcollections will no longer inherit permissions from the parent and will need to be added directly, though collection admins that are automatically inherited from a parent collection can't be removed.
 
@@ -102,7 +104,7 @@ Similarly with the Data Curator and Data Source Admin roles, permissions for tho
 
 ### Add users to roles
 
-Role assignment is managed through the collections. Only a user with the [collection admin role](#roles) can grant permissions to other users on that collection. When new permissions need to be added, a collection admin will access the [Azure Purview Studio](https://web.purview.azure.com/resource/), navigate to data map, then the collections tab, and select the collection where a user needs to be added. From the Role Assignments tab they will be able to add and manage users who need permissions.
+Role assignment is managed through the collections. Only a user with the [collection admin role](#roles) can grant permissions to other users on that collection. When new permissions need to be added, a collection admin will access the [Azure Purview Studio](https://web.purview.azure.com/resource/), navigate to data map, then the collections tab, and select the collection where a user needs to be added. From the Role Assignments tab they'll be able to add and manage users who need permissions.
 
 For full instructions, see our [how-to guide for adding role assignments](how-to-create-and-manage-collections.md#add-role-assignments).
 

articles/purview/concept-workflow.md

@@ -0,0 +1,95 @@
+---
+title: Workflows in Azure Purview
+description: This article describes workflows in Azure Purview, the roles they play, and who can create and manage them.
+author: nayenama
+ms.author: nayenama
+ms.service: purview
+ms.subservice: purview-data-catalog
+ms.topic: conceptual #Required; leave this attribute/value as-is.
+ms.date: 03/09/2022
+ms.custom: template-concept
+---
+
+# Workflows in Azure Purview
+
+[!INCLUDE [Region Notice](./includes/workflow-regions.md)]
+
+Workflows are automated, repeatable business processes that users can create within Azure Purview to validate and orchestrate CUD (create, update, delete) operations on their data entities. Enabling these processes allow organizations to track changes, enforce policy compliance, and ensure quality data across their data landscape.
+
+Since the workflows are created and managed within Azure Purview, manual change monitoring or approval are no longer required to ensure quality updates to the data catalog.
+
+## What are workflows?
+
+Workflows are automated processes that are made up of [connectors](#workflow-connectors) that contain a common set of pre-established actions and are run when specified operations occur in your data catalog.
+
+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.
+
+Workflow [actions](#workflow-connectors) include things like generating approval requests or sending a notification, that allow users to automate validation and notification systems across their organization.
+
+Currently, there are two kinds of workflows:
+
+* **Data governance** - for data policy, access governance, and loss prevention. [Scoped](#workflow-scope) at the collection level.
+* **Data catalog** - to manage approvals for CUD (create, update, delete) operations for glossary terms. [Scoped](#workflow-scope) at the glossary level.
+
+These workflows can be built from pre-established [workflow templates](#workflow-templates) provided in the Azure Purview studio, but are fully customizable using the available workflow connectors.
+
+
+## Workflow templates
+
+For all the different types of user defined workflows enabled and available for your use, Azure Purview provides templates to help [workflow administrators](#who-can-manage-workflows) create workflows without needing to build them from scratch. The templates are built into the authoring experience and automatically populate based on the workflow being created, so there's no need to search for them.
+
+Templates are available to launch the workflow authoring experience. However, a workflow admin can customize the template to meet the requirements in their organization. 
+
+## Workflow connectors
+
+Workflow connectors are a common set of actions applicable across all workflows. They can be used in any workflow in Azure Purview to create processes customized to your organization. Currently, the available connectors are: 
+
+- **Approval connector** – Generates approval requests and assign the requests to individual users or Microsoft Azure Active Directory groups. 
+
+    Azure Purview workflow approval connector currently supports two types of approval types: 
+    * First to Respond – This implies that the first approver’s outcome (Approve/Reject) is considered final. 
+    * Everyone must approve – This implies everyone identified as an approver must approve the request for the request to be considered approved. If one approver rejects the request, regardless of other approvers, the request is rejected.
+
+- **Task Connector** - Creates, assigns, and tracks a task to a user or Azure AD group as part of a workflow.  
+
+- **Send Email** – Sends emails as part of a workflow.
+
+## Workflow scope
+
+Once a workflow is created and enabled, it can be bound to a particular scope. This gives you the flexibility to run different workflows for different areas/departments in your organization.
+
+Data governance workflows are scoped to collections, and can be bound to the root collection to govern the whole Azure Purview catalog, or any subcollection.
+
+Data catalog workflows are scoped to the glossary and can be bound to the entire glossary, any single term, or any parent term to manage child-terms.
+
+If there's no workflow directly associated with a scope, the workflow engine will traverse upward in the scope hierarchy to determine closest workflow, and run that workflow for the operation.  
+
+For example, the AdatumCorp Purview account has the following collection hierarchy: 
+
+Root Collection > Sales | Finance | Marketing
+
+- **Root collection** has the workflow _Self-Service data access default workflow_ defined and bound.
+- **Sales** has _Self-Service data access for sales collection_ defined and bound.
+- **Finance** has _Self-Service data access for finance collection_ defined and bound.
+- **Marketing** has no workflows directly bound. 
+
+In the above setup, when an access request is made for a data asset in Finance collection, the _Self-Service data access for finance collection_ workflow is run. 
+
+However, when a request access is made for a data asset in Marketing collection, _Self-Service data access default workflow_ is triggered. Because there are no workflows bound at the Marketing scope, the workflow engine traverses to the next level in the scope hierarchy, which is Marketing's parent: the root collection. The workflow at the parent scope, the root collection scope, is run.
+
+## Who can manage 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 these workflows to the collections they have access to. 
+
+A Workflow admin defined for any collection can create approval workflows for the business glossary. In order to bind the glossary workflows to a term you need to have at least [Data reader permissions](catalog-permissions.md).
+
+## Next steps
+
+Now that you understand what workflows are, you can follow these guides to use them in your Azure Purview account:
+
+- [Self-service data access workflow for hybrid data estates](how-to-workflow-self-service-data-access-hybrid.md)
+- [Approval workflow for business terms](how-to-workflow-business-terms-approval.md)
+- [Manage workflow requests and approvals](how-to-workflow-manage-requests-approvals.md)
+