A Note About Workflows And Process Execution 

Recall that MDM workflows can be triggered by various events, such as adding, updating, or importing a record. However, such event-driven process execution has its limitations, and is effective only in very simple circumstances, when such events all trigger the same simple process.

Unfortunately, in most scenarios, the process flow depends very much on the type of update or the business intent of the change. For example, changing a product description may simply require approval from a copy editor, but changing the price may require the record to be approved and then distributed to a downstream system.

In the example, two very different processes must be chosen as a result of a single type of event. Moreover, as the number of variations increases, building these decisions into a single workflow that is triggered by a change event will likely result in excessively complex and difficult to manage process logic.

An alternative to the event-driven approach is patterned after SAP’s transaction model, where the user chooses the process to follow (that is, the particular transaction) before making any changes to the data. This ensures that the correct downstream steps take place without any ambiguity for the user or complex decision logic within the process.

Within MDM, the transactional approach can be modeled by displaying a list of available workflows from which the user must choose before any modifications to the records take place. So for the example, the user would choose from the “Update Descriptive Information” workflow or the “Modify Price Structure” workflow before making the change.

This transactional approach is not only an effective substitute for event-driven execution but also a superior model, resulting in two very different processes managed by two distinct workflows and making clear to the user what will happen as a result of each action.