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:
- Added a new property onto the ‘Ticket’ object, ‘Last Public Contact By’. This can either be ‘support’ or ‘user’.
- 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’
- 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!