1 Reply Latest reply on Jul 5, 2017 5:56 PM by kellytice

    Trigger to generate a ticket after a set amount of time




      We have a need to have a trigger occur after a set amount of time.


      So lets say,


      1. HR submits an employee separation ticket

      2. We perform the request of the ticket (lets say we deactivate the accounts or change passwords)

      3. This ticket could get resolved or closed

      4. At the original ticket creation or at close it spawns a new ticket SCHEDULED 30 days out (informing us to delete former employees accounts/data).


      No where have I found a 'counter', anything scheduled is a specific date or specific reoccurring dates via action rules or tasks. Any ideas?

        • Re: Trigger to generate a ticket after a set amount of time

          This isn't really possible in an elegant way.


          I can think of a way that might work for you, but it's not super intuitive/easy-to-setup.   The general flow of it would be:


          • Someone opens up a ticket and chooses the Employee Separation Request Type.


          • An Action Rule gets triggered based on a new ticket having that Employee Separation Request Type and the Action Rule launches a Task.  The Task then kicks off one or more other initial tickets  (perhaps one for the account deactivation and another for password change and a third for Facilities to clean up the office/cube)

            However many Task Elements (tickets) there are, you'd likely want to put conditions on those so that each Task Element ticket only gets generated when the Task Element ticket before it is Closed.   (That is done with a setting called "Generate Next" which is an option on each Task Element).


                  The last Task Element defined in the Task would be the one for the "30 days out" followup ticket.



          NOTE: The biggest 'problem' here is that WHD doesn't really have a time mechanism in place that works with only one Task Element.  The Task itself as a whole could be scheduled to recur at a certain time, but that's not possible for just one part (Task Element) of the Task.


          So, the real trick here is to come up with a way that that last Task Element piece can be kicked off 30 days out.   This method would essentially leave the next-to-last Task Element "open" - perhaps in a particular custom Status for that 30 days and then alert a Tech when the last ticket needs to be generated.




          So, the last pieces to this puzzle would be to:

          • Create a custom Status called 30DayFollowup (or whatever you'd like to name it) - this is just a way to let the Techs know that tickets with this Status shouldn't be Closed out yet.   When the Techs work the next-to-last Task Element ticket, instead of Closing it they would put it in this status.
          • Create a custom Priority called LongTermTicket or 30DayFollowup (or whatever you'd like to name it).  For this Priority we'd define a "Due Date" of 30 days, and we'd set up one of the Alert Levels in the Priority definition to notify the Tech if the ticket hasn't been Closed in 30 days. The next-to-last-Task Element can be set to get this Priority automatically.
          • When the Tech gets the Alert from the system, they will set that next-to-last Task Element to Closed.   If the task was setup the right way, that should kick off that final Task Element ticket.


          Overall, there are two manual steps here for the Techs to do:

          1. Remember to set the next-to-last Task Element Ticket to the custom Status (30DayFollowup) instead of Closed
          2. When they get the Alert, Close that next-to-last Task Element.

          Everything else would be somewhat automated.





          *(phew)* - hopefully that made sense and wasn't too convoluted!