This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Nesting automation rules

Is it possible to have multiple automation rules occur on a incident after its created.   In my case we have the SolarWinds Orion integration setup.  What i would like to happen first is that on ticket creation it performs the following actions:

- Add a tag
- Set a standard Category/Subcategory
- Set a specific assignee

This step has no issues completing alone.

After this first action is completed I am attempting to have a secondary automation rule run on this, tried both with and without the time based automation rules but unable to get this to trigger. 

First use case is alerts that come from the system for installing windows updates.  I am using the Keyword Regex logic to find these incidents.  One these I am:

- Adding an additional tag
- Updating the Category/Subcategory to our patching tickets. 
- Updating the assignee based on text in the description (pulled from regex, we have about 10 different groups they go to) 
- Updating the Due date 

Trying to get this rule to run after the initial does not work.  If i create generally the same rule and have it trigger without the first rule it works (verifies the regex is good).  So it just seems to be the issue of having a secondary rule run on an incident.  The time based rules, using the changed "FROM" and "TO" rules, also playing with the object updated, created, or just custom and I can not figure out a method to get this to work.  

Any suggestions?  If you need to see my setup i can create some clean examples later. 

  • Our roadmap plans include two future enhancements that could help your use case:

    • Triggering (and executing) multiple automation rules on the same event
    • Triggering automation rules on system updates (e.g., updates done via Update Record in an automation rule)

    We're hoping to deliver at least one of the above changes before the end of the year. 

    Currently, the only way to trigger "secondary" rules is to use API calls to update the relevant record (you could update any field). An API update record call, combined with a a time based automation rule, could give you the result that you want. Note that when you use a time based rule, your condition should query the current value of fields, since the trigger for such rules is time, not a record update where the From/To context applies. 

    I hope this helps. 

  • Thanks for this information, a few final questions.  

    Is the general road map available online for viewing regarding what features are verified actively being worked on and planned ETA's, and future roadmap items for future releases in order of priority?  I understand that any roadmap item, either the item itself or its ETA can always change.  

    Second the API update record call, is that an action item I am missing and if so where is the trigger?  Or are you just referring to the rest API that is documented in the link below?

    If so how do you recommend setting up the timing so that alerts are not delayed.    

  • Roadmap - we don't share the full roadmap as a public doc for legal and other reasons. Nevertheless, there are three ways that we share more detailed information:

    1. We periodically update the What We're Working On page (SWSD WWWO) with information about features on which work has already started (even if it's just the initial design). We are currently in the process of updating this page with the latest. Note however that the next revision won't include the features I mentioned above,  because work on these items has not started yet.

    2. Last month we started a new series of quarterly product updates where we intend to share roadmap information.  In the future, we will provide a way to submit questions in advance, that we will try to address during the call. 

    3. You can work with your account manager/rep to request a roadmap discussion with a member of our team (Product team). 

    Record update - yes, I was referring to the API described on As for the trigger/timing,it really depends on the specifics of your environment. if I understand the scenario correctly, you have a system that generates the events that should trigger your second automation rule, which in turn is expected to update a record. If feasible, that system could not only generate the alert you were referring to, but also update a field of the target incident record to a/any value that would trigger a time based automation rule.

    Since you mentioned Orion above, while I'm not very familiar with Orion, an example would be to create an alert in Orion that performs multiple actions when a specific event occurs. One of these actions could be to run a script (or a command such as CURL) that uses the SWSD API to update the target incident record, which should then trigger your time based automation rule. 

    I hope this helps.

  • Just to make sure were on the same page Orion = SolarWinds Orion (both the NPM and SAM modules)

    In Orion there is already an alert action integration with the SWSD and it creates the ticket and links the alert and ticket together.   However I have looked and did not find a method to pull the information that links the tickets so that a follow up action can update the related incident.   

  • Yes, that is correct. Orion has the following properties:

    However, I checked with the Orion product manager and unfortunately, the above information is not available to the alert, at the time that the alert info is sent over to SWSD. 

  • Thank you very much, one last question regarding the Orion integration while you possibly still have a product managers ear.   

    From what I have found in the alert action in Orion the below variables can be defined in the Entity or Custom Attributes section to send into SWSD.   


    Are there any other variables that can be passed from the alert action that link directly to SWSD fields. 

    My main wants are to be able to send in the:

    Assigned to (this is my biggest need/ask)

    If there was a way to send in the "assigned to" from the alert action this honestly could solve my needed workflow as well.  I realize there would probably have to be some tweaking on my naming, might have to use the back end ID number or email for the person / group as it exists in SWSD but that would make most of what I need function.   

    From what I understand so far, as long as an alert property comes in named correctly as the incident is created in the system it will automatically read in the data to that field and set it appropriately.  I have done some self testing but have not been able to figure out a method to get this to work for the additional fields. 

    Thanks again for your assistance on this and any information you are able to add to this. 

  • Here's the Orion PM's response:

    "Any alert variable can be sent but the assigned to value would be empty at the time the alert triggers. You could define a new property “assign to this team” and provide any value you need, then find a way for SWSD to identify and process"


  • Yeah i know that i can send any alert variable over to Service Desk from orion, What I was wondering was if there were any variables that can be defined that link directly to the mentioned fields:

    Assigned to 

    So that when the alert action creates the ticket I can set these fields from the alert action definition and not need to rely on secondary step automations within SWSD.