Upcoming capability (March 2025)
Freshservice enables new teams setting up a dedicated workspace for their operations to preview the end-user experience before publishing the workspace. As an admin of an in-setup (previously called draft) workspace, you can publish service catalog items and solution articles while keeping their visibility limited to workspace members (agents). This enables a controlled environment for previewing the experience on the support portal, and refining configurations, ensuring a seamless, efficient, and error-free go-live process.
Who can preview an in-setup workspace?
Agents:
✅ Only agents explicitly added to the workspace (henceforth referred to as ‘workspace members’) can submit tickets, request service items, or access solution articles—provided these items are visible to workspace members.
❌ Account-wide admins can configure the workspace but cannot preview the experience unless they are explicitly added as members.
❌ Agents from other workspaces cannot submit tickets or view published items from this workspace.
Requesters:
❌ Requesters cannot submit tickets or view published items from this workspace until the workspace is published.
How can admins preview the experience?
A. Previewing service items and solution articles
When admins publish service items or solution articles while the workspace is in setup mode, their visibility across support channels (i.e., agent portal, requester portal, ServiceBot/virtual agent) will be restricted to workspace members. Workspace members can also submit tickets using these service items to verify that the configured processes and workflows are functioning as expected.
How do visibility rules work in in-setup workspaces
For an item to be visible on support channels, both of the following conditions must be met:
The agent must have access to the service item based on its visibility settings.
The agent must be explicitly added to the workspace.
Once the workspace is published, these items will be available to both requesters and agents from other workspaces, following the applicable visibility rules.
Tip: The order in which service item categories will appear on the support portal to all users after the workspace is published can be adjusted beforehand under Global Settings > Service Catalog. Workspace members can preview the experience and request adjustments if needed.
B. Previewing the ticket (‘report issue’) form
Members of in-setup workspaces can select the workspace, preview its form, and submit tickets directly for testing purposes.
The visibility of the Workspace field (default label for the requester portal is ‘Issue related to’) on the ticket form, as well as the list of workspaces available in this field will depend on the following criteria:
Case 1: The account has one published workspace and one or more in-setup workspaces
The workspace selection field (Issue related to field) will be visible only to agents who have been added to at least one in-setup workspace.
The field will be visible to them irrespective of the channel from which the ticket is raised (i.e. agent portal, requester portal, mobile, servicebot/virtual agent)
These agents will also see a dismissable banner on the portal notifying them of this access.
All the other users (i.e. requesters, agents added to only published workspaces, account-wide admins not added to in-setup workspaces explicitly) will not see this field but will continue to see the ticket form associated with the primary workspace.
NOTE: When the second workspace is published: - The workspace selection field will automatically become visible to all users across all support channels. - If you want to hide it before publishing the second workspace or later, navigate to Global Settings > Field Manager > Ticket Fields > Workspace Properties and Uncheck "Display to requester" to hide the field.Key points to remember: a) When hidden, the primary workspace’s form will be displayed by default, and tickets will be submitted directly to the primary workspace. b) These tickets can then be reassigned to the correct workspace via global workflows or manual reassignment. c) The above rule only applies to the support portal/servicebot. On the agent portal, the workspace selection field will always remain visible as long as the agent can submit tickets to multiple workspaces
Case 2: The account has multiple published workspaces and one or more in-setup workspaces
The workspace selection field will be visible to all users across all support channels.
Members of in-setup workspaces will additionally see their respective workspace listed as an option in the dropdown.
They will also see a dismissable banner on the portal highlighting this.
Other users (i.e. requesters and agents not added to any in-setup workspace) will not see the in-setup workspace listed in the dropdown.
Impact of publishing a workspace
Once an in-setup workspace (with published service items or solution articles) is published:
Expanded Visibility: The published service items and solution articles will become accessible to agents in other workspaces and all requesters, based on the configured visibility rules.
Ticket Submission: Requesters will be able to submit tickets directly to the workspace if the "Display to Requester" option is enabled for the workspace selection field.
How can admins publish a workspace to a limited set of requesters?
Before publishing a workspace to the entire organization, admins can restrict its visibility to a specific set of requesters by following these steps:
Limit Service Catalog Visibility:
Navigate to Workspace Settings > Service Catalog
Bulk update the requester visibility rule for service items, selecting the appropriate requester group instead of All Requesters.
Restrict Access to Solution Articles:
Go to Solutions (left navigation bar)
Bulk update the visibility settings of solution folders to include only the intended requester group.
Control Workspace Visibility on Ticket Forms:
Navigate to Global Settings > Business Rules> Create a New Ticket Business Rule
For requesters on the New/Edit Ticket Form, add a condition that restricts the rule to requesters who should not see the workspace listed in the Workspace Selection field.
Use the "Remove options" action for the workspace selection field, specifying which workspaces should be visible to those users.
