Configurable update-time SLA semantics
1) What is your original issue/pain point you want to solve?
The SLA “update time” is bound to Zammad’s fixed definition of what counts as an update and does not map onto arbitrary process steps.
2) Which are one or two concrete situations where this problem hurts the most?
A process working with per-step deadlines (“next action due by”) on top of an overall closure due date cannot be represented; escalations fire at the wrong time or not at all.
3) Why is it not solvable with the Zammad standard?
The SLA engine only knows first response, update and solution time with fixed semantics.
4) What is your expectation/what do you want to achieve?
A modified/configurable update-time SLA that can match the customer’s own ticket process (i.e. which events reset or fulfil the update target).
Ticket#10231017