1) What is your original issue/pain point you want to solve? When an incoming email causes a ticket’s state to change (e.g., from Closed or Pending to Open), we frequently need to build automation that evaluates what the state used to be before the update, and then dynamically revert the ticket back to that exact state. Currently, both Triggers and Postmaster Filters only allow checking and setting hardcoded, static states (like “Closed”), which breaks workflows if the ticket was previously in a custom state, Pending, or Awaiting 3rd Party Response.
2) Which are one or two concrete situations where this problem hurts the most?
- Customer Satisfaction Surveys: A ticket is set to “Closed” and a survey is sent. If the customer replies with an automated “User Satisfaction Feedback” response, Zammad automatically opens the ticket. We need a Postmaster Filter or Trigger to check a condition: If Previous State was Closed, and then execute an action: Set State to Previous State. Currently, we are forced to hardcode the action to “Closed.”
- Out of Office / Automated Replies: If a ticket is currently “Pending Reminder” and the customer sends an automated OOO reply, the ticket incorrectly opens. We need to detect the OOO response, check if the previous state was a pending state, and dynamically revert it back to its original pending status. We cannot currently do this; we can only assign a static new state.
3) Why is it not solvable with the Zammad standard? In both the Trigger and Postmaster Filter UI, the State dropdown only provides static database variables (Open, Closed, Pending, etc.) for both “Conditions for affected objects” and “Execute changes on objects”. Zammad does not natively expose a dynamic #{ticket.previous_state} variable to check against or assign. Reverting the state dynamically currently requires building complex external API webhooks or creating and maintaining custom Ruby .zpm packages.
4) What is your expectation/what do you want to achieve? I would like a native way to evaluate and revert a ticket’s state via automation by implementing the following:
- In Conditions: Add a “Previous State” operator/value combination to the existing
Statedropdown under “Conditions for affected objects” (e.g.,Stateprevious wasClosed). - In Actions: Add a dynamic “Previous State” option directly into the
Stateselection dropdown under “Execute changes on objects”. - Cross-Platform Availability: Make these options available in both the Triggers and Postmaster Filters settings.
Your Zammad environment:
- Average concurrent agent count: 20+, We are evaluating this product. We will going to use this for our e-commerce website as well and then agents number will increase.
- Average tickets a day: Currently is 50, in recent Future 200+
- What roles/people are involved: Admin, Agents