For example, activating a phone line for a new employee might require that the application create the fulfillment requests for the following processes in the specified order:
- Verifying the employee's specific details
- Searching for an available phone number to assign
- Ordering the phone
- Activating the line
- Testing the line
- Scheduling an appointment for a technician, if necessary
- Notifying the employee that the service is active
How standard PDTs work when a user requests a service
When a user submits a request, if the PDT is created as a series of fulfillment requests (for example, change requests), fulfillment providers can perform some tasks in parallel. Some tasks might need to be performed in a strict sequence, and some tasks might be conditional.
When PDTs and AOTs run in parallel, the application simultaneously creates one request (for example, a change request to order a phone) and another request (for example, a change request to search for an available phone line). The fulfillment providers can work on these requests at the same time. To create a request for ordering a phone, you can design a PDT that creates one request to verify the employee's specific details and another to search for an available phone line to assign. These two requests can be performed in any order.
When the PDTs and AOTs run in a strict sequence, the application activates the first request (for example, the change request to order a phone is assigned a change request ID). The second change request is activated only after the first change request is completed. The assignee must complete the first change request before the second assignee can start testing the phone line. In turn, both these requests must be completed before the application activates the third request to notify the employee that the phone line is active.
Important
If you create a service request that activates a sequence of fulfillment requests (for example, a series of change requests, incidents, or work orders) and then you cancel a fulfillment request that was activated, the next request in the sequence is activated. However, if you cancel the service request, the fulfillment requests are cancelled.
When the PDTs and AOTs are conditional, the flow criteria determines if the next action is executed or bypassed. For example:
- If the first change request is completed, create the second request.
- If the first change request is not approved, create an incident.
Application instances that were created for a particular service request are visible in request details.
Variables and their use in standard PDTs
Use variables to pass data from a service request to a fulfillment application, and from one fulfillment application to another. You can define variables and the process flow in a PDT, and map variables to questions and responses in the SRD that contains that PDT. For information about creating questions for SRDs, see Creating questions to use with SRDs.
If the PDT contains an AOT, any target data selected in the AOT is mapped to the variables defined in the PDT. You can map PDT variables to:
- A question in the SRD
- A service request field
- A hard coded text string that you create in the SRD
- A combination of all three options. See Concatenating multiple inputs.
Create variables using the correct Type, such as Process Input, Process Output, or Internal, to distinguish how the variable should be used within the PDT. Only Process Input types are exposed to the service request. Use internal variables to pass data between AOTs and nested PDTs. A fulfillment application should use process output variables to receive data from an AOT or nested PDT after it has completed.
See the following table to know more about the types:
| Type | Description |
|---|---|
| Process Input variables | Pass responses to questions in the service request form to the fulfillment process. Input variables can be mapped as values for Target Data fields in the process flow. For example, you can map the question "What is your first name?" in the SRD to the target data field "Requested For First Name." The requestor's response to this question will be the value of the Target Data field. You can also pass on input variables from one fulfillment process as output variables to another fulfillment process in the PDT. You can also use input variables to build conditions to drive the fulfillment process. For example, you can add a condition specifying that if the location is San Jose, then the work order must be assigned to John Doe, a member of the San Jose IT team. |
| Process Output variables | Receive target data field values from an AOT representing one fulfillment application into another AOT or nested PDT representing another fulfillment application. Output variables are typically used when a PDT contains more than one AOT. They are set when an AOT process has completed, and the data is used as input in the next AOT. For example, suppose the Notes field is passed from target data to an AOT representing the Work Order application. When a fulfillment worker updates the value of the Notes field, the updated value is passed on to another AOT representing the Change Management application. |
| Internal variables | Pass data internally between nested PDTs within a PDT. An AOT sets the variables and passes them to a nested PDT. The value can be used as input to the next AOT or fulfillment application. For example, you can pass on the employee ID. Internal variables are not exposed outside of the PDT or AOT. |
To allow branching within a process, you can add conditions to the PDT. Only variables can be used when creating the qualification for conditions.
Best practice
- When defining your input variables, provide a meaningful description of the input variable's purpose. The catalog manager uses this information when defining and mapping questions to the PDT input variable..
- When you create a PDT in the Visual Process Editor workspace, a set of validations are implemented. For more details on these validations and best practices for creating a PDT, see Guidelines and validations for creating a PDT.
