Customizing Workflows in MDM SaaS with CAI

Challenge

A common requirement in MDM implementations is providing the capability for users to review master data changes before they become effective. Workflows are the feature in all Informatica MDM SaaS offerings, including Customer 360 and Product 360, which are used to meet these requirements.

Description

MDM SaaS includes built-in workflow and custom workflow options. This Best Practice discusses the differences between these options and best practices for custom workflow implementation.

General Workflow Considerations

When planning any implementation of MDM SaaS workflows (built-in or custom), it is important to consider the following points:

• Once a record has entered a workflow, it becomes locked in pending state. There can be no changes to the record until the workflow has completed.
• Workflows are triggered by a Create, Update, Delete, Merge, or Unmerge event made by a user via the MDM SaaS UI or API.
• Workflow triggers are configured by a combination of MDM objects (business entity or hierarchy) and user roles. During configuration, specify which objects, modified by which roles, will trigger a workflow.
• Workflow tasks can only be assigned to roles, not individual users. The only exception is the Originator Task, which is directly assigned to the user who initiated the workflow.

When To Use Custom Workflows

One of the first decisions for a workflow implementation is whether to use the built-in workflows or develop custom workflows. The business requirements will determine whether the built-in workflows are sufficient.

As a general rule, it is best to use the built-in workflows if they will satisfy the business requirements for the following reasons:

1. Simplicity: Built-in workflows require only configuration. No custom development is needed to implement built-in workflows.
2. Minimal testing: Built-in workflows require minimal testing because they are a standard product feature.
3. Time-to-value: Built-in workflows can be configured in a fraction of the time required to implement custom workflows.

Custom Workflow Capabilities

Custom workflows unlock several capabilities, including the list below. If any of the following features are required in the workflow, then a custom workflow must be developed.

1. Add any number of tasks in the workflow.
2. Route tasks to different user groups based on custom logic.
3. Include parallel tasks to allow multiple roles to work on the same record at the same time. The workflow will not continue until all parallel tasks are completed.
4. Display custom page layouts for each task to show users only relevant data for each task.
5. Implement API calls to internal or third-party APIs during the workflow.

Custom Workflow Limitations

1. In the custom workflow, you can invoke an Originator Task to assign the task back to the user who triggered the workflow. However, a task cannot be assigned back to the user who completed the previous task. Instead, it must be assigned back to the role responsible for the previous task, where it can be claimed by the previous user.
2. Custom workflow is not available for manual merge tasks. Only the built-in workflows can be used for manual merge tasks.

Custom Workflow Design Phase

This section discusses the steps involved in designing the workflow implementation. All requirements and workflow designs should have business stakeholder support before development begins.

Gather Business Requirements

Workflow design discussions should begin with an understanding of the business requirements. A workflow implementation can only be successful if the workflow steps align with business processes, and the business stakeholders understand the workflow.

Begin with working sessions for business and technical stakeholders to define workflow use cases. The following questions should be answered during these sessions:

• What changes to master data are allowed through the MDM SaaS user interface and API?
• Which of these changes require an approval workflow?
• How many approvals or data entry tasks are needed before a change can be approved?
• What are the business user roles that will be involved in the approval?
• Will any of the out-of-the-box approval workflows satisfy the business requirements?
• Is there any need for parallel approval tasks?
• What actions should be available to the user on each task? For example: “Approve”, “Reject”, “Cancel” and/or “Send back to Initiator”.
• Are there any requirements to call third-party APIs during the workflow?

Align Requirements to Workflow

After the business requirements are determined, the technical workflow design can begin. Map the business process requirements to technical assets. The following steps should be completed:

• Ensure that business user groups are mapped to roles within IDMC.
• Map business approvals and data entry tasks to tasks in MDM SaaS. Assign a unique name to each task type.
• Optionally, determine the page layout for each task to ensure that each task participant has all relevant data to complete the task.
  
  

Custom Workflow Development Phase

This section describes the best practices for developing and configuring a custom MDM SaaS workflow.

CAI Workflow Development

As a best practice, it is recommended that workflow development begins with the template workflow. Locate the CAI process in the IDMC Business360 folder called “MDM Multi-Step Approval Template”. Copy this process into a new folder and modify it to develop a custom workflow.

The workflow template demonstrates several capabilities of the custom workflow, including:

• Parallel tasks
• Originator tasks
• Send back to previous tasks
• Custom decision logic for workflow routing

B360 Business Event Configuration

MDM SaaS workflows are initiated by user-triggered business events. These events can be configured for any business entity or hierarchy in the Business 360 Console.

For Business Entities, the supported event types (or scenarios) are Create, Update, Delete, Unmerge, and Manual Merge. For hierarchies, the supported event types (or scenarios) are Create, Update, and Delete.

If the Create or Update scenarios are selected for a business entity event, the event can be configured on individual fields or field groups or the entire entity. For example, it is possible to create a business event trigger only when a new address is created on an existing record.

When configuring user-triggered business events, note the following:

• If different workflows are required for different event types (create, update, delete), create separate business events for each scenario.
• If different workflows are required depending on which role initiated the event, create separate business events for each scenario.
• A CAI process must have at least one human task to be selected in a user-triggered event workflow.