Dynamic data flow: Passing data between fulfillment applications

Dynamic data flow is useful when passing data between applications. For example, the first part of the new employee process is a "new employee ID" work order to your Human Resources application. Human Resources types the new employee ID into a field in the work order and marks the order complete. Next, a "new badge" work order goes to Security. The ID entered in the first work order is mapped to a field in the second work order so that Security knows which employee ID the new badge is created for.

Variables and dynamic data flow

When you set output variables from a fulfillment application, the value that is used is the internal representation of the data. For example, if you retrieve data from a selection field on the fulfillment application, the data that is stored is the selection value (not the label). When you map this data to another fulfillment application, the field to which the data is passed interprets the data and shows the data, based on the type of field you have mapped to.

The following example of a selection field clarifies how data is passed from one fulfillment application to another fulfillment application. Imagine that your application includes a Priority field with these selection labels and values: Critical = 1, High = 2, Medium = 3, Low = 4.

• If you mapped the data from this selection field to a character field on another fulfillment application, you see the selection values (1, 2, 3, 4). In this case, the data that appears is the internal representation of the data (not the selection labels that appear).
• If you mapped the data from this selection field to another selection field on the fulfillment application (which contained the same labels and values), you see the correct labels (Critical, High, Medium, Low).
• If you mapped the data from this selection field to a date field on the fulfillment application, the data appears as a date (most likely, an invalid date).

Scenario for creating standard PDTs that use dynamic data flow

The following scenario illustrates how to build PDTs that use dynamic data flow. This simple scenario creates the following BMC Service Request Management objects:

• 2 work order templates
• 1 change management template
• 1 incident management template
• 4 AOTs
• 2 PDTs

The following figure illustrates how these Service Request Management objects are used in the dynamic data flow. The Categorization Tier 1 value of a service request (its "data") serves as the input and output value for the fulfillment applications.

Dynamic data flow from SRD to PDTs

PDT flow design in the Visual Process Editor

You can drag and drop process objects from the Palette to construct the design and flow of your PDT in the Visual Process Editor. 

You can create conditional processing in PDTs by specifying the flow criteria that determines if the next AOT or PDT in the branch is executed. The Service Request Management administrator can define conditions that would determine which branches in the process flow are executed or bypassed. 

If you add a condition to the PDT, you create a decision branch in the process flow:

• If the condition passes, the PDT executes the Yes branch.
• If the condition fails, the PDT executes the No branch.

In the example, the InstallOffice AOT runs first.

• If it is successful, the PDT executes the Yes branch and the New Employee PDT is activated.
• If it is unsuccessful, the PDT executes the No branch and the Create an incident AOT is activated.
  When you specify that processes are in the same level (for example, the two AOTs), they run in parallel.
  When you drag a new node (for example, an AOT) to a row of nodes, the node is added to the beginning or end of the row.

Adding nested PDTs, AOTs, and conditions to the process