Freshservice Workspaces let multiple internal service teams (IT, HR, Facilities, Legal) share one tenant with separate ticket queues, separate SLAs, and separate visibility. Done right, every team operates in a clean room. Done wrong, the IT director gets HR onboarding tickets.
When workspaces fit
Use workspaces when:
- Multiple internal service teams want their own portal experience.
- Each team has its own categories, custom fields, and SLAs.
- Cross-team visibility should be opt-in, not default.
Skip workspaces if:
- You only have one service team (you do not need them).
- All teams want shared visibility and reporting (a global ticket type with team-scoped views works better).
- You need shared assets, contracts, and CMDB (workspaces share these globally; team isolation breaks).
Setup order
Always configure shared resources first, workspaces second. Shared resources include: agents, requesters, assets, vendors, contracts, business hours, holidays. These live globally and surface across all workspaces.
Workspace-specific resources: ticket fields, statuses, priorities, categories, SLA policies, automation rules, dispatch rules, scenario automations, solution articles, service catalog items, dashboards.
Agent visibility
An agent can be a member of one or many workspaces. Their default workspace is set under their profile. When they create a ticket, it lands in their default workspace unless they explicitly choose another.
Two-workspace agents (a tier-2 agent serving both IT and Facilities) need to switch contexts. The workspace switcher in the UI is not always obvious; train explicitly.
Requester visibility
Requesters always see one portal at a time. A single requester can submit to multiple workspaces but the portal experience is per-workspace. URLs differ: support.yourco.com/it, support.yourco.com/hr. Do not use a global portal landing page that lists all workspaces; it confuses non-technical users.
Cross-workspace ticket linking
Sometimes IT and Facilities both need to handle one issue (laptop delivery: IT for setup, Facilities for desk space). Use linked tickets across workspaces. Link is bidirectional but the ticket can only live in one workspace at a time. The other workspace sees a read-only summary with a link.
Do not try to “move” tickets between workspaces; copy via workflow into the new workspace and close the original with a link.
Reporting across workspaces
Global reports honor workspace permissions. A user with access to only the IT workspace cannot see HR data even in cross-workspace reports. The CIO with access to all workspaces sees everything.
Build separate dashboards per workspace and a leadership dashboard scoped to your global access. Do not try to embed cross-workspace data in a single dashboard for users with restricted access; the silently-filtered result confuses everyone.
Migration from single tenant
If you are converting an existing IT-only tenant into a multi-workspace setup, freeze the IT tenant first. Snapshot the configuration. Rebuild the IT workspace from scratch in the new model rather than trying to retrofit; the import tool does not always handle existing automations and SLAs cleanly.
Service catalog isolation
Each workspace has its own catalog. A “New laptop” item in IT and a “New desk” item in Facilities live separately. Categorization for the requester portal is per-workspace; do not try to share catalog categories across workspaces.
What to do this week
If you are running multiple service teams in a single workspace today, list the pain points (cross-team noise, conflicting SLAs, mixed reporting). Score whether workspaces would solve them or add complexity. Pilot with one team before a full rollout.
