Skip to main content

Set Service action

Available for event, alert, and incident workflows

This action adds to or replaces the service list of an event, alert, or incident with user-specified services.

The standard practice is to place this action after a filter in the Workflow trigger or an action such as Time Filter Action.

This action takes the following inputs:

  • Action

    Select one of the following options:

    • Replace all service names

    • Add to any service names that already exist

      Note

      New service names are always appended to the end of the existing list of services.

  • Service

    The new service names that should go into the service field list of the event or incident. You can provide the service names one of two ways:

    • Data from another field

      Pass data from another selected field in the event or incident.

    • Text

      Provide the new service names as text. Enter the name of the new service without using any quotes.

Event example

Set Service works the same way for events, alerts, and incidents. In all cases, it supplements or substitutes the list of services associated with an event, alerts, or incident with services chosen by the user.

Suppose you want to change the value of the service field for all events coming from a particular source. You can accomplish this by creating an event workflow using a Set Service action.

After setting up the Trigger to activate the workflow only for relevant source events, you can configure the Set Service action as follows:

  • Action

    • Replace all service names

  • Service

    • Text: payment

Here is an example event that was processed by this workflow:

Event fields before

Event fields after

{
    "description": "CPU spike to 80%",
    "severity": 5,
    "source": "ussf-sw99",
    "check": "cpu",
    "service": [
        "retail",
        "support"
    ],
    "tags": {
        "devicename": "sw99"
    }
}
{
    "description": "CPU spike to 80%",
    "severity": 5,
    "source": "ussf-sw99",
    "check": "cpu",
    "service": [
        "payment"
    ],
    "tags": {
        "devicename": "sw99"
    }
}
 

Alert example

Suppose that you are setting up data ingestion. After examining the structure of the incoming data, you realize that you can improve the service mapping if you map the application tag tags.application to the service field for a subset of your servers which have that information available. You can accomplish this with an alert workflow with Trigger and Set Service actions.

Set the workflow trigger to New or changed alerts (select Changes from anywhere), and add a filter for the application tag:

tags.application != NULL

Configure the Set Service action as follows:

  • Action

    • Replace all service names

  • Service

    • Select Data from Another Field, choose Tags from the dropdown, choose Add a Tag if necessary, and choose or enter application.

Here is an example alert that was processed by this workflow:

Alert fields before

Alert fields after

{
    ....
    "service": [
        "retail"
    ],
    "tags": {
        "application": "CheckoutV2"
    }
}
{
    ....
    "service": [
        "CheckoutV2"
    ],
    "tags": {
        "application": "CheckoutV2"
    }
} 

Incident example

Suppose you want to add a new service name to all new incidents. You can accomplish this by creating an incident workflow with a Set Service action.

After setting up the Trigger, you can configure the Set Service action as follows:

  • Action

    • Add to any service names that already exist

  • Service

    • Text: payment

Here is an example incident that was processed by this workflow:

Incident fields before

Incident fields after

{
    ....
    "services": [
      "support",
      "retail"
    ],
}
{
    ....
    "services": [
      "support",
      "retail",
      "payment"
    ],
}