Notification Workflow Step for a Later Date (Possibly 1+ Years in the Future)

Good afternoon,

I've come across a couple of IT teams that have indicated that they could use a conduit for sending an automated notification after they've completed an activity, and more imporantly, after the associated ticket has closed.

The main use case is a department having provided an individual with temporary access or a temporary account. In that even, the IT team would like a notification sent to the Responsible technician or group to remind them to remove that access/account. In both use cases, the reminder should occur either one year from the ticket's submission, or from a date specified by the IT technician working the ticket. 

There are probably a few ways to do this, but several of them are not viable in our environment. Those non-viable potential options could be:

  • I believe this is possible using Scheduled Tickets in TDX, but we try to avoid using that feature because (and correct me if I'm wrong) Scheduled Tickets post to the ticket calendar, which causes conflicts/muddies the water for Change tickets and Maintenance Activities (we generally only want Change-related items on the calendar). 
  • We could maybe use the "Goes off hold" feature on a ticket, but we don't want tickets staying open for months/years just for a reminder email to trigger.
  • The Timer workflow step sounds possible for most of the goal, but I believe the Timer step does not take tick down when a ticket is On Hold, Resolved, or Closed.
    If I'm wrong though, and the Timer does continue to count down even when a ticket is in one of those states, then this is probably the solution.

That said, I think the goal I'm looking to accomplish is possible using a web services step/API call in a workflow since (and again, correct me if I'm mistaken) a ticket's workflow stays in motion even if the ticket is resolved/closed. Here's specifically what I'd like to accomplish:

  1. Pull a date from the ticket (be that the ticket creation date, or a date entered by the IT technician) and store it for a workflow step later on. 
    I can probably figure this step out since I've pulled ticket ID numbers into a web service step using the PATCH call. I believe I'd use a GET for this particular action item.
     
  2. Add (for example) one calendar year (or, better yet, one calendar year minus one week to allow a buffer) to the item stored from step #1 above.
     
  3. Have the workflow recognize the new date, and send a notification.

Does what I've outlined in the steps above seem possible? If so, what's the best approach? 

I haven't dug into this too much yet, so any information/articles that could help with this are very much appreciated. 

Thank you.

Nate

Asked by Nate Sakovitch on Mon 1/16/23 3:44 PM
Sign In to leave feedback or contribute an answer

Answer (1)

This answer has been marked as the accepted answer
Mark Sayers Tue 1/17/23 11:45 AM

Hello Nate,

A timer step *does* actually continue to "tick" as long as it was started prior to the ticket being moved into a closed/on hold status class.

Essentially we just queue up whatever comes next and tell the system to execute that action X minutes/hours/days/year in the future based on the timer step's configuration. So maybe that could work for you as a route to achieve this end and not keep the original ticket open.

You could test on a ticket by setting the timer for like a couple hours and then closing the ticket after the timer step becomes active in your test workflow (where after the timer you have a web service step that changes its status or creates a new ticket for your team to address, whichever is the best scenario for you).

1 of 1 users found this helpful.
Hi Mark,

Thank you for the information you provided earlier. I'm finally getting back to this task, and the timer workflow step does work as you've described!

Now that I've got the timer portion all set, I'd like to have that timer initiate a next workflow step to create a new ticket. I've completed this portion with the TDX KB at https://solutions.teamdynamix.com/TDClient/1965/Portal/KB/ArticleDet?ID=18608.

If possible, I'd like the following in the new ticket (continued in the next comment due to character restraints): - Nate Sakovitch Wed 2/1/23 1:47 PM
1 - Assign the ticket to a particular group
** I've taken care of this item
2 - Make the new ticket's requestor the same as the original ticket
** The KB says to use {{RequestorID}} in the web service body, but that doesn't seem to do anything (just makes a blank requestor in the new ticket)
3 - DO NOT send the requestor a notification that the ticket was created (a customer receiving a random ticket creation notification causes concern)
** I feel like this is possible with adding a bit of text in the web service body, or maybe the API URL, but I can't seem to get it
4 - Have the Acct/Dept field in the new ticket reflect the requestor's dept.
** The KB indicates that we need to enter a static ID in the Acct/Dept area, but it'd be better if this set itself based on the requestor in the new ticket if possible

Thank you again for the help so far!

Nate - Nate Sakovitch Wed 2/1/23 1:49 PM
You have to actually define a parameter for the RequestorID in the Parameters tab of your web service step for part 2) of your list to work.

The ticket create endpoint supports the following URL-based parameters, so yes it is possible for 3): EnableNotifyReviewer={EnableNotifyReviewer}&NotifyRequestor={NotifyRequestor}&NotifyResponsible={NotifyResponsible}&AllowRequestorCreation={AllowRequestorCreation}

Again, for 4), define a parameter based on the Acct/Dept ID property (which references the ticket's Acct/Dept value. That value should be the same as the Requestor's because the system is built to apply the Requestor's Acct/Dept value to the ticket upon creation) in the Parameter's tab of your web service method and then reference that parameter's name in the body of your call. - Mark Sayers Wed 2/1/23 1:54 PM
Thanks for the additional info.

Shortly after I posted, I attempted to create parameters in the web service method for:
RequestorAID String From Ticket Acct/Dept ID
RequestorUID String From Ticket RequestorUID

When using the web service method's "Test Request" button, I kept receiving a null dept/acct error when typing {{RequestorAID}}, but now I realized that test requires manually entering an actual value, whereas the ticket workflow pulls in the ticket's values. That's my misunderstanding of the test vs. live systems.

Regarding the notification, once you posted the URL-based parameters, I remembered I'd seen that somewhere, and found my way back to the follwoing KB:
https://binghamton.teamdynamix.com/SBTDWebApi/Home/section/Tickets#POSTapi/{appId}/tickets?EnableNotifyReviewer={EnableNotifyReviewer}&NotifyRequestor={NotifyRequestor}&NotifyResponsible={NotifyResponsible}&AllowRequestorCreation={AllowRequestorCreation}

Everything works. I'm all set. Thank you so much!!! - Nate Sakovitch Wed 2/1/23 5:58 PM
Hi again Mark,

Though the initial ask is complete, I'd like to go a bit further if possible - and if I should submit a new question/service request, please let me know.

We'd like to tie a date picker (or text field where a reqeuestor types in a date) to a timer workflow step if possible. The idea is:
1 - The requestor enters an expiration date on a request form
This date should have a maximum of one calendar year from the request date (I don't see a way to make a date picker field have a max date, but if that's possible, it'd help a lot)
2 - The workflow converts that date into a value representing the difference between the request's submission date and the expiration date
3 - Add that value into a timer workflow step as a number of days

I have a couple of ideas for saving the date picker's entry (a workflow step, or an API could probably do it - but suggestions are appreciated), but not sure if TDX can do conversions or if that's something we'd have to do via an API call elsewhere - Nate Sakovitch Thu 2/2/23 9:24 AM
Hi Nate, it probably would be best to start new topics in their own ticket at this point, but generally speaking to your questions: 1 and 2 aren't currently possible natively within the tool, nor is it possible (3) to dynamically set the value of a timer step dependent on values from the ticket/workflow.

You could possible query an outside service to do the conversion for step 2 for you, but that still wouldn't help make 3 any more achievable, unfortunately.

The iPaaS tool could potentially achieve this, but it is a separately paid-for tool. It's very flexible though and this sort of thing should be possible with it if you're interested in speaking to your Customer Success representative about it. - Mark Sayers Thu 2/2/23 9:39 AM
Thanks for the review and clarification, Mark. I had a feeling that would be the result for all items.

I'll consider some other options, and if I have further questions on the latest items, I'll open a new ticket.

Thank you again for the help and information! - Nate Sakovitch Thu 2/2/23 12:54 PM