Department admins can see and add users from ALL departments when managing queues – privacy/compliance issue

[alexander12323232]

Hi all,

we're running a 3CX instance with multiple departments, where each department is intentionally set up as a separate, self-contained area. In our setup, this separation isn't just organizational – it's a privacy and compliance requirement, since the departments represent different organizational units with strictly separated responsibilities.

To delegate administration, we promoted some users to department administrators so they can manage the call queues of their own department independently. That's where we noticed the following behavior:

When a department administrator edits a queue and adds agents, the user selection shows ALL users of the entire 3CX instance – including every user from other departments – and the admin can actually add them to his queue. The selection is not restricted to the admin's own department.

This causes two real problems for us:

1. Privacy (GDPR): Department admins get visibility into personal data (names, extensions) of employees from other departments, without any business need. This breaks the need-to-know principle that the department separation is supposed to enforce.

2. Compliance / tenant separation: A department admin can actively assign users from other departments to his own queue and thereby interfere with the call routing of other organizational units – without the affected department ever knowing or consenting. This effectively defeats the whole point of having separated departments.

Expected behavior: When managing queues, the user selection for department administrators should be restricted to members of their own department – consistent with the rest of the department permission logic.

Has anyone else run into this? Is there a configuration option we're missing, or is this a known limitation?

If it's working as designed, I'd like to formally request this as a product improvement – for organizations that rely on department separation for compliance reasons, the current behavior is a real blocker.

Thanks!

 

[NikosT_3CX]

@alexanderhofstaetter in this case since you want pure isolation of the Departments and operations, why you do not use Multi-Company mode ?

 

[alexander12323232]

Thanks for the suggestion, but Multi-Company mode is unfortunately not an option for us – for several reasons:

1. Microsoft 365 integration: This is the complete showstopper. We operate a single Microsoft 365 tenant that contains multiple business entities, and we rely on the M365 SSO integration for all departments. Since the 3CX M365 integration binds to one tenant, splitting into separate 3CX instances/companies would break SSO and user provisioning for everyone. Having multiple legal/business entities within one Microsoft tenant is a very common real-world setup.

2. Shared SIP trunk: All departments share the same SIP trunk(s). Multi-Company would force us to duplicate/split trunk infrastructure that is intentionally shared.

3. Cross-department users: Some users legitimately belong to multiple departments. That's exactly what the department concept handles well – and exactly what Multi-Company mode cannot do.

So the department model is the right fit for our structure. The issue is really just this one permission gap:

I'd even argue the read visibility is the smaller problem. The critical part is that this is a WRITE operation – a department admin can actively add a user from a completely unrelated department to his own queue, thereby changing that user's call routing and workload without the other department's knowledge or consent. A delegated admin performing write operations on objects entirely outside his scope of authority is a fundamental permission model issue, regardless of the deployment scenario.

Expected behavior remains: agent selection in queue management should be scoped to the admin's own department(s), consistent with the rest of the department permission logic.