Design > Designing Processes > Adding Process Steps
  

Adding Process Steps

Add steps to access data, services, and perform related orchestration activities.
When you add a step, you also define properties for that step.
Perform one of the following tasks to add a step to a process:

Assignment Step

Use the Assignment step to set a value to a field. To create an Assignment step, click a process, and then select Assignment from the Design canvas. Then, from the Assignments properties panel, click the Add icon to assign Name and Assignment values.
The following image shows an Assignment step:
You can view an Assignment step with five fields.
To add a field, click the Add icon, and then add the following information for each field:
Name
This is the fully-qualified field name. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Assignments
This is the source from which the field takes values. The fields you see depend on the data type you defined under Start > Properties > Input Fields or Temporary Fields.
For example, if you define the data type in the Input Fields as Date or Time, the following options appear for that field in the Assignment step:
If you define the data type as Integer or Text, you see the following options to specify the value of the field:
For more information about data types, see Using the Field Properties Dialog.

Service Step

When you add a Service step, you set some properties.
The following sections describes the Service step properties:

General

Property
Description
Step Type
The Service step.
Name
A descriptive name for the service. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.

Service

Property
Description
Service Type
The connection, process, or system service you add to the process. Select from a list of existing tasks.
Note: You must have an existing item to add to a process. You cannot create a task in when you create a process.
For more information about the list of supported actions for system service, see System Service Actions.
When you add a service to a Service step, corresponding Input Fields are created.

Input Fields

Input Fields section shows the names of input fields that are most often used when using this kind of step. For Service steps that create objects, the input fields shown are the fields that are most frequently needed when the object is created. (If you do not need a field and it is optional, you can delete it.) You can choose additional (optional) input fields from the list.
Use the delete icon to remove a field. This removes input fields that you do not want to pass to the Service step. Some fields are required and cannot be deleted.

Fault Handling

Fault handling in Process Designer is based on the Business Process Model and Notation (BPMN) 2.0 specification, which defines the concept of a boundary event. The boundary events catch faults associated with specific steps, rather than the overall process scope. This means you can handle faults at the step level, not the process level. (Developers can also use Process Developer to define a fault handler on the process scope.)
Visibility of Faults in Application Integration Console
When fault handling is enabled in a process, you can view the error marker on the step and some basic fault information in the Application Integration Console Processes list.

Timer Events

Use Timer Events to perform an action based on a schedule. You can specify whether you want the event to run At specific time or After a delay.
The following image shows a configured timer event:
You can view the timer set for Service 2 to run 45 minutes after Service 1.
Select Interrupting if you want the timer to interrupt the Service step. When you set an interrupting timer, the Service Step task is interrupted and the process only runs the task on the timer set

Message Events

Specify messages for use with message providers and correlation. You can add multiple instances of the same message event to the Service step.

Subprocess Step

A Subprocess step embeds one process within another process. When the Subprocess step executes, the embedded process executes.
When you have a process that contains numerous steps, consider splitting the orchestration logic across multiple smaller processes. You can then simplify the design by using the Subprocess step to embed the smaller processes in the parent process. This not only leads to modular design, but also helps with faster loading when you open the process for editing.
The Subprocess step name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
You can define the Input and Output associated fields for the Subprocess step, if any, based on the embedded process.
The following image shows the JMS Dequeue subprocess properties:
You can view the input and output associated fields for the JMS Dequeue subprocess.

Iteration Rule

The iteration rule applies when the selected process in the Subprocess step has the Applies To field set to an object type.
You can configure the subprocess to run on a single object or on all objects in a specified list.
If you select Run on a single object, the subprocess runs on the specific object it receives as input. When execution completes, the subprocess passes control to the step that follows in the subprocess.
If you select Run on each object in list until, you also choose an event that controls the subprocess execution.
You can select one of the following values to define the event that controls the subprocess execution at run time:
The following image shows the iteration rule properties:
You can view the Iteration Rule where the Run on each object in list until option is set to End of list, and On Object List is set to Field.

Human Task Step

Use the Human Task step to include a human decision within an Application Integration process. A human action is required for approvals and exception management. For example, you might want to add a Human Task step to a loan approval process.
To include a human task into a process, drag and drop the Human Task step from the palette to the canvas. Double-click the Human Task step and select the human task that was created in the human task asset.
The following image shows a Human Task step within an Application Integration process:
The following table describes the properties that you can configure in a Human Task step:
Property
Description
General
The name of the Human Task step.
Human Task
Select the human task that you want to include within the Application Integration process. The tab displays all the settings that were defined in the human task asset such as the task description, task priority, input fields, output fields, and assignments. The tab also displays whether the task is skippable or not.
Assignments
Select from the asset, field, or formula options corresponding to the Task Role field and assign a value to the field. By default, the Asset option is selected and the users and roles that were configured during task creation are retained. You can use the Field or Formula option to override the users and roles that were defined in the human task asset.
For more information, see Overriding assignments in human tasks.
Input Fields
Enter the values in the input fields for the human task.
Outcomes
Displays a list containing the outcomes that you defined in the human task asset.
Fault Handling
Select the Catch Faults option to enable fault handling for the Human Task step. You can provide a name for the fault handler in the Fault Field Name field.
For information about creating a Human Task asset, see Human Task creation .
Note: The Human Task step is available for preview. Preview functionality is supported for evaluation purposes but is unwarranted and is not supported in production environments or any environment that you plan to push to production. Informatica intends to include the preview functionality in an upcoming release for production use, but might choose not to in accordance with changing market or technical circumstances. Note that if you are working on a preview POD, all data is excluded from SOC 2 compliance coverage. For more information, contact Informatica Global Customer Support.

Overriding assignments in human tasks

When you use a Human Task step in a process, you can override the users and roles that were defined in the human task asset using a formula or field. You can also use the Expression Editor to create simple expressions that only contain a field or complex expressions that include nested functions.
To override the assignments, perform the following steps:
    1Click the Assignments tab.
    The tab displays the users and roles that were defined in the human task asset.
    2Click the Value From field to select the asset, field, or formula. Perform one of the following steps:

Create Step

Use the Create step to add new object instances. For example, if you work with an Account object, you can use the Create step to add a new account.
The Create step name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
The following image shows a Create step for the Account object:
You can view the input fields for the Salesforce account object.
To create new objects:
  1. 1Choose the Input Fields tab and select all the fields that you will be adding to the object. Some are required; others are optional.
  2. 2For each field name, set its source to one of the following values: Content, Field, or Formula.

Using Reference Fields

Note that:

Receive Step

A Receive step can be defined in processes that make a Service and wait for some event data before the process can continue. For example, if the order process includes a step to request more credit information when the order is above a certain threshold, then a Receive step allows you to handle the blocking receive call.
The Receive step name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
The output of a Receive step is available to be used later in the process, similar to output fields in Service steps.
For the Correlation Assignments, select the fields you are correlating with the incoming message event. You can use these assignments to cancel further execution of a request (interrupting) or to provide status (non-interrupting).
For more information, refer to: Correlated Message Events

Wait Step

When you add a Wait step, you set some properties.
The following table describes the Wait step properties:
Property
Description
Name
The name of the Wait step. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Wait
Properties that determine when and for how long the process pauses. You can choose from the following options:
  • - At a specific time
  • - After a wait period

Pause at a specific time

Select this option to pause the process at a particular time. Enter the Time you want the process to pause at, and optionally, a Delay. The Delay value can be an integer or a field that you define.
The following image shows the At a Specific Time option:
For example, set the process to pause at 1:00 am after three days. 1:00 am is the Time and three days is the Delay.

After a wait period

Select this option to pause the process after a period. The period begins when the process reaches the Wait step. Enter the Wait Period that you want the process to pause for. The Wait Period value can be an integer or a field that you define.
For example, set the process to pause for one hour from the time that the process reaches the Wait step.
The following image shows the After a wait period option:

Milestone Step

Use the Milestone step to specify one of two actions when the process ends.
The following image shows a Milestone step:
The image shows the Ending Type set to Milestone: Send a Synchronous Response, HTTP Status, and a HTTP response header
You can configure the following Milestone step properties:
Name
Displays the name of the milestone step. You can edit this value.
Ending Type
You can select one of the following values:
Milestone: Send Synchronous Response
Sends a synchronous reply to the original request. The reply has all the output fields defined in the Process Properties dialog. If a synchronous reply was already sent, no action occurs. This is not an error as it allows background and batch work to occur. You can have additional steps after a Milestone step to send a synchronous message, and then continue executing.
Note: If you insert a Milestone step into a Parallel Paths step, the Ending Type field must be set to Milestone: Send a Synchronous Response.
End of Process
No further action occurs when the process ends.
The default value is Milestone: Send Synchronous Response.
HTTP Status
Displays the HTTP response status code. The default value is 200 OK. You can edit this value.
HTTP Response Headers
Specifies the HTTP response headers and values that the REST API associated with the process must return after the process runs.
For example, you can configure a response header to return the organization ID. You can consume the header value that the process returns in downstream applications.
You can configure a response header to return a lookup value. Based on the lookup value that the process returns, you can make a decision and perform further processing in downstream applications.
You can configure the X-XSS-Protection HTTP response header to enable additional security for a REST API in various browsers.
Enter X-XSS-Protection as the header name and 1; mode=block as the value.
The X-XSS-Protection header enables cross site scripting (XSS) filtering. If the browser detects an XSS attack, it will not render the page.
You can add multiple response headers to the process by configuring the name and value for each header. The header name must be unique and cannot contain the following characters:
( ) < > @ , ; \\ / [ ] ? = { } _
The header name must also not contain non-English characters. If you want to provide a non-English character in the header value, you must encode the text in the Base64 format. The downstream application must decode the text to get the original content. You can add the values manually or enter a formula.
A process uses the following default HTTP response headers:
You cannot override the names and values of the default headers.
After the process runs, the API returns the HTTP response headers that you configured. You can view the response headers on the My Processes page in Application Integration or on the Processes page in Application Integration Console.

End Step

An End step indicates the end of the process. When execution reaches this step, the process completes.
You can configure the following End step properties:
Name
Displays the name of the end step. You can edit this value.
Ending Type
You can select one of the following values:
Milestone: Send Synchronous Response
Sends a synchronous reply to the original request. The reply has all the output fields defined in the Process Properties dialog. If a synchronous reply was already sent, no action occurs. This is not an error as it allows background and batch work to occur. You can have additional steps after a Milestone step to send a synchronous message, and then continue executing.
If you set the value as Milestone: Send a Synchronous Response, you see an option to select the next step.
End of Process
No further action occurs when the process ends.
The default value is End of Process.
HTTP Status
Displays the HTTP response status code. The default value is 200 OK. You can edit this value.
HTTP Response Headers
Specifies the HTTP response headers and values that the REST API associated with the process must return after the process runs.
For example, you can configure a response header to return the organization ID. You can consume the header value that the process returns in downstream applications.
You can configure a response header to return a lookup value. Based on the lookup value that the process returns, you can make a decision and perform further processing in downstream applications.
You can configure the X-XSS-Protection HTTP response header to enable additional security for a REST API in various browsers.
Enter X-XSS-Protection as the header name and 1; mode=block as the value.
The X-XSS-Protection header enables cross site scripting (XSS) filtering. If the browser detects an XSS attack, it will not render the page.
You can add multiple response headers to the process by configuring the name and value for each header. The header name must be unique and cannot contain the following characters:
( ) < > @ , ; \\ / [ ] ? = { } _
The header name must also not contain non-English characters. If you want to provide a non-English character in the header value, you must encode the text in the Base64 format. The downstream application must decode the text to get the original content. You can add the values manually or enter a formula.
A process uses the following default HTTP response headers:
You cannot override the names and values of the default headers.
After the process runs, the API returns the HTTP response headers that you configured. You can view the response headers on the My Processes page in Application Integration or on the Processes page in Application Integration Console.

Throw Step

You can use a Throw step to construct an error payload.
The following table shows the properties in a Throw step:
Property
Description
Name
Required. A descriptive name for the Throw step. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Code
Required. A string value that contains the name of the faultInfo payload.
Detail
Optional. A string value that contains the faultInfo detail.
Reason
Optional. The faultInfo reason detail, which can be type $any.

Loop Step

A Loop step runs the steps configured within the loop until a certain condition is satisfied.
The following table describes the properties in a Loop step:
Property
Description
Name
The name of the Loop step. The name can contain only alphanumeric characters, hyphens (-), underscores (_), spaces, and Unicode characters.
Loop
Properties that determine the steps to run within the loop until a certain condition is satisfied. You can select one of the following options:
  • - While
  • - Repeat Until
Type
You can select one of the following options:
While
In the While loop, the process enters the loop only if the loop condition is satisfied. The While loop executes an activity repeatedly until its condition evaluates to false.
In contrast to the Repeat Until activity, the While loop might not execute the contained activity at all.
Repeat Until
In the Repeat Until loop, the process enters the loop but exits only when the loop condition is satisfied. The Repeat Until loop executes an activity repeatedly until its condition evaluates to true.
In contrast to the While activity, the Repeat Until loop executes the contained activity at least once.
Looping Criteria
You can select one of the following options:
Formula
You can create a condition using an XQuery function. You can also evaluate simple and complex expressions directly in the Loop step with no dependency on the prior steps.
Field
Select an input field, output field, or temporary field from the list of fields.
Enter the condition and value that you want the Loop step to base the step execution on.
The conditions available depend on the field you select.
For example, if you select a field of type Simple > Number, the following conditions are available:
You can enter a value against the condition you select.
Note: You must set an initial value for the fields used in the loop condition. Otherwise, the loop becomes infinite.

Loop step example

You create a Loop step with the following properties:
Type: While
Looping Criteria: Field with value temp
Condition: Less than with value set to 5
You have a temp field with the initial value set to 1, and the temp field is configured to increment by 1 using the Assignment step within the Loop step.
The following image shows the While option with the looping criteria set to field in the Loop step:
The image shows the While loop with the looping criteria set to field in the Loop step.
In this case, when you run the process, the subprocess runs four times until the temp value reaches 4, and then the process comes out of the loop and runs the subsequent steps.
For the same process, if you create a loop with the following properties:
Type: Repeat Until
Looping Criteria: Formula with $temp.temp >5
The following image shows the Repeat Until option with the looping criteria set to formula in the Loop step:
The image shows the Repeat Until loop with the looping criteria set to formula in the Loop step.
In this case, when you run the process, the subprocess runs five times until the temp value reaches 5, and then the process comes out of the loop and runs the subsequent steps.

Rules and guidelines for using Loop step

Consider the following rules and guidelines when you use the Loop step in a process:
Note: The loop construct feature is available for preview. Preview functionality is supported for evaluation purposes but is unwarranted and is not supported in production environments or any environment that you plan to push to production. Informatica intends to include the preview functionality in an upcoming release for production use, but might choose not to in accordance with changing market or technical circumstances. Note that if you are working on a preview POD, all data is excluded from SOC 2 compliance coverage. For more information, contact Informatica Global Customer Support.

Decision Step

A Decision step allows a process to take different paths depending on the value of the field.
The following table describes the properties in a Decision step:
Property
Description
Name
The name of the Decision step. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Decision
The process takes a decision based on the fields and paths you define here.
Select a field name from the list of fields you define under Start > Fields.
Enter conditions and values that you want the Decision step to base a decision on.
The conditions available depend on the field that you select.
For example, if you select a field of type Simple > Text, the following conditions are available:
  • - Equals
  • - Starts With
  • - Ends With
  • - Starts with any of
  • - Contains
You can enter text values against the conditions you select.
You can add multiple conditions to a Decision step. Each condition is a potential data path.
For each path that you add, a corresponding branch appears on the UI. Drag branches to rearrange the order in which the branches appear on the UI.
Most Decision steps have an Otherwise path. This path handles execution if no data meets the conditions in your tests.

Evaluating Paths

A process evaluates conditions based on the criteria you specify. Ensure that you construct paths with non-intersecting conditions.
For example, you create a Data Decision step with the following paths:
If the integer field for which the Data Decision step was created has a value of 25, the Data Decision step takes path 1. This is because 25 is less than 100 and path 1 is the first option.
To ensure that the Data Decision step follows the "Field less than or equal to 25" path, re-create the paths with the following criteria:
Important: The process evaluates conditions in a top-down manner. Ensure that the Otherwise branch is the last path.
A Decision step can lead to another Decision step. For example, a branch could run if an annual income exceeds $100,000. The next decision test along the same path could test if the city is Boston, or otherwise. Using this technique, you use Boolean AND logic because you base the test for the second condition on the true branch of the first condition. In this example, you use the Decision step to set the condition "Annual Revenue exceeds $100,000 AND city is Boston".
Similarly, to support Boolean OR logic, you can add a test for the second condition on any branch.

Parallel Paths Step

When you add a Parallel Paths step, you set some properties.
The following table describes the properties in a Parallel Paths step:
Property
Description
Name
The name of the Parallel Paths step. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Parallel Paths
The paths that you want the process to run in parallel.
Note: When you use a Parallel Paths step, all the steps in all the branches will not start at the same time. There will be a time lag in the start time of the steps in all the paths. The execution of branches varies based on the steps used in each branch.
When more than one branch is running in sequence, if one branch pauses for a specific time, instead of waiting for the steps to complete in that branch, the process starts running steps from another branch in parallel. For example, if you have a Wait step in a branch and the process is paused for a specific time, the steps in a different branch starts running in parallel.
Click Add to add a new branch.
You can add multiple steps to each branch. To add steps to a branch, drag and drop a step from the pallette on the left.
When you use the Jump step in conjunction with the Parallel Path step, you can only jump to another step on the same Parallel Path branch.
Keep in mind the following restrictions when you use the Jump step and the Parallel Path step together:
  • - If you are in a Parallel Path step, you cannot jump to a step on another branch of the same Parallel Path step.
  • - If you are in a Parallel Path step, you cannot jump to any step outside the Parallel Path step.
  • - If you are outside a Parallel Path step, you cannot jump to any step inside the Parallel Path step.

Jump Step

When you add a Jump step, you set some properties.
The following table describes the properties in a Jump step:
Property
Description
To
The target of the jump. Select from a list of available steps.
More than one step can jump to the same target step. To see how many Jump steps have a particular step as their target, place the cursor over the arrow next to the target step.
When you use the Jump step in conjunction with the Parallel Path step, you can only jump to another step on the same Parallel Path branch.
Keep in mind the following restrictions when you use the Jump step and the Parallel Path step together:
  • - If you are in a Parallel Path step, you can't jump to a step on another branch of the same Parallel Path step.
  • - If you are in a Parallel Path step, you can't jump to any step outside the Parallel Path step.
  • - If you are outside a Parallel Path step, you can't jump to any step inside the Parallel Path step.
  • - You can't jump to any step from the fault path. You must merge the fault path back to the main process path to add the Jump step.
  • - You can't jump to a step inside the fault path if you are outside the fault path.
Use the following best practices when you use the Jump step in a process:
  • - Instead of using a Jump step from an outside flow to a step inside the fault path, design the process by replacing the Jump step with the same flow as in the fault path.
  • - If you use a Jump step for iteration purposes and it points to a Service or a Subprocess step with fault handling, enclose the Service or Subprocess step with fault handling inside another Subprocess step.