This documentation supports the 18.08 version of Service Request Management.

To view the latest version, select the version from the Product version menu.

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:

  1. Associate processes and AOTs with the PDT. 
  2. 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.


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.


  • 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. 

Creating a standard PDT - Quick start

Create a standard PDT in the Process View of the Service Catalog Manager Console by completing the following steps:


Create a new PDT from the Service Catalog Manager Console.

  1. From the IT Home Page, open the Service Catalog Manager Console.
  2. Click Console Focus in the left navigation pane, and click Process.
  3. Click Create.
2Define basic information for the PDT.
  1. In the Process Details tab, specify a name, description, and company for the PDT.
    The company can represent internal groups or business units as well as external vendors or customers. If you select Global , any user (including guests) can access the PDT.
    Note: PDTs can be used in a multi-tenancy environment.

  2. From the Request Type list, select Standard.

Use the Visual Process Editor to associate an application object or process to the PDT, and to arrange the process flow.

  1. Click the Process Details tab if it is not already in view.
  2. To add processes to the Visual Process Editor workspace, drag and drop PDT, AOT, or condition objects from the Palette.
    When designing your PDT, you can mix and match any combination of nested PDTs, AOTs, or condition objects for a standard SRD. 
    The objects are activated in the visual sequence displayed in the workspace:
    • 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.
  3. To rearrange PDTs, AOTs, and conditions, select the object in the workspace and drag it to its new level or position.


    You cannot drag a condition to a new position if an AOT, PDT, or other condition is connected to at least one of its branches. Instead, you must delete the condition and create a new one.

  4. To delete an object, right-click it, and select Delete Shape.


    If you delete a condition, any AOTs, PDTs, and nested conditions in the branches of the condition are also deleted. You will not receive a confirmation, and you cannot undo the action.

4Define variables.
  1. Select an AOT or PDT in the Visual Process Editor workspace.
  2. Click the Define Variables panel (at the bottom right).
  3. In the Define Variables area, define the names, description, and default value of the variable.
  4. Select the process input type (Process Input, Process Output, or Internal). See Variables and their use in standard PDTs.
    You use these to specify the direction of your variables. The Internal type is used to pass data between PDTs in the process diagram. You cannot map questions to Internal variables.
    Select Process Input if you want to map the variable to a question when creating an SRD.
  5. For Process Input variables, if you require data be entered for this variable (by users answering a question, through a mapping, or through a default value), select the Input Required check box.
  6. Click Add.
    You can modify or remove these variables as needed. You can also view their usage.
5Define properties for the AOT and PDT objects.
  1. Select an AOT or PDT in the Visual Process Editor workspace.
  2. In the Name field of the Define Properties panel, select an AOT or PDT from the menu.
  3. Verify the read-only information in the remaining fields, such as the fulfillment application and template to make sure that you selected the correct AOT or PDT.
  4. To allow users to view the status of the process from the Request Entry console, select Show in simplified view.
  5. Click Apply to show the object name in the process workspace.


    Adobe has announced the end of development and distribution of Flash Player by the end of the year 2020. For more information, see and For Adobe flash in Remedy Open link .

6Define properties for conditions.
  1. Select the condition object in the Visual Process Editor workspace.
  2. In the Name and Description fields, enter a name and description for the condition.
  3. In the Condition field, enter a qualification that the condition will evaluate.
    You can use variables that you created for the PDT. Click the ellipsis button (...) to open the Condition Builder and create the condition.
  4. Click Apply.

Map the direction of the data flow.

See Dynamic data flow: Passing data between fulfillment applications.

When you map the direction of the data flow, you can, for example, specify that the data from one variable is passed to another variable.

  1. Select an AOT or PDT in the Visual Process Editor workspace.
  2. Click the Map Data panel (at the right).
  3. In the table on the Map Data panel, select one of the fields that you exposed in the AOT. (The fields come from the fulfillment application.)
  4. If you want to enter data into the field on the fulfillment application, select a variable from the Input field.
    The data from the variable will be entered into the field on the fulfillment application.
  5. If you want field data from the field on the fulfillment application pushed to another AOT or PDT, select a variable from the Output field.
    You can enter variables in the Input and Output fields. For example, an input variable might enter data into a Cube Number field, but if the fulfillment provider changes the data in that field on the fulfillment application, the data can be passed on to the next process steps (AOT) through the Output variable.
  6. Click Apply.
  7. Click Save.
8Define general details and save the PDT.

In the General Details tab, define the following:

  • (Optional) End User Displayed Name — name that you want to be displayed to the end user if it is different from name in the Name field. This name is displayed in the Process View of the Request Entry form.
  • Category — select a category from the menu, for example, Generic. You can also enter a new PDT category (for example, BMC Change Management, BMC Incident Management, or Work Order). After you save the PDT, you can select these categories from the Category menu. If multi-tenancy is enabled, not all categories are available to all managers.
  • Status (for example, Active)
  • (Optional) Version number.

For information about the Work Info area on the General Details tab, see Tracking work on a PDT.

For information about the Used By area on the General Details tab, see Checking the use of this PDT by other PDTs or SRDs.

Related topics

Was this page helpful? Yes No Submitting... Thank you