Workflow conditions and actions

This topic lists all available conditions for each trigger type, explains what each condition does, and describes the actions you can apply.

All actions and updates applied to tickets must be set explicitly. Each action performs one task. If you need to perform multiple tasks, such as assigning a technician and setting the ticket status to "Assigned", you must add a separate action for each task.

Email conditions

Use the following conditions to define workflow rules. Each condition includes a description of what it checks.

  • Contact location: Checks the contact's location associated with the contact email address.
  • Customer contains contract: Checks if the selected customer has a contract with the specified name.
  • Sender email: Checks the email address of the sender.
  • Email body: Checks the body of the incoming email.
  • Email subject: Checks the subject of the incoming email.

    When creating workflow rules for Email Subject or Email Body, use Contains as the condition operator.

  • Customer name: Checks the customer name.
  • Sender domain: Checks the email domain of the sender of the incoming email.
  • Monitored mailbox email address: Checks the email address of the monitored mailbox. Use this to process messages only from a specified mailbox address.
  • Program level name: Checks the name of the program level.

Outage conditions

Use the following conditions to define workflow rules for outages. Each condition includes a description of what it checks.

  • Asset – Description: Checks the asset description associated with the incoming outage.
  • Asset – Domain: Checks the asset domain associated with the incoming outage.
  • Asset – External IP: Checks the asset's external IP address associated with the incoming outage.
  • Asset – Install date: Checks the install date of the asset associated with the incoming outage.
  • Asset – Location: Checks the location name of the asset associated with the incoming outage.
  • Asset – OS type: Checks the asset OS type associated with the incoming outage.
  • Asset – Owner: Checks the asset owner associated with the incoming outage.
  • Asset – Server role name: Checks the server role name of the asset associated with the incoming outage.
  • Asset – System type: Checks the system type of the asset associated with the incoming outage.

    The system type in RMM is determined by the Servers tab, the Workstations tab, or the Type columns for network devices.

  • Asset class: Checks the asset class associated with the incoming outage and compares the asset ID to determine if the asset class is listed in the condition builder.
  • Asset class name: Checks the name of the asset class associated with the incoming outage.
  • Asset location address 1: Checks the primary location address of the asset associated with the incoming outage.
  • Asset location address 2: Checks the secondary location address of the asset associated with the incoming outage.
  • Asset location city: Checks the city of the asset associated with the incoming outage.
  • Asset location ZIP code: Checks the ZIP code of the asset location associated with the incoming outage.
  • Asset status: Checks the asset status name associated with the incoming outage.
  • Assigned service item: Checks if the service item with the given name exists in the many-to-many table that stores associations between assets and service items.
  • Check category name: Checks the category ID of the asset associated with the incoming outage.
  • Customer has service item: Checks if the customer associated with the incoming outage has a service item with the specified name.
  • Customer name: Checks the name of the customer associated with the incoming outage.
  • Customer since: Checks the created date of the customer associated with the incoming outage.
  • Customer status: Checks the status of the customer associated with the incoming outage.
  • Location – State: Checks the state in which the asset is located.
  • Outage – Description: Checks the description of the incoming outage.
  • Outage – Created date: Checks the creation date of the incoming outage.
  • Outage – Subject: Checks the subject of the incoming outage.
  • Previous ticket – Closed date: Checks the closed date of previous tickets associated with prior outages.
  • Previous ticket – Date of last activity: Checks the last updated date of previous tickets associated with prior outages.
  • Previous ticket – Details: Checks the details of previous tickets associated with prior outages.
  • Previous ticket – Opened date: Checks the opened date of previous tickets associated with prior outages.
  • Previous ticket – Title: Checks the title of previous tickets associated with prior outages.
  • Program level: Checks the name of the customer's program level associated with the incoming outage.

Portal ticket request and easy ticket request conditions

Use the following conditions to define workflow rules for portal and easy ticket requests. Each condition includes a description of what it checks.

  • Contact email address: Checks the contact's email address associated with the ticket request.
  • Contact location: Checks the contact's location associated with the ticket request.
  • Ticket category: Checks the ticket category of the portal ticket request. This condition is only available for portal ticket requests, as ticket category cannot be determined for easy ticket requests.
  • Ticket request details: Checks the details of the ticket request.
  • Ticket request title: Checks the title of the ticket request.

Actions

Use the following actions to define workflow rules. Each action includes a description of what it does.

  • Set property: Sets a property of the created ticket to one of the following options:
    • Priority
    • Ticket status
    • Is taxable
    • Is billable
    • Description
  • Update previous ticket: Reopens a previously closed ticket for the same RMM outage and adds a note indicating that it was reopened.
  • Create ticket: This is the default action for all workflows.
  • Assign technician: Uses ticket routing rules to assign a technician to the created ticket.

    To apply this action in a workflow rule, add the Set property action, then edit the action. In the Property dropdown list, select Ticket status, and set the value to Assigned.

  • Assign service plan: Assigns a service item using one of the following methods:
    • Default service item of the customer (if configured)
    • Selected service plan—assigns a service item created using the selected service plan. If the service item is not found, the action does nothing.
  • Assign contact: Assigns a contact to the created ticket using one of the following methods:
    • Contact which created Ticket Request - Customer contact that initiated the ticket request.
    • Default Customer Contact - if the default Contact for the customer is configured, it will be assigned.
    • Named Contact - finds specified contact by email address.
  • Assign queue: Assigns the ticket to the selected ticket queue.
  • Do not create ticket: Overrides the create ticket action.
  • Set ticket issue type: Assigns the selected ticket issue type and sub-issue type to the ticket.
  • Delete ticket request: Deletes the ticket request.

    For example, if your company does not want tickets created for requests from a specific email address:

    Condition: Sender email address contains 'Email@domain.com'

    Action: Delete ticket request

    To ensure ticket requests are deleted using a workflow rule, add a Do not create ticket action before the Delete ticket request action.

What would you like to do?