The following tables describe and list the properties of the process definition objects.

Event reference

Process definition includes the following event references.

SymbolNameDescriptionProperties
Generic Start Event(default) Process initial state.
  • Name
  • ID
  • Input Type
    • Alert (default)
    • Resource
  • Add Custom Input (optional)
    Select or deselect the Add Custom Input toggle.
    Click + to add custom input fields.
Timer Start EventProcess initial state. Transition to the next process step is triggered by a time event.
  • Name
  • ID
  • Start Date
  • Ends
    • Never
    • AfternumberOfOccurrences
    • On
  • Recurrence Pattern
    • Minute
    • Hourly
    • Daily
    • Weekly
    • Monthly
  • Repeats Every
Signal Start EventProcess initial state. Transition to the next process step is triggered by an alert, incident, or resource signal event.
  • Name
  • ID
  • Signal type:
    • Alert
    • Incident
    • Resource
  • Signal event:
    • Created
    • Updated
  • Filter Criteria Start event condition. Example: $attribute1Name =
Timer Intermediate Catch EventPuts the process on hold until the specified time or duration. Transition to the next process step is triggered with the elapse of time or duration.
  • Name
  • ID
  • Time Definition Type:
    • Duration
    • In - Enter the duration.
    • Select
      • Days
      • Hours
      • Minutes
      • Seconds
  • Time

    Select the time in 24 hour format.

Timer Boundary EventEnables the task to complete within the specified duration. If the task is not completed within the duration, the process moves to the next step.
  • Name
  • ID
  • Duration
  • In - Enter the duration.
  • Select
    • Days
    • Hours
    • Minutes
    • Seconds
End EventProcess end state.
  • Name
  • ID

Task reference

You must define one of the following task types.

SymbolNameDescriptionProperties
Send TaskSends an email notification to the specified users, user groups, or rosters.
In the Message Recipient field, click Add/Modify to find the recipients.
The recipient list is displayed based on the login authentication such as partner or client.
  • Name
  • ID
  • Input
  • Message Recipient
  • Notification Template
  • Notification Priority
    • VERY_LOW
    • LOW
    • NORMAL (default)
    • HIGH
    • URGENT
Script TaskRuns an agent-based script or agentless script using the Ansible control node.
The agent-based task can be implemented using a Python, PowerShell, or shell script.
See Ansible Integration to learn more about Agentless script tasks.
  • Name
  • ID
  • Platform
    • Agent (default)
    • Agentless
  • Script Name
  • Resource ID
  • Run As
    • Default user (default) Use the user of the agent service for execution.
    • Other users Use the credential assigned to the resource.
Service TaskRuns an external, REST API, local platform, and utility service.
User TaskA user task models work that requires human intervention. When the task runs, a new service desk entity task is created and is displayed in the assignee/assignee group task list.
In the Assignee Group field, click Add/Modify to select the assignee group. In the Assignee field, click Add/Modify to select the assignee.
The assignee/assignee group is displayed based on the login authentication such as partner or client.
The workflow transitions out of the user task and to the next stage On receipt of a Closed or Resolved indication from the service desk entity.
Any properties you define in Setup > Service Desk > Custom Forms are also displayed here as additional properties.
  • Name
  • ID
  • Subject
  • Description
  • Priority
    • Low
    • Normal
    • High
    • Urgent
    • Very Low
  • Due Date
    • In
    • Interval
      • Days
      • Hours
      • Minutes
      • Seconds
  • Assignee Group
  • Assignee

REST Web service tasks

The REST web service task calls an external API.

OptionDescription
NameEnter a name for the REST web service task.
IDThe ID is populated automatically.
ServiceSelect the REST Web Service task from the drop-down.
Asynchronous Service Invocation (optional)Select or deselect the toggle.
An asynchronous service invocation follows the Request, Acknowledge, and Callback pattern. Once invoked, the process is put on hold on this task until the REST application calls back.
IntegrationSelect - Choose a custom integration from a list of previously created integrations.
Only the selected custom integration is triggered during the process workflow.
To create a custom integration for Process Automation, see the How to Set up a Process Automation Integration section.
EventSelect - Choose a custom event from a list of previously created events.
Only the selected custom event integration is triggered during the process workflow.
To create a custom event for Process Automation, see the Configuring the integration section.
InputEnter the input. To provide multiple inputs for different tasks, enter the multiple inputs separated by commas.
For example, $StartEvent_1bedsev.alert, $Create_SR, $Create_INC

Note: The input value provided must be the same as the option selected in the On field in the Configuring the event section in How to Set up a Process Automation Integration section.

See the Input examples section for information about providing input values.

- If the event type set is to "Alert" we can configure all properties related to alert and resource along with resource custom attributes from the tokens section to the payload.
- If the event type is set to "Resource" we can configure all properties related to resource along with resource custom attributes from the tokens section to the payload.

Input examples

On field Integration EventREST Web service Input fieldInput Example
ResourceResource$taskId.alert.resource, $taskId.resource
AlertAlert$taskId.alert
TaskTask$taskId.task
IncidentIncident$taskId.alert.incident, $taskId.incident
Json ObjectJson Object$taskId

Platform service tasks

The following platform service tasks are available for the task reference service task:

Platform Service TaskDescription
Close AlertCloses an alert using the alert ID.
Create/Update AlertCreates and updates an alert.
The Create/Update Alert lets you customize the alerts that are inbound through the integrations.
By configuring a custom process definition for an integration, you can customize the incoming alerts according to the properties defined in the process definition.
Enter the attribute values. The input text here is provided as an example:
  • Subject - $StartAlert.alert.subject
  • Alert State - $StartAlert.alert.currentState
  • Metric Name - $StartAlert.alert.metric
  • Alert Source - $StartAlert.alert.alertSource

  • Note:
    • When you enter a value in the Alert Source field to create a Process Definition and if the given value is a valid source, then an alert is created with the same source value.
    • When you enter a value in the Alert Source field to create a Process Definition and if the given value is an invalid source, then an alert is created with the default source value as OPSRAMP.
    • When you create a Process Definition by keeping the Alert Source field empty, then an alert is created with the default source value as OPSRAMP.


  • Component - $StartAlert.alert.component
  • Resource Name - Enter the resource name or uuid.
    $StartAlert.alert.resource.name or $StartAlert.alert.resource.uuid
  • Description - Process definition for Integration

This process definition is available for selection in the Enrich and Create Alert section while creating custom integrations.
See the Configure the custom integration for webhook section to learn more about the Enrich and Create Alert option.
Find AlertsFinds a list of alerts that match a PromQL query string.
Find ResourcesFinds a list of resources that match a PromQL query string.
Get AlertGets an alert using the alert ID.
Get IncidentGets an incident using the incident ID.
Heal AlertHeals an alert using the alert ID.
Post Alert CommentPosts a comment using the alert ID.
Set Alert PrioritySets an alert priority using the alert ID.
Update IncidentUpdates the following incident attributes using the incident ID.
  • Priority
  • Status
  • Assignee Group
  • Assignee
  • Response

Utility service task

The Parser Utility Service task parses string text into key values. This helps you to extract information from voluminous data by using custom input fields. Using the parser task, you can define the keys, validate the input string to verify the parsed text, and provide the values as inputs for the next task in a process workflow.

With the Parser task, you can parse any plain text, and also dynamic token values at runtime such as:

  • $.alert.uuid
  • $.resource.hostName

The parser task parses and returns information such as percentage, descriptions, numbers, or path values that can be used in subsequent tasks in a process workflow.

To use the parser task, do the following:

  1. Add a Service task, select Utility Service from the Service drop-down in the Configuration section.

  2. Select Parser from the Task drop-down list.

  3. Enter the value in the Input field.

    Notes

    • Enter the dynamic values using the tokens from the previous tasks, plain text, or a combination of both.
    • Input field supports Json, XML, and YAML formats.
    • Click +Add to create multiple input fields. This is optional.
  4. In the fields below the input field, define the key values and enter the text that needs to be parsed. Click + to create multiple key value fields. This is optional.

    The following input fields are available:

    • Enter Key - Enter a name for the parsed text. For example: Physical Memory % Ensure that each key name is unique.
    • Select - Select a parsing operator from the drop-down options:
      • After: Parses the text after a given input or word.
      • Before: Parses the text before a given input or word.
      • Between: Parses the text between the start and end word.
      • Pre Pend: Adds the text before a given input or word.
      • Post Pend: Adds the text after a given input or word.
  5. Click Validate to verify the parsed output.

  6. In the Validation pop-up that appears, enter the input in the field and click Validate. Validating the input allows you to verify the output, and also make any corrections, if required.

Example:

The following example demonstrates the validation of a plain text alert input using all the five available parsing operators.

The Physical Memory Usage on the device is 56%. The Virtual Memory Usage on the device is 43%.

The following is the parsed text result:

{  "physical memory": "The Physical Memory Usage on the device",
  "virtual memory": "43%."}

Parsing dynamic values in run time

The following example demonstrates providing dynamic values as inputs, parsing dynamic values in run time, and using the parsed values in the next task in the process workflow.

For example, the first task in the workflow is the Parser utility task and the next task is the Post Alert Comment platform service task.

Parser task

The input query for the Parser task is as follows:

Alert created # $StartEvent_10g1j00.alert.uuid on device $StartEvent_10g1j00.alert.resource.hostName. Subject: $StartEvent_10g1j00.alert.subject.

The validation response for this input is:

{
  "subject": "$StartEvent_10g1j00.alert.subject",
  "alertId": "$StartEvent_10g1j00.alert.uuid",
  "deviceName": "$StartEvent_10g1j00"
}

The subject, alertId, and deviceName parameters are the outputs of the Parser task. The actual values are replaced with tokens in the run time.

Note that the values are not yet assigned to these parameters. These are provided as inputs for the Post Alert Comment task.

Post Alert Comment task

The following parameters are provided as inputs after parsing the text:

  • Alert Id - The alert id is generated from the parser task. $Parser.alertId
  • Subject - The name of the subject is appended from the parser task. $Parser.subject
  • Device - The name of the device is appended from the parser task. $Parser.deviceName

The result of the Post Alert Comment task is as follows:

Alert Id: 24475 Subject: Testing the parser task. Device: Think-pad

Call Activity

A Call Activity is a set of tasks that is defined and executed independently from the main process definition workflow. It is a reusable process that can be called by multiple process definitions. A call activity performs the defined set of tasks by creating a new process instance, executes the task, and the main process definition continues afterwards.

Assign a call activity to a process definition

To assign a call activity to a process definition, do the following:

  1. Create a new process definition by clicking +Add.
  2. In the display canvas, enter a required Name for the process. You can enter an optional process Description.
  3. Add a start event and append a task.
  4. For the task, click the Change type and choose Call Activity.
  5. Click the task to view the task properties and enter the following:
    • Name - Enter the name.
    • ID - The ID is auto-generated.
    • Process - Select the specific process definition created for the call activity from the available list.
    • Input - Enter the input.
      When the signal input is triggered, the call activity is also triggered and performs the tasks as defined in the process selected from the Process field and moves to the subsequent tasks in the process definition.

The following is a sample process definition with call activity. The call activity is indicated by a thicker border and a + sign.

Assigning Call Activity to a Process Definition

Sub Process (expanded)

A Sub Process is a set of tasks that is defined and executed independently within the main process definition workflow. It can contain:

  • Other activities
  • Gateways
  • Events

A sub process performs a set of related tasks on its own, and the workflow moves to the next task in the main process.

The following are some of the points to remember about the Sub Process:

  • Runs only within the main process.
  • Only None start event is available.
  • Must have at least one end event.
  • The outputs of the sub process cannot be used as the inputs of the subsequent tasks.
  • Contains only the Name property. The ID is auto-populated.
  • Additional properties such as Multi-instance is available when it is defined from the previous task.

The following is a sample sub process definition:

Sample Sub Process Definition

The sample sub process definition can be explained in the following way:

  • The list_of_critical_alerts task contains a list of critical alerts.
  • The subProcess is defined within the main process definition. The task of the subprocess is to comment and close the alerts coming from the previous list_of_critical_alerts task.
  • The three vertical lines indicate that a multi-instance loop is added to the sub process. A multi-instance loop indicates that a particular task has to be performed multiple times.
    The following additional properties are available for a sub process when a loop is added:
    • Parallel Multi instance: Indicated by three vertical lines. All tasks are executed concurrently and independently from each other.
    • Sequential Multi instance: Indicated by three horizontal lines. All tasks are executed one after the other.
    • Collection: Enter the array list from the list_of_critical_alerts task. For example: $list_of_critical_alerts.alerts
    • Element Variable: Enter the variable in which the alert will be stored. For example: x So, if five alerts come through the task, each alert will be repeated. For example, the first alert is mapped to the x variable, the action is performed, and then the second alert is mapped until all five alerts go through this process.
    • Loop Cardinality: The number of times a process is iterated. Select the Number of loops from the range. If you select 3, the tasks will be iterated three times either parallely or sequentially based on the multi-instance selection.

Multi-Instance activities

A multi-instance activity is a process of defining repetition for a task in the sub process. All the following tasks can be used to define a multi-instance activity:

  • Service Task
  • Send Task
  • User Task
  • Business Rule Task
  • Script Task
  • Sub-Process
  • Call Activity

Gateway reference

Process definition includes the following gateway references.

SymbolNameDescriptionProperties
Exclusive gateway(default) Specifies conditional task execution. Use the connector symbol to specify the branching condition.
  • Name
  • ID
Parallel GatewaySpecifies concurrent task execution.
  • Name
  • ID

Connector reference

Process definition includes the following connector references.

SymbolNameDescriptionProperties
Sequence FlowConnects two components in a directed, sequential workflow.
  • Name
  • ID
Default FlowConnects two components in a conditional workflow. Default processing continues in the direction of this connector if the specified condition is not satisfied.
  • Name
  • ID