This blog is one in a four-part series on workflows in the context of master data management (MDM). The term “workflow” has different meanings in different contexts. In this blog series, we frame the discussion within different levels of workflow complexity:
In this series, we will explore each of these in further detail, including the technical approaches available for implementing each in the Microsoft MDM ecosystem. We will wrap up the series with a discussion of the relationships between workflows, processes, and governance.
A worker-centric workflow provides direct feedback to data stewards when an action is required of them. This action is discrete, and does not require coordination with other activities within a larger defined process. For example, once a particular issue is corrected, a subsequent action is not immediately required. Common examples of a worker-centric process include:
- Data Quality issue identification and correction
- A listing of invalid data values that need to be corrected
- A listing of missing values that need to be populated
- Simple review and approval
- A record is new or has changed, and requires a simple review before it is approved
Worker-centric workflows are fully supported by Business Rules in Microsoft Master Data Services (MDS). Let’s explore the scenarios above in a bit more detail, including how they are implemented in MDS.
Worker-Centric Workflows Scenario #1: Data Quality Issue Identification and Correction
For a worker-centric workflow that corrects data quality issues, the primary requirements are:
- Data quality issues must be automatically detected
- Data stewards must be made aware that an action is required to correct a data quality issue
- Data stewards must have a way to view their list of issues, and take action to correct each issue
In effect, the goal for the data steward is to “tell me when something is wrong, and give me a place to fix it.”
In MDS, this is natively supported by business rules, including their ability to send notifications, and generate validation issues for users to correct. The business rules identify on an automated basis the issues that need to be corrected; send notifications to the responsible data stewards; and create a list of validation issues which are the to-do list for data stewards to work on.
In the example below, a business rule has been defined that specifies Color as a required attribute, and that Cost must be greater than zero. If we have a single product that doesn’t meet this standard, upon running business rules, the data steward is notified of the issue, and is provided a place to correct the issue.
Figure 1 - Color is Required Business Rule
Figure 2 - Product Missing Color
Alternatively, the data steward can also filter the product entity to create a list of products with validation issues. The data steward can then work to fix the issues that exist for each product.
Figure 3 - List of Products with Validation Issues
As these issues are identified, a notification email is generated, making the user aware that there are new issues that require attention. These issues can be reviewed en masse by users via Version Management in MDS, providing a comprehensive list of issues to resolve:
Figure 4 - MDS Notification Email
Figure 5 - List of Data Quality Issues
This worker-centric approach to workflows allows for data stewardship to be guided toward areas of greatest need. As a general rule, the issues are discrete issues that require attention, and are not related to one another. Scenarios where issues or activities require coordination will be explored when we discuss collaborative workflows in a subsequent post.
Worker-Centric Workflows Scenario #2: Simple Review and Approval
It is often the case that a very simple review is required when a new record is added to the master data hub. This is commonly the case with reference data sets. Continuing with the Product example, Color is a set of reference data. If a new Color is added, we may want to engage a manager to formally approve that new Color value.
This more advanced worker-centric workflow can be implemented using a couple of business rules, a status attribute, and security. In the following screenshot, a new Color has been added:
Figure 6 - Business Rules for Color Entity
Figure 7 - New Product, Cannot Be Approved by Creating User
Note that we have added an Approval Status attribute to the Color entity, and that the current user cannot edit the value of this attribute. Next, we created two business rules: the first defaults the Approval Status to “Not Approved”; the second states that if Approval Status = “Not Approved” then the Approval Status is invalid. This will generate a notification to someone who needs to review the new color and ultimately approve it.
In the following screenshot, we have logged in as a different user. This user has a notification indicating they need to perform an approval. They are able to review the corresponding color, and determine whether it is approved. If it is approved, they can change the Approval Status to “Approved”.
Figure 8 - Administrator Can Approve New Product
As you have seen, simple worker-centric workflows can be easily implemented using MDS. In the next posting, we will look at more sophisticated, collaborative workflows, which orchestrate activities between multiple users. We will also demonstrate some of the limitations of MDS’ business rules for supporting collaborative workflows, and introduce Maestro Workflow as an alternative.