Here is a detailed guide on how to clone configurations and move existing tickets to a new workspace using the Workspace Setup Assistant.

Workspaces allow you to easily bifurcate service management operations between different functions such as IT, HR, Facilities, Finance, etc. This can provide the desired level of administrative autonomy and data segregation for different teams in your organization, yet offer a unified support experience to your employees through a one-stop service management portal.

However, if workspaces have been recently enabled in your Freshservice account, there could be a scenario where all the data and configurations pertaining to different functions might be residing in a single workspace. 

Here is a self-serve guide on how you should copy configurations from one workspace to another and move data using the Workspace Setup Assistant, a utility tool built to make this process easier. 

TABLE OF CONTENTS

• Prerequisite: Creating a new workspace
• STEP-1.1: Cloning configurations to the target workspace.
• STEP-1.2: Setting up the channels for incoming tickets
• STEP-2: Going live with the new workspace
  
• STEP-3: Moving tickets
  
• APPENDIX

Before we begin, here’s what you should know: 

- Workspace Setup Assistant is a temporary tool to enable teams that signed up for Freshservice before workspaces were launched to split their configurations into multiple workspaces. As such, the tool will be available only for 6 months from the date of activation in the account. After 6 months, the tool will be disabled and access to it will be removed.

- Workspace Setup Assistant supports moving tickets in bulk only from primary to non-primary workspaces. Non-primary to non-primary, and non-primary to primary moves are not supported.

- Only resolved or closed tickets can be moved. This is to ensure that the workflows and SLA policies executing on your existing tickets are not impacted. 

- An agent who has been granted access to ‘Manage Workspaces, Agents, Agent Groups, and Roles’ privilege at an account-wide level and access to ticket data (for all agent groups or a particular agent group) in the primary workspace would be able to use the Workspace Setup Assistant to move accessible data.

Let’s get started with an example scenario:

IT and HR currently operate out of the primary workspace. HR wants its own workspace and needs to move its data and configurations to the same.     

Let’s look at each of these steps in detail. 

Prerequisite: Creating a new workspace

Create a new workspace using the ‘Blank’ template and choose the relevant primary business function during workspace creation. In our scenario, this would be ‘HR’. 

Choosing any business function other than IT will create a ‘business workspace’. If the second team is IT-affiliated and will not require the business agent license, you can select ‘IT’ as the primary business function. This would create an ‘IT workspace’. Creating the right type of workspace is important as it will determine the functionalities IT and Business agents will be able to access. 

Here is an article to understand the difference between IT workspaces and Business workspaces. 

Workspace type once selected (IT/Business) cannot be changed after workspace creation.

Here are some important points to note at this stage:

• HR agents are still in the primary workspace and will continue to handle tickets in the primary workspace.

• The newly created workspace and any content added to it WILL NOT be visible on the requester support portal/virtual agent bot until the new workspace is published.

• The newly created draft workspace will be visible ONLY to agents who are members of the draft workspace in

  • ‘Move’ dropdown.

  • ‘Create’ dropdown (ticket, problem, change, release)

• Only agents added to the HR workspace can be given access to view its settings and data.

Please read the agent, requester, and admin sections of this article to clearly understand what happens in a multi-workspace setup.

STEP-1.1: Cloning configurations to the target workspace.

a. Navigate to the tool 

1. Go to Account Settings > Manage workspaces. 

2. Click on the Workspace Setup Assistant button at the top right part of the screen.

3. In the next panel, you will see a two-step process that lets you

   1. Clone configurations from the primary workspace to a target workspace. 

   2. Move tickets from the primary workspace to a target workspace. 

For step(a), click on the Clone Configurations button. 

b. Create a config set

As the next step, you will be prompted to create a config set. A config set enables admins to group together configurations that have to be copied over to the target workspace.

1. Click on the Create Config Set button on the top right.

2. Provide a name to the config set and select the target workspace to copy the configurations. 

c. Add configurations to the config set

As the next step, you would have to add the configurations that need to be cloned to the target workspace. 

Review the following table to see the list of configurations that are supported by the tool. 

• Select all the configurations that you want to copy over to the target workspace and click on Save and Continue. Each configuration is clickable and opens the corresponding settings page in a new tab. This helps you review the configurations before adding them

. 

Up to 250 configurations can be cloned using each config set. In case you plan to clone more than 250 configurations, please split them into multiple config sets.

Key points regarding cloning agent groups: 

- Given that Agent Group names are unique in an account, the agent groups being cloned will be named as “<workspace name>_<agent group name>” in the target workspace. This keeps the agent group name unique and prevents duplication. 

- Agents have to be explicitly added as members of the target workspace from the workspace’s settings page. It is fine to not give them any permission. If any agent group member (agent) is absent in the target workspace at the time of cloning, that agent will be dropped from the cloned agent group in the target workspace. 

- If you are cloning configurations in multiple batches and you have already moved agent groups in the 1st batch, here is the expected behaviour for the 2nd batch. In the 2nd batch, if you try to move a configuration that refers to any of those agent groups from the first batch, the agent group will appear as a dependency and you will have to add it to the config set. However, once the cloning is done, the old agent group created in the first batch will be updated and a duplicate agent group will not be created. 

• The tool then computes the set of configurations that have not been added to the config set, but are referenced by the configurations in the config set.  You need to add these dependent configurations to the config set to move forward. This step ensures that the copying process is comprehensive and all the configurations work seamlessly in the target workspace. Click on the Add Dependencies button to add the dependent configurations. 

If a dependent configuration has already been moved earlier and is present in the target workspace, it will not be tagged as a dependency.

• This would bring you back to the configuration selection screen. The dependent configurations would also be selected at this stage. Make changes to your selection if required, or proceed further by clicking on the Clone Configurations button.

• The cloning of configurations would now be initiated. You will be redirected to the page that has the list of all config sets so that you can track the status. Once the status shows Completed, all the configurations in the Config set will have been copied to the target workspace. 

• As you know, the setup assistant does not clone certain configurations. Please ensure that you recreate those configurations manually (if required) before moving on to the next steps. 

Important points to note

- It is recommended that you do not modify ticket fields and service items in the target workspace after they have been cloned. This is because the ticket move tool (covered in the next step) will look for an exact match of configurations between the primary workspace and the target workspace when it is about to move tickets.

- If the clone status shows as Failed or Partially Successful, please add a new config set and ensure that the errors highlighted are resolved in the new set. If any configuration hasn’t been cloned, you will be able to click on the config set to understand the reason for failure. 

- The order in which configurations are present in the primary workspace may not be preserved in the target workspace. Please review and if required, re-order the configurations in the target workspace after the cloning process is completed.

- Field values are not transferred for archived fields. 

STEP-1.2: Setting up the channels for incoming tickets

Once the settings have been added, we have to set up the channels via which incoming tickets will flow into this workspace. There are three primary channels for the same:

1. Service Items

We have already created the same in STEP-1. These are in the draft state currently and can be published only after the workspace is published.

2. Emails

A particular support email id can only be added to one workspace and cannot be present in two workspaces at the same time. If you have the HR team’s email ID added to the primary workspace, tickets will continue to flow in via emails to the primary workspace. Deleting that email id and adding it to the second workspace will disrupt the incoming ticket flow when the second workspace is not completely set up. 

The recommended time to do this is right before or right after publishing the second workspace. This ensures that the right SLAs and workflows are applied to them and agents are ready to act in the second workspace. Any support email received up to 24 hours before re-adding the email will be created as a ticket in the second workspace.

    3. Support portal “Report an issue form”

Please evaluate the following scenarios and take the necessary steps accordingly:

Scenario 1: You have a generic ticket form that only has default fields and you haven’t added any custom fields of your own. 

Goal: You want to continue with the current setup. 

Action to be taken: 

The form that is required to be exposed to requesters in this case is the primary workspace’s form (global form cannot be exposed on its own). Since the primary workspace’s form is ready, there is no re-configuration required here. 

However, via this form, all the tickets will be sent to the primary workspace because the form belongs to the primary workspace. As such, you will have to create a global workflow to direct tickets to the HR workspace on the basis of conditions such as ‘Subject contains X, Y, Z keyword’. The workflow should ideally be in the deactivated state until the second workspace is published. If you want to test it out, you can activate it temporarily and submit sample tickets to see if the workflow is working as expected.

Since tickets are created in the first workspace in this case, email notifications (such as ticket create notification, etc) present in the first workspace will be triggered.

Once the second workspace is published later, the workspace selection field will be automatically shown to requesters in the ticket form. Since you plan to expose only the primary workspace's form and therefore, not expose workspace selection to requesters, you will have to go to Global Settings >Field Manager > Workspace and uncheck ‘Display to requesters’. This will hide the workspace dropdown from the requester form and requestors will only see the primary workspace’s form.

Please note that agents will still see the workspace selection field in their agent portal ticket form. Agents can select a workspace and raise tickets directly to the respective teams.

Situation 2: Your current form has both default and custom fields. The form isn’t customized for individual teams using business rules and the custom fields are applicable to all teams in the primary workspace.

Goal: You want to continue with this setup but want to have teams across workspaces.

Action to be taken:

Let’s first understand the pros and cons of continuing with the current setup:

Pros: 

1. No-reconfiguration required.

2. Since the current form will be used, if any fields are referred to in apps/workflows, they will not be impacted.

3. Historical tickets will not be impacted as the fields remain as is.

Cons: 

As the form is created in the primary workspace, future tickets will first be created there and when they are moved to the second workspace during regular operations via workflows/manually, custom field values will be lost as those custom fields are present in the primary workspace.

Recommendation: Update the existing form by adding custom fields in global settings and hiding custom fields from the primary workspace. Global custom fields are shared by all the workspaces and therefore, their values are not lost when tickets are moved across workspaces.

Process: 

• The form that is required to be exposed to requesters in this case is the primary workspace’s form (this form will be updated with global fields). However, you need to hide existing custom fields and re-create them in global settings. 

• List down all the admin settings (business rules, workflows) that refer to these custom fields. These settings will have to be updated later.

Since you are performing changes on a live form, it is advisable to announce a down time to users before you start this or you can perform it during out-of-office hours.

    Requester Form Setup

• The primary workspace’s custom fields should not be deleted because they are still present in your historical tickets. You can therefore hide them from requesters by unchecking “Display to requesters”.

• Rename custom fields in Primary Workspace by appending "-tmp" [so that admins/agents are able to differentiate between old and new fields]

• Re-create the fields now in global settings and save the settings. These fields will be immediately exposed to requesters (if display to requester is checked).

• Replace the old custom fields with the new custom fields wherever they are referred to in your settings (example: workflows, business rules, etc).

• Create a new global workflow that will move any future incoming ticket to its target workspace. This workflow can be activated right after publishing the workspace or if you want to test it, you can activate it before that and see if the tickets are getting routed correctly.

• After performing this, your ticket form will have a copy of each custom field - one created in the primary

            workspace and the other created in global settings. The fields in the primary workspace will be hidden from 

            from requesters but your agents will still be able to see them.                             

Agent Form Setup

• Agents will continue to see both the old fields and new fields in ticket create and edit forms. To avoid this, archive the old custom fields. This will prevent loss of data and you will be able to continue to refer to them in analytics.

• It is suggested that this be done when your agents have resolved all the open/in-progress tickets. For unresolved tickets, you can also copy the values over from old custom fields to new custom fields using scheduled workflows so that the old custom fields can be archived sooner.

Important points to note: 

- You plan to use global custom fields going forward but your historical tickets still have values in the primary workspace's custom fields. When you move HR tickets later to the HR workspace using the Move Tickets tool (covered in the next step), field values present in primary workspace's custom fields will not be copied over to the new global custom fields you've created above. This is because the move tickets tool supports transferring data only from a local workspace field (primary) to a local workspace field (target). If you want to preserve the values in such fields, you can additionally add custom fields in the target HR workspace for the sake of retaining this old data. When you do this first and then move the tickets, the values will be copied over. These fields can be archived/hidden using business rules once the values are copied over. With this, the data of new tickets will be captured in global custom fields, and the data of existing tickets will be preserved in these workspace-level custom fields. 

- If ticket form fields are explicitly referred to any app that you have installed from the marketplace, please update the settings. An example could be an app that maps ticket fields between Freshservice and a third-party tool. Apps that refer to ticket form fields can only refer to the form present in the primary workspace.

Situation 3: You currently have a dynamic form to suit the needs of different teams in the first workspace. 

It is set up with the help of business rules and the form shows different fields on the basis of any previous selections made in the form. For example, if the category is Hardware, it shows hardware-specific fields. If the category is Payroll, it shows different fields.

Goal: You want to continue with the current setup

Recommendation:

In this case, it is recommended to let requesters choose the workspace in the ticket form and raise the ticket directly to that team. IT and HR Admins can choose to further customize their workspace forms as per their needs. For example, let the requester choose IT or HR in the ‘Issue related to’ default field that is exposed when you publish the second workspace. Selecting either of the options will load that particular workspace’s local form. 

If you go ahead with this, you should:

• Ensure all the HR custom fields are cloned/recreated in the HR workspace. IT-specific custom fields can remain in the primary workspace.

• Expose the workspace selection field to requesters during/after you go-live.

Note:

Do not delete the HR fields from the primary workspace just yet. This is because the move tickets tool will only let you move closed/resolved tickets and therefore, you will have some open/in-progress HR tickets in the primary workspace. Therefore, before you are ready to go live:

• Hide the HR fields from the new ticket form using business rules in the primary workspace.

Post go-live:

• Once all the open and in-progress HR tickets have been resolved/closed, you can move them to the new workspace and delete the HR fields from the primary workspace.

On the other hand, if you are keen to go ahead with the current setup only where there’s one team controlling the setup, you should proceed with the solution mentioned in Situation 2 and the entire form will have to be recreated in global settings. However, dependent field relations/dynamic form relations between global field values and workspace field values, cannot be created.

STEP-2: Going live with the new workspace

The next step is to publish the new workspace. Ensure that you check off the below action items:

Before publishing

• Manage old service items in the primary workspace: Bulk-update their status to ‘Draft’. This will not impact existing tickets.
• Ticket form setup: Depending on the ticket form setup you need, perform the necessary actions to show/hide fields to requesters.
• Ensure that the email setup is done: Delete the HR email configuration from the first workspace and add it to the second workspace.

The workspace can now be published to requesters. Tickets will now start getting created in the new workspace.

After publishing

• Show/Hide workspace field in requester ticket form: If you need to hide the field, hide it from Global Settings>Field Manager>Workspace Field>Uncheck “Display to Requester”.
• Move any solution article folder, article, asset, contract, or PO that belongs to the new workspace from the primary workspace. Solution articles should not be moved when the new workspace is still in draft as they will disappear from the support portal.
• Employee onboarding: Update the target workspace of child tickets if required.

STEP-3: Moving tickets

Once the necessary configurations have been successfully cloned to the target workspace, we move to the last step of moving the tickets. 

Here are some important things to keep in mind before you initiate this step: 

- Only Resolved or Closed tickets will be considered. This choice stems from the fact that open tickets might contain ongoing activities managed by agents or workflow automations, which could be disrupted if moved. Hence, it is recommended to resolve all the tickets that you want to move from the primary workspace to the target workspace.

- Only tickets accessible to you will be included; any tickets inaccessible due to agent group restrictions will not be considered.Tickets can be moved while the workspace is in draft mode. They will continue to be visible on the support portal to the corresponding requesters. 

- Despite service items being in draft state in the target workspace, they will still get attached to the transferred tickets.

- If you have chosen to retain some of the old tickets in the primary workspace instead of moving them, it is suggested that you do not delete their ticket fields and instead archive them. This ensure that the field values don't get deleted and you retain the ticket data. Workflows and Service Items can be deleted. 

Read this note to understand the logic followed for mapping ticket fields and service items between workspaces to ensure successful movement of tickts

Here are the steps in the process

a. Navigate to the Move Tickets flow

Start with the second step by clicking on the Move Tickets button. 

b. Create agent group mapping 

As the first step, you will be prompted to create a mapping between agent groups of the primary and target workspaces. The agent group assigned to the ticket in the primary workspace will be replaced with the mapped agent group when the ticket is moved to the target workspace. 

This mapping will be saved for all the upcoming runs between the selected pair of workspaces. Please note that the agent assigned to the ticket should be present in the mapped agent group in the target workspace, otherwise, the transfer of the respective ticket will fail. 

If no mapping exists for a particular agent group in the primary workspace or the agent group is deleted after creating the mapping, that ticket will not be moved. The latest updated state of the mapping of agent groups will be considered at the time of any move activity.

c. Set the ticket filter conditions 

As the next step, you need to filter the tickets you want to move from the primary workspace to the target workspace. You may choose a combination of filter criteria such that all the tickets that you want to move get covered. Please note that the ‘AND’ operator is used when multiple conditions are added and at a time, only 10,000 tickets can be moved. In case, more than 10,000 tickets get selected by the filter criteria, you would be asked to add stricter filter rules. You can use the ‘Ticket Created At’ date filter to reduce this count and move the remaining tickets in the next batch (by running the tool again). 

d. Verify the configurations in the target workspace 

As you click on ‘Proceed’, you will be able to see the list of all the ticket fields and the service item fields which are associated with the filtered tickets but are not present in the target workspace. Please review this list and create the missing fields/items with the same name (case-sensitive) in the target workspace. If a particular ticket field is not relevant to the team that will work in the target workspace, you can skip creating that field. 

The list will not show any value option that you have missed adding in the target workspace (for fields of the type Dropdown, Multidropdown, or Dependent). Please verify that separately before proceeding further. If they are not added and the tickets are moved, the tickets will show a read-only text of the old value for reference. However, since the value is not actually present in the drop-down, you will get an error message when you update the ticket properties. 

Workspace Setup Assistant supports transferring data only from a local workspace field (primary) to a local workspace field (target). The custom field values will not be copied from the primary workspace to global custom fields.

If you choose to proceed without creating the missing fields, these fields will be dropped from the transferred tickets, and they cannot be recovered.

e. Initiate Move 

Please click on ‘Proceed’ to start the process. Before it begins, you will receive a CSV export via email of the list of tickets that are going to be moved and their field values. This acts as a backup of the state of tickets before the move. 

Once the transfer begins, you can monitor the status on your screen. 

The status page will auto-refresh every 5 minutes. You may refresh it manually to see the latest status of the tickets. It will typically take ~10 minutes for a batch of 10,000 tickets to be moved.

f. Status check after moving tickets

The status of the ticket movement can be found under the Moved Tickets History page, where past ticket movement runs are also logged in. You may download the list of tickets that got moved (or failed to move) with their appropriate status. In case of any failures, the reason for failure will be logged as well. You can fix the gaps and run the ‘Move tickets’ step again. You will also receive an email with the ticket movement report. 

The ticket ID of every ticket will remain the same during the ticket movement process. However, the ticket type will change as per the target workspace. Eg: INC-123 will change to REQ-123. 
Here is an article to learn more about ticket types.

Once the tickets are moved, delete the service items, ticket fields, and workflows of the team that has been relocated to the new workspace.

Important points to note related to moving tickets

• The movement of tickets itself will not cause any automation flows to get triggered. (For instance, a workflow automation configured to be triggered on the event “Workspace is changed to {target_workspace}” will not be triggered due to the movement process.) However, once the tickets are moved, changes to the tickets might trigger automation flows in case the trigger conditions match. This includes all automation flows like Event Workflows, Supervisor Rules, Scheduled Automation, etc. 
• SLA/OLA policies of the target workspace will not impact the moved tickets because the status of tickets would be either ‘Closed’ or ‘Resolved’. DueByDate will also not be changed for the moved tickets. 
• Here is the detailed impact of moving ‘Incident’ and ‘Service Request’ types of tickets to Business workspaces.

• When a parent incident has a child incident attached to it and the parent incident is moved to a business workspace, the parent incident will get converted into the ticket type enabled in the target workspace (Case/Query/Issue/Request). However, association with the child incident will be maintained despite this not being supported by business workspace ticket types.
• Movement of Major Incidents is not supported by this tool. However, it will be supported in the near future (by June 2024).
• At a time, the tool will be able to support only one ticket movement activity for each account.
• The tool will clone the custom object settings. You can export and import the data once the custom object settings are cloned.

Please reach out to support@freshservice.com for queries, if any. 

APPENDIX

Mapping ticket fields and service items between workspaces

This mapping is only maintained when tickets are moved using the Workspace Setup Assistant. It is not maintained when tickets are moved via Move or Bulk Move options on ticket details/list page

• Mapping fields and values: The setup assistant will create a mapping for this on its own. To ensure successful mapping, each field name and value option in the target workspace should be an exact match of the original field name/value in the primary workspace. The name match for fields and value options would be case-sensitive (eg: 'location' will match with 'location' and not with 'Location'). Please note that the order in which fields/value options are created in the target workspace is not important.

• Mapping service items: The setup assistant will create a mapping for this on its own. To ensure successful mapping, the names of the recreated service items and the service categories they belong to in the destination workspace should exactly match (case-sensitive) with the original settings in the primary workspace. For example: A ticket has a service item associated with it called “Oracle Access” and it is under the ‘Applications’ folder in the primary workspace. For this ticket to be able to map with the new service item in the target workspace (after it’s moved), there should be a service item called ‘Oracle Access’ under the ‘Applications’ folder in the target workspace too. If the category is not found or the item is not found under the category, the ticket will not be moved. Please note that the tool simply matches the names of service items and service categories to find a match. Other service item properties such as description, visibility rules, etc. need not match for the mapping to be successful.

• Mapping agent groups: Since an agent group’s name has to be unique in the entire account, an exact name match of agent groups does not work because you cannot recreate an agent group with the same name as in the primary workspace. Therefore, once you create agent groups in the destination workspace, the tool will let you map them to agent groups in the primary workspace. For example: If tickets assigned to the ‘HR Team’ in the primary workspace need to be assigned to the ‘Payroll’ team in the destination workspace, the mapping tool will allow you to define the rules. Please ensure that the agents assigned to the tickets being moved are also added to the mapped agent groups in the destination workspace. For example, if a ticket is assigned to the agent group ‘HR Team’ and the agent ‘‘Andrew Smith’, Andrew has to be present in the ‘Payroll’ agent group in the destination workspace (‘Payroll’ is mapped to ‘HR Team’) for the ticket transfer to be successful. The exact mapping process will be explained in detail in a subsequent section of this guide.