I have several projects to support with a different identity per each organization that receives support requests. Is it possible to do this in Zammad in a self-hosted instance or do I need to set up a separate instance per each organization?
For example, I’d like for users from somedomain.tld to get help.somedomain.tld and users for anotherdomain.tld to get help.anotherdomain.tld, but by using the same Zammad instance and so forth? Is this already doable? Or would it have to all be through a single domain like support.somedomain.tld redirects to support.adomain.tld where Zammad is being hosted?
in my opinion the main problem is that you’ll be misxing customer contacts for several organisations. Especially inside the EU-Region this can be troublesome.
So far I know there is no option to use one instance for more than one organisation - even though you can use different E-Mail-Adresses, triggers/notifications per group and so on. The domain support.domain.tld will always be the same, especially when it comes to notifications from zammad (as it shares it’s configured URL).
You’d have to work with different instances - your database and elasticsearch-backend can be the same to save ressources (statet here: https://github.com/zammad/zammad/issues/1047).
It would be VERY useful for us to be able to support multiple projects with one Zammad instance, a single user or organization could actually submit tickets within multiple projects, but the projects should operate on separate frontend interfaces with its own branding etc.
But, What i am google for is: multiple instance of zammad on a single installation
For example, I’d like for users from somedomain.tld to get help.somedomain.tld and users for anotherdomain.tld to get help.anotherdomain.tld, Each one isolated but on a single installed zammad. Zammad.com guys i guess did it.
You cannot run multple organizations within one zammad-instance. You need different backends, because otherwise you will mix data of companies - this will get you in trouble.
I understand that NOW it is impossible, this is why this should be treated as a feature request. What would be required - is a new layer that could “tag” users and issues and pin them to these “separate frontends”.
In the backend - this could still be ONE instance, with one set of agents managing it. Quite similar to what Jira Service Desk allows for.
This would be super useful in many use cases - a service company that provides support to many clients, a company that runs many separate projects or brands. From GDPR / data protection perspective this is not a problem as the “backend” operating entity is still the same, and owns all the data. On the “frontend side” of things we could have a very simple solution:
Lets call the separate “front ends” Projects, for simplicity.
We could set if the end user can see multiple Projects he is assigned into at once (using a single login). Subsequently if he can use a single login for multiple projects, or if he needs to log into separate frontends multiple times to work with multiple projects). If the user can see multiple Projects at once - instead of creating an account for next Project he would be able to add his account to it (if self registration is enabled for the project) or would need an admin to do that (if self registration is disabled)
We could set if the end users organization can see issues of other users from the same organization in multiple Projects (setting per project)
When creating new issues we should be able to configure / run multiple “channel” modules (e.g. email, twitter etc), and pin each channel module instance to a Project.
This improvement would actually make Zammad usable in beforementioned use cases. While it is doable to run separate helpdesk instances for lets say 2 or 3 Projects (as defined here) it is a nightmare if you need let’s say 10 or 20 projects that would be operated by more or less the same group of agents (btw. it could be possible to assign agents to a subset of projects in the same way we could do it for users)… Imagine an agent that needs 20 windows open and support 20 different queues… Imagine a manager trying to oversee it…
