- What is your original issue/pain point you want to solve?
There is no standard way in Zammad to store a relation from a user to one or more other users, for example the supervisor(s) of an agent. Organizations usually maintain such relations in their directory (e.g. the LDAP “manager” attribute or dedicated approver groups), but Zammad has no object attribute type for it, cannot sync it via LDAP and cannot use it in trigger notifications or Core Workflow. Everyone who needs it has to build a custom attribute plus custom logic.
- Which are one or two concrete situations where this problem hurts the most?
- Budget based approvals: there is one approver for purchases below 1,000 EUR, another one for purchases above 1,000 EUR and a third one for purchases above 10,000 EUR. Each approver relation would be a separate user field (e.g. “Supervisor < 1,000”, “Supervisor > 1,000”, “Supervisor > 10,000”), filled with different users from LDAP. An approval field on the ticket should only be visible and editable for the matching supervisor of the ticket owner. Today Core Workflow cannot express “the logged-in user is contained in field X of the ticket owner”.
- When a ticket reaches a certain state, the matching supervisor of the owner should be informed by email via a trigger. Today the trigger recipient list is fixed (owner, customer, agents of the group, …) and does not know user fields of the owner.
- Why is it not solvable with the Zammad standard?
- The Object Manager offers no “Multi-select with relation User” attribute type. Such attributes can only be created via console, and even then the following points are missing.
- The LDAP integration cannot map a directory attribute to such a field and resolve the referenced entries (user DN, group or list of users) to Zammad users.
- Trigger email notifications offer a fixed list of recipients; user relation fields of the owner cannot be chosen as recipients.
- Core Workflow cannot compare a user relation field of the ticket owner against the current session user.
- What is your expectation/what do you want to achieve?
- A new object attribute type “Multi-select with relation User” in the Object Manager (at least for the user object), so that admins can create any number of such fields, e.g. several supervisor fields for different budget levels. Each field allows selecting one or more users (several to cover substitutes, e.g. during vacation).
- LDAP sync: these fields can be mapped to LDAP attributes. The LDAP value may be a single user, a group or a list of users; every entry that resolves to a Zammad user is written into the field.
- Trigger action “Email notification”: the recipient list is built dynamically. Zammad iterates over the user object attributes, detects every multi-select attribute with relation “User” and offers it as recipient based on its field name, e.g. “Owner: Supervisor > 1,000”. When selected, the notification is sent to the users stored in that field of the ticket owner.
- Core Workflow: because these are regular user attributes, they are automatically available for the session user and the ticket owner, so conditions like “current user is contained in Supervisor > 10,000 of the ticket owner” can be used, e.g. to show an approval field only to the matching supervisor.
A generic attribute type instead of a fixed “supervisor” field keeps the feature flexible for other use cases (deputies, team leads, cost center approvers, …). The relations are usually already maintained in the directory (LDAP/Active Directory), so syncing them instead of maintaining them manually in Zammad is important for larger installations.