Agent access
Decide who may become an agent.
Team access decides who may become an agent. It appears in first-run setup and in Settings → Identity.
- Team email domains admit everyone at those domains.
- Additional teammates admit individual addresses.
An address that matches becomes an agent of the workspace on its first sign-in, and can then open every ticket in it. Treat a domain as a standing invitation to everyone who can get an address there.
Free email providers are refused
A free email provider can't be a team domain: anyone can create an address there.
What counts as one. The rule looks at the registrable domain, so subdomains count too:
- providers such as
gmail.com,googlemail.com,icloud.com,me.com,mac.com,msn.com,proton.me,protonmail.com,mail.com,zohomail.com, the large ISPs, and regional ones (web.de,mail.ru,qq.com, …); - whole families under any public suffix:
yahoo.*,gmx.*,yandex.*,hotmail.*,outlook.*,live.*,aol.*,zoho.*.
The list is FREE_MAIL_DOMAINS in src/lib/settings/store.ts.
What happens:
- Saving. The form refuses the domain and names it, and saves everything else. It suggests adding those teammates one by one. The audit entry records what was refused as
refusedFreeMail. - Signing in. A free email domain admits nobody, even one saved before this rule existed or listed in
AGENT_EMAIL_ALLOWLIST. The form says so while one is still listed. - Individual addresses at a free provider, such as
freelancer@gmail.com, still work.
The portal's Customer sign-in domains are not affected. Customers may use any provider.
Team domains that are also customer domains
A brand's Customer sign-in domains (portal → company sign-in) may list a team domain as well. When they do, the Team access form warns and names the brands. Everyone the portal lets in from that domain can also join as an agent and read every ticket, including other customers' tickets. That is right only for a help desk whose customers are its own employees. Otherwise, remove the domain from Team access and add the agents one by one.