Read access to all tickets for special organisation


  • Used Zammad version: 3.0.0-1560433985.617324d6.xenial
  • Used Zammad installation source: for xenial
  • Operating system: Ubuntu 16.04
  • Browser + version: FF 67 on Ubuntu 18.04

Use case:

We run several Zammad instances to handle our customers but for some of the we got a special use case. That is with a dedicated instance for one agency customer that is used by three kind of personas like agency employees, it’s freelancers and also the end customer of the agency. Only the first group has for sure the same mail domain for creating a shared organization.

In this scenario we have therefore kind of a super customer with the agency who would like via it’s employee and the shared organization to read access also tickets created by freelancers and end customers with various mail addresses. While the shared organization should be able to read all tickets not created by them they clearly shouldn’t act as agents. The aim is just to making information from the end customer communications within agency projects available to agency employees.


What could be a way to configure this kind of behavior? Looked already a bit in to roles, organizations and custom attributes, also searched online and within the forum but are still a bit clueless how to create this. Basicially it’s kind of super customer group while regular customers of course should be able to access tickets from other customers. We guess that this is more easy to configure on a user basis but we aim to have it on a group basis with an organization.

The only way to achieve this in the current state would be a shared organization which every member needed for this is inside that organization.

Please note that this only works for one customer/organization.
This is imho a really really bad idea.

Ignoring your organization wish:
Put the customer into one shared organization and -if you really have to- ensure that the communication between the freelancers and the agency gets inside a ticket of the customer. That way he’ll see the answers if they’re public.

Again, both approaches are a bad idea in my opinion.

@MrGeneration True true the nerd in me also thinks it’s a bad idea :sweat_smile: But at least a few users from the agency should be able to read access all tickets and optional add them self to the conversations.

So do you see any other way to solve this on a user basis with special permission without granting the agent role. But if the agent role is the only way to deal with it can there by separate groups or types of agents. Meaning that the real agents could still make internal notes the people from the agency even with kind of agency permissions can’t read.

Thanks for your efforts so far :vulcan_salute:

I’m afraid there’s no other way than hacking around it with API stuff (so having another interface giving information). Zammad is not designed to allow customers to have access to specific roles.

You need to provide agent rights with access to groups, no other way. Sorry about that.

@MrGeneration Thanks a lot for clarifying that :metal: Building a whole system around a hack is something we for sure don’t like either :innocent: We’ll deal with it on a management level when we don’t have a technical solutions. A feature about multiple agent levels could be interesting but probably also bloats a lot of stuff and in the end people just force the management decision if customers are customers or agents :joy:

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.