When a User need Hardware or access they need to get the approval from their Lead.
At the moment this is missing in zammad, so we can’t really use it yet.
What is your original issue/pain point you want to solve?:
Get the approval from a specific Person before continue work on a Ticket
Which are one or two concrete situations where this problem hurts the most?
When a User needs specific access or Hardware we from the IT Support want an approval by their Team Lead.
Why is it not solvable with the Zammad standard?
Feature is not implemented
What is your expectation/what do you want to achieve?
Having a full Approval Process in place.
We normally just do a “reply” on the ticket that needs approval, putting whoever we need approval from as the “To” address. The reply comes back to the ticket.
You haven’t actually described what your requirements or expectations for this feature request are?
So how would you expect such a feature to work, what are you imagining? Do you imagine like a workflow engine type of thing where the ticket is “tasked” to somebody else?
I think he wants something more like designated Team leads. Like you can designate each User a specific Lead and when the ticket gets flagged for approval he has to acknowledge it inside the ticket. Prob with a specific button instead of change of the agent.
I thought about assign a specific Lead to a Person but this would be a lot of hussle in the setup when you have a lot of employees. Maybe you can sync this information via LDAP but then you also need to have this information somewhere. So in the end I let the user decide who is their Lead.
The zammad Admin can create a Ticket Type that needs approval
The user creates a ticket and adds the Lead as approver
The Lead receives a Mail and see that an approval is needed in their Zammad UI
The Lead can now approve or decline. This information will be tracked in the Ticket history and the Admin receives a Mail about the changed Ticket Status
Approval workflows are a common requirement that our consultants encounter in their workshops. Many of these can be met through the clever use of triggers, custom attributes and core workflows. However, one thing we have learned about approval workflows in recent years is that the way they should be handled varies greatly from one use case to another. This makes it extremely difficult to build a one-size-fits-all solution into the core product.
Rather than incorporating a solution that only caters for some use cases, I would prefer to enhance the capabilities of the existing tools to cover more use cases. We have done this in the past by increasing the capabilities of the available conditions and actions on triggers, filters and core workflows. We have also increased the capabilities of custom ticket attributes. And we will continue to do so.