Help with Trigger or Scheduler For Actions on Tickets After Customer Hasn't Responded

Technical assistance
1

Infos:

  • Used Zammad version: 6.5
  • Used Zammad installation type: docker-compose
  • Operating system: Ubuntu 20.04
  • Browser + version: Brave Version 1.76.82 Chromium: 134.0.6998.178 (Official Build) (64-bit)

What I am trying to achieve is notifying a customer after they do not respond on a ticket for one week, and then to close it after another week. Here’s the general idea:

  1. Customer and Agent do their back and forth on the ticket. Matter seems to be resolved but ticket remains open, Agent leaves a reply “if there’s anything else we can do for you please let us know.”
  2. Customer doesn’t respond, or close ticket. After one week of not hearing from the customer we add a new article w/ a message like “hey, we haven’t heard from you. Please let us know if you need anything else. If you don’t, this ticket will automatically close in one week”. The customer receives an email notification with those details.
  3. One more week passes w/no response from customer, automatically update ticket state to closed.

So here, the general conditions are:

  • Ticket state is Open
  • Last public note/reply by agent is more than 1 week ago

Based on the documented trigger limitations, it seems that I should not create a trigger because:

Triggers are executed when a ticket is updated via clicking the “Update” button.

So, I assume I should use the Scheduler, please let me know if I am wrong here. I have set up a scheduler action with what I think is the correct configuration:

  • Object: Ticket
  • Condtiions:
    • Ticket: State is open
    • Ticket: Last contact (agent) - before (relative) - 7 day(s)
    • Article: Sender is Agent
    • Article: Visibility is public
  • Execute Changes On Objects
    • Note: Visibility public
    • State: pending close
    • Pending till - relative - 7 day(s)

image
image1189×1304 110 KB

Regarding the conditions, I’m not sure if I have the article conditions right, or if they will work as I expect. Based on the trigger limitations documentation, it sounds like any conditions on an article are matched against the most recent article, I’m guessing this is the same for the scheduler. If this is the case, will my condition fail if the last article was an internal one by an agent? Meaning, if the last article is an internal one by the agent, this would never run?

My other question is about the executed changes. I am assuming that setting the state to ‘pending closed’ and ‘pending till’ to 7 days will accomplish the goal of closing the ticket after 7 additional days - is this correct?

Also, we have a trigger in place to notify customers of new replies by agents on their tickets. I’m assuming that since I have ‘disable notifications’ set to ‘No’ that the customer will receive the email notification with the details given about their ticket closing if they don’t respond for another week - is this correct?

2

That part of the documentation needs improvement IMHO. Triggers are executed when the state of the ticket changes. Changing something and “clicking Update” is just one way this happens.

Either way, since you want something to happen based on how much time has passed, the scheduler is what you want. I can’t tell you, though, if your configuration is going to work, best you test it in a safe environment first.

1 Like
3

Thanks @vic for your comments - you’re right it’s the schedule that I wanted.

I was able to figure out how to do what I wanted but it’s quite a bit different than what I mentioned above. We’ve developed a custom frontend for Zammad that is built into our websites, and as part of that, “customers” use web-type articles and admins mainly use note-type articles to communicate.

After digging I found that note-type articles will NOT update some timestamps because notes are not a communication article. And, communication articles will not update the timestamps. I did find this documentation which might indicate a way to have notes update those timestamps, but we didn’t go that route - just mentioning it here in case others are interested in another option.

Here’s what we did to get this working the way we wanted:

  1. Added a new property onto the ‘Ticket’ object, ‘Last Public Contact By’. This can either be ‘support’ or ‘user’.
  2. Added two triggers:
    • Whenever an article is created with public visibility and the sender is ‘Customer’ set ‘Last Public Contact By’ to ‘user’
    • Whenever an article is created with public visibility and the sender is ‘Agent’ set ‘Last Public Contact By’ to ‘Support’
  3. Add a scheduler:
    • Set it to run once every morning at 8 am
    • Object: Ticket
    • Conditions:
      • Ticket state: Open
      • Last Public Contact By: Support
      • Updated at: Before (relative) 1 Week(s)
    • Execute changes on objects:
      • Email recipient customer with our message
      • Ticket State: Pending close
      • Pending till: relative 7 Day(s)

So, what essentially happens here is that whenever a new article is added to a ticket that is for the other party to see, it tracks who sent it. If the last public contact was made by support, and it was a week ago, it’ll send the customer and email and set the ticket to close in one week.

An additional benefit of this solution is that the ‘Last Public Contact By’ field can be used in our overviews to see at a glance if there are any tickets that were last communicated on by a “customer” that need an agent’s attention.

Now that it’s been the two full weeks needed for us to test this I can confirm it’s working for us as desired. Kudos to Zammad developers and the organization for putting out such a robust system!

1 Like