Creating a standard PDT

Standard process definition templates (PDTs) define the fulfillment process steps that occur when a user requests a service. Fulfilling a service request can involve one or more fulfillment applications. For example, a request to onboard a new employee can involve many groups such as Human Resources, IT, Security, and so on. Thus, one service request can spawn multiple fulfillment processes.

A complex PDT can contain several application object templates (AOTs) and PDTs representing multiple fulfillment processes. A PDT can also contain one or more conditions that specify when a process begins.

How PDTs are defined

Best practices

For best practices, see Guidelines for designing services.

Defining a PDT includes the following steps:

Associate processes and AOTs with the PDT.
Specify the order in which the processes and AOTs are activated.
You can order them to run either in parallel (in any order) or in strict sequence (1, 2, 3, and so on). You also add conditions to the PDT to skip sequences, for example, 1, 3, 5, and so on.

For example, activating a phone line for a new employee might require that the application create the fulfillment requests for the following processes in 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 other change requests are not yet activated, nor are they assigned change request IDs. Only after the first change request is completed does the application activate the second change request. As a result, the assignee must completely finish 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.

Note

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, 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

You use variables to pass data from a service request to a fulfillment application, and from one fulfillment application to another. You define variables and the process flow in a PDT, and you map variables to questions and responses in the SRD that contains that PDT. See Adding and mapping questions, variables, and service request fields.

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.

When you define variables, you must specify one of the following types:

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. Thus, 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.

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.

To allow branching within a process, you can add conditions to the PDT. Only variables can be used when creating the qualification for conditions.

Tips

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 defining a process with conditions, ensure that the variables that are used in the condition qualification are set prior to the evaluation of the condition qualification.