Groups, Roles, Organizations and Users in Zammad

Context

This is a tutorial video (part of a basic-configuration series) explaining core Zammad administrative concepts and UI settings. Everything shown can also be performed via Zammad’s API, but API usage is intentionally not covered in the video.

Groups — purpose and key settings

Groups separate tickets (like folders or departments) and control access via access levels.

Important group settings

• Outgoing email address: must be set (requires an email account) or agents cannot send replies from that group.
• Assignment timeout: unassigns inactive owners after X minutes (this timeout ignores business hours).
• Follow-up possible / Assign follow-ups: allows or blocks reopening closed tickets and can unassign owners when a follow-up occurs.
• Signature: one signature per group (can be dynamic; there is no per-agent signature).
• Shared drafts: enable or disable per group for team collaboration on replies.
• Note field: admin-only internal note for the group.
• Parent groups: support group trees (hierarchies).

Operational notes

• Groups cannot be deleted — they can only be disabled.
• Disabling a group makes its tickets inaccessible.

Roles — permissions model and recommendations

Roles are bundles of permissions. They only add permissions (there are no negative permissions).

What roles affect

• UI access and admin sections
• Knowledge base (reader/editor)
• Reporting
• Ticket access and permissions (see below)
• CTI / chat
• User preferences

Permissions and configuration

• Ticket permission granularity: read, create, change, overview, full (full = all permissions).
• Group-level permissions can be configured per role (read/create/change/overview/full).
• Default signup roles: you can assign default roles to new users; only use customer roles as defaults to avoid privilege escalation.

Recommendations and notes

• Recommended setup: create a basic agent role with core permissions, then separate roles per group or department (helps with LDAP role mappings).
• SaaS/licensing: users with agent permissions count toward agent licenses; the starter package lacks role management.
• Reporting: reporting profiles cannot be limited by role or user — avoid exposing reporting features to customers to prevent information leaks.
• Agents can add new customers during ticket creation; this action cannot be disabled.

Organizations

Typical usage and behavior

• Typical use: represent the company the customer works for (alternative: use organizations for departments).
• Users can have secondary organizations.
• Shared organization option: when enabled, all members can read and answer the organization’s tickets (useful for service providers; disable for internal orgs to preserve privacy).
• Domain field: supports only one domain and is used for domain-based automatic org assignment on first ticket from a new user.
• VIP flag: mark organizations as important for UI visibility (e.g., paying customers).

Deletion and import

• Organizations can be disabled; removal is possible via the data privacy workflow when the last user of the org is removed.
• Organization management supports CSV import/update (a short video on this is planned).

Performance note

• Organizations with many agents can degrade indexing/search performance.

Users — types, management, and profile settings

User types

• Administrator, agent, customer. One account can have multiple roles.
• Customers must be user accounts (unlike systems that allow anonymous customers).
• Tickets require a group and a customer; owner is optional.

User creation and roles

• Admins can create users manually and assign roles, organizations, and secondary organizations.
• If no roles are selected, default signup roles apply (same behavior as creating customers during ticket creation).
• When assigning agent roles, a group-permission matrix is shown (if multiple groups exist).
• Admins and users with the admin-user permission can “take over session” of another user (this logs the user out temporarily — a powerful operation that should be used responsibly).

User profile menus (available to both agents and customers)

• Appearance: choose light or dark mode; can override browser preference. Quick dark-mode toggle key = D.
• Language: UI language only (does not affect text modules). Low-coverage languages prompt translation requests via Weblate.
• Avatar: upload an image or use webcam; Gravatar is fetched by default on user creation.
• Password & authentication: reset and 2FA configuration (since Zammad 6.4 these can be toggled independently).
• Overviews: reorder UI overview panels.
• Devices: list active browser sessions; sessions can be revoked.
• Token access: create API tokens (tokens are limited to the user’s permission or less, can have lifetimes, and are preferred over username/password for API access).
• Linked accounts: manual link/unlink of SSO providers (e.g., Microsoft 365, Google).

Agent-only profile/settings

• Notifications matrix: configure in-app (phoenix icon) and email notifications; admins can set defaults or overwrite agent settings in Ticket settings.
• Out-of-office: designate a replacement colleague who receives updates/notifications (the owner remains assigned). Replacements need equivalent group permissions.
• Calendar: iCal URL (basic-auth) to subscribe to ticket reminders/escalations (read-only).
• VIP flag: mark individual users as VIPs (like organizations) for UI visibility.

Security & authentication

SSO / third-party login

• Option to hide local username/password login to force SSO-only access.
• Admins can request a one-time password-login email for a user (the requesting admin must have a local password).

Signup & password reset

• The signup form can be disabled (this does not prevent account creation from incoming emails; unknown email senders can still create customer accounts).
• Lost-password functionality can be disabled globally (useful when using LDAP/SSO).

Password policy defaults

• Default minimum: length 10, at least 1 number, at least 2 lowercase, at least 2 uppercase characters. Special-character requirement is optional.
• Admins setting user passwords are not forced to meet the policy (admins should not know user passwords).

Account lockout & session timeout

• Default lockout after 5 failed login attempts; users can unlock via password reset; admins can unlock manually.
• Session timeout default: 4 weeks (configurable from 1 hour up to disabled).
• Third-party-authenticated sessions are not affected by these timeouts.

Two-factor authentication (2FA)

• Supports Security Keys and Authenticator Apps and provides recovery codes when enabled.
• 2FA enforcement is enabled by default for agent roles but can be adjusted.

Data privacy and deletion behavior

User removal behavior

• Removing a user deletes tickets where they are the customer.
• If a removed user is an agent, customer tickets associated with that agent will be removed (the video implied this — verify in product docs if needed).
• If the removed user is the ticket owner, the owner assignment is removed but the ticket remains.
• When removing the last member of an organization, the org may be removed as part of the same workflow.

Data privacy UI

• The data privacy interface shows task status and history for removal tasks.

Practical gotchas & tips (highlighted in the video)

• A group without an outgoing email address prevents agents from replying to incoming mail for that group.
• Assignment timeout ignores business hours.
• Follow-up and Assign follow-ups settings can prevent runaway reopens and can unassign owners on follow-ups.
• Signatures are per-group, not per-agent.
• Disabling a group hides its tickets.
• Organizations with many agents can degrade indexing/search performance.
• Domain field allows only one domain; automatic org assignment works only on user creation.
• Reporting profiles cannot be limited per role/user — avoid giving customers reporting access.
• Creating customers during ticket creation is a core agent action and cannot be disabled.
• Prefer API tokens over username/password for API access.
• Admin session takeover will kick users out of active sessions — use with care.

Guides / future tutorials mentioned

• This video is part of a basic configuration series.
• A short stand-alone video on CSV import/update for organizations is planned.

Main speaker / source

• Video presenter (unnamed), a Zammad product/tutorial author representing Zammad administration best practices.