Last updated: 2026-01-27

Source: https://support.freshservice.com/support/solutions/articles/50000009671-workspace-organizer-usage-playbook

Workspace Organizer \| Usage Playbook

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

``` NOTE: The Workspace Organizer would be enabled only in accounts with business teams working out of the primary workspace. In case it's not enabled in your account and you want to leverage this utlity, please reach out to your success manager to get it enabled. ```

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 were enabled in your account AFTER you had started using Freshservice, 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 can achieve data segregation and admin autonomy by moving different business functions to dedicated workspaces of their own. This can be done using the Workspace Organizer, a utility tool built to make this process easier.

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

Workspace Organizer supports moving tickets and tasks in bulk only from the primary workspace to non-primary workspaces. Non-primary to non-primary, and non-primary to primary moves are not supported.

Play God admins permission is mandatory to clone configurations. They can clone configurations to restricted workspaces well.

Play God admins and agents who have been granted access to ‘Manage Workspaces" privilege will be able to bulk move tickets/tasks via the tool. Level of access to ticket data (for all agent groups or a particular agent group) in the primary workspace would determine what tickets or tasks can be moved using the Workspace Organizer.

Enterprise account admins can also create a workspace, and perform steps 1.1 and 1.2 in sandbox. Additionally, the move tickets/tasks tool can also be tested in sandbox. Once this is done, you can sync the global settings followed by local workspaces to production, create configurations in production that cannot be synced from sandbox, and go live.

Workspaces Organizer allows you to move tickets across any status, including Closed, Resolved, Open, and Unresolved. However, archived tickets cannot be moved.

Please contact our support team at support@freshservice.com if your tickets need to be unarchived in bulk so that they can be moved using the 'workspace organizer' tool. Depending on the complexity and volume of tickets, its feasibility will be evaluated and may take ~3 months or more to be facilitiated, if the request is accepted.

To understand the implications of moving Open and Unresolved tickets, please continue reading the guide. ```

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. (If there are multiple teams that need to be moved out of the primary workspace, the process remains the same)

Let's examine each step in detail, starting with the prerequisite of creating a new workspace if you don't have one already created.

Creating a new workspace

As blank workspaces do not have any sample data/settings, 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.

``` NOTE:

You can select non-blank templates as well. However, you might have to delete the sample data and configurations in them if you don't need them.

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.

Only agents added to the HR workspace can be given access to view its data. It can be configured by workspace agents as well as account-wide admins.

The newly created in-setup workspace (previously called draft workspace) will be visible ONLY to agents who are members of the in-setup workspace and account-wide admins. It will be visible to them in

- ‘Create’ and 'Filter' dropdowns - By default, in-setup workspace members will be able to create tickets/tasks in the in-setup workspace. For all the other modules (i.e problem, change, release, asset, contract, software, purchase order, etc), relevant permission to create them needs to be given in the target workspace. - ‘Move’ dropdown.

- If the in-setup workspace is of type business, it will be visible in the move dropdown of ticket, task, and other business workspace modules.

- If the in-setup workspace is of type IT, it will be visible in the move dropdown of ticket, problem, change, release, task, and other IT workspace modules.

``` NOTE: 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 Organizer workspaces 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 and tasks 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.


CONFIGURATION NAME	SUPPORTED
Core Workspace Settings<br>These settings could be referred to in other configurations. Hence these settings need to be selected first.
Form Fields (Tickets, Problems, Changes, Releases)	✅
Service Items	✅
Custom Objects	✅
Business Hours	✅
Agent Groups\*	✅
Advanced Workspace Settings
Workflows	✅
Business Rules	✅
Closure Rules	✅
Document templates	✅
SLAs and OLAs	✅
Change Lifecycle	✅
Credentials	✅
Email Notifications	✅
Agent Roles and Permissions	❌
Supervisor rules	❌
Canned responses	❌
Leaderboard	❌
Tags	❌
Schedulers	❌
Scenario automation	❌
Form Templates	❌
Satisfaction Survey	❌

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.

``` NOTE: 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 and other configurations that contain agent references:

Given that Agent Group names are unique in an account, the agent groups being cloned will be renamed 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 to the target workspace before cloning. It is fine to not give them any permission. If an agent is absent in the target workspace at the time of cloning, that agent will be dropped from the cloned agent group, workflow or any configuration that referred to that agent in the target workspace. In case you forget to add agents before cloning, you can add them later and clone the configuration once again from the primary workspace. This will overwrite the old configuration 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.

```

After you select the HR team's configurations, 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.

``` NOTE:

Agents do not appear as dependent configurations. It is pre-supposed that they will be present in the target workspace. If you miss adding them before cloning configurations, you can add them later and reclone 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 as the tool scans what is available in the target workspace vs what is present in the primary workspace.

```

This would bring you back to the configuration selection screen. The dependent configurations would also be selected at this stage. You will see a column named "Action" with Add or Update as values on this screen.

- 'Add' indicates that this configuration is not present in the target workspace and will be added to the target workspace. - As mentioned earlier, only in the case of 'agent groups', the value is always shown as "Add". However, if the agent group has been cloned earlier, we will not "Add" it but overwrite the old group. - 'Update' indicates that this configuration is already present in the target workspace and will be updated with the latest version in the primary workspace. - 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, Workspace Organizer 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

Service item-related placeholders, if referenced in any configurations such as workflows or email notifications, need to be manually updated after cloning those configurations. This requirement arises because, when service items are cloned, the new service item receives a different ID than the primary workspace service item. However, any placeholder inserted in your configurations is treated as text and gets copied as-is during cloning. Consequently, service item placeholders retain the ID of the primary workspace service item even after cloning. If not updated, these placeholders will prevent the configuration from working as expected.

Ticket Field placeholders will work as expected and point to ticket fields in the new workspace.

Only custom object settings will be cloned. Records will have to exported and then imported manually.

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 particular configuration hasn’t been cloned, you will be able to click on the config set to view 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.

```

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 via cloning in STEP-1.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 (the 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.

``` NOTE: 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 from the primary email. ```

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.

Scan all the admin settings (business rules, workflows) and list down the ones 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 downtime 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 the requester is checked). Uncheck them until your setup is ready.

You will now have replace the old custom fields with the new custom fields wherever they are referred to in your settings (for example: workflows, business rules, etc).

- Impacts:

- Any workflow or business rule that was supposed to execute on the old custom fields in existing unresolved tickets will not work as expected when the source configurations are updated. Therefore, you can also choose to duplicate/recreate these configurations and then update them with the global custom fields. The old configurations can be archived once all the existing tickets that they are supposed to execute on are resolved.

- Guide for updating configurations: If the configurations are going to apply to all workspaces, you can choose to recreate them manually in global settings. If they apply only to one team or specific workspaces, you can duplicate them within primary workspace and clone them to the specific workspaces.

Outcome:

- Your ticket form has 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 requesters but your agents will still be able to see them.

- You have a duplicate version of configurations ready in the primary/global workspace that should act on the global fields.

- The fields in global settings are as yet hidden from requesters. You can expose them to requesters now so that all the new tickets capture values in global fields.

Agent Form Setup

Agents will continue to see both the old fields and new fields in ticket create and edit forms. New tickets will capture values in the global custom fields whereas old tickets will have values in the primary custom fields.

You will have to maintain this setup for agents until you have resolved all the tickets that captured value in the old custom fields. If this could cause potential confusion, you can choose to create scheduled workflows to copy the values from old custom fields to new custom fields. Please note that scheduled workflows run only on unresolved tickets and on a limited number of tickets/hour.

When you no longer need the primary workspace custom fields or when the values have been copied over to global fields via scheduled workflows, you can archive the fields which will hide them from everywhere in the account except analytics. This will prevent loss of data and you will be able to continue to refer to them in reports.

Resolved tickets will continue to have values in the old custom fields. However, you will not be able to read values of archived custom fields. That data will be available only in analytics.

Before publishing the workspace: 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, submit a ticket via email, and see if the tickets are getting routed correctly.

``` 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 clone the old primary workspace custom fields to 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 remove these items from 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.

Employee onboarding: Update the target workspace of child tickets if required.

Move tickets and tasks (covered in detail in the next step)

Ticket Views, Dashboards, and Analytics reports:

- Ticket Views: - In default views, agents will be able to see tickets from all the workspaces they have ticket access in. - In custom/saved views: - If the view is NOT based on custom field filters, agents can update the workspace filter to "All workspaces" and see tickets from all the workspaces they have access to (in this case, it's IT and HR since they have tickets in both of them). Later, when the tickets are moved to HR and the agents are removed from IT workspace, "All workspaces" will show tickets only from HR. - If the view is based on custom field filters, agents can: - If all the tickets have been resolved and moved> update the workspace to HR and select the correct filters again - If some of the tickets have not been moved (as unresolved ticket movement isn't supported via the tool) > Create a separate view. The old ticket view can be deleted when all the tickets have been moved. - Dashboards: - Dashboards are based on ticket views. When ticket views are updated, the dashboards will show the correct information. If new ticket views have been created, the dashboard will have to be updated. - Analytics Reports: - If the report is based on global fields, the workspace filter can be updated to "All workspaces" - If the report has metrics based on custom fields, the report can - If all the tickets have been resolved and moved> Update the workspace to HR and select the metrics again - If some of the tickets have not been moved (as unresolved ticket movement isn't supported via the tool) > Clone the report and set HR as the workspace.

STEP-3:Moving tickets and tasks

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

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

Ticket and tasks can be moved independently irrespective of their association and the association would persist even after moving them to different workspaces.

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 in-setup 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.

```

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

NOTE: Impact of moving Open and In-progress tickets and tasks

``` Please be aware of the following implications while moving open or in-progress tickets.

Ticket SLA update: SLA and Business Hour policies added in the target workspace will be applied.

To maintain the first response times and due dates of tickets: 1. Clone SLAs and policies: Before transferring tickets, ensure you have cloned the relevant SLAs and business hour policies from the source workspace to the target workspace. 2. Preserve Order: Make sure the SLAs and business hour policies are in the same order in the target workspace as they are in the primary workspace. 3. Verify Ticket Statuses: Confirm that all relevant ticket statuses are present in the target workspace.

Workflow interruption: Ongoing workflows will be disrupted if a ticket is moved mid-process.

If a workflow is in progress on a ticket during its transfer, the workflow may fail to complete because the ticket might have already moved to another workspace. For example, consider an approval workflow where an approval request is sent before the ticket is moved. If the approval is granted after the ticket has already been transferred, the approval action will succeed. However, subsequent workflow actions may fail if they rely on attributes that are available only in the source workspace. Examples of such attributes are assign the ticket to an agent group in the primary workspace, update custom fields in the primary workspace, etc.

Status Page disruption: When an incident listed on the status page in the primary workspace is moved to another workspace, it will first be unpublished, removing all its information from the status page. Only then will it be transferred to the destination workspace.

Servicebot disruption: If an agent group is linked to a channel on Slack or Microsoft Teams, moving the agent group's tickets from one workspace to another will disrupt the notifications that were being pushed to that channel. This happens because the tickets are reassigned to a different agent group in the new workspace and the new agent group is not yet associated to a channel on Slack/Teams.

To resume notifications after the tickets have moved, go to your channel/team and change the linked agent group to match the new agent group in the target workspace. Slack: You can do it by visiting servicebot settings, disconnecting the old agent group and connecting the new group. More details here. MSTeams: You can dissociate the current team from an agent group and associate it with another agent group, by using the “@ServiceBot Reassociate” command. More detais here.

Any subsequent updates to the ticket will be pushed to the channel as before. ```

Here are the steps in the process

a. Navigate to the Move Tickets and Tasks flow

Start with the second step by clicking on the MoveTickets and Tasksbutton.

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. This is because agent group names are unique in the entire account so without this, the target agent group of a ticket cannot be identified.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.

``` NOTE: 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. Selecting tickets that need to be moved

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. Selecting tasks that need to be moved

Similar to the selection of tickets, you can select the set of tasks that you want to move by the filters available in the Move Tasks option.

``` NOTE: You can move all types of tasks, irrespective of their parent entity (i.e. tickets, problems, changes, releases) ```

e. 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 clone the missing fields/items to 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.

Youwill not see this alert for tasks as task fields are global and shared by all workspaces.

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 may 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.

In addition to missing fields/items, you will also be informed of any association types (eg: change association, etc) that will be removed if you move tickets to a business workspace. If any field/service item has been renamed by an admin after it was cloned, it will also be shown for your information. When the tickets are transferred, the ticket/service item field values will appear under a different field label due to this because internally, cloned fields remain mapped to their source fields in the primary workspace.

``` NOTE: Workspace Organizer 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. ```

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

f. Initiate Move

Please click on ‘Proceed’ to start the process. As 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. No file will be sent for tasks because task fields are global and there is no risk of losing values from custom task fields.

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

``` NOTE: The status page will auto-refresh every few minutes and may appear static. You 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 and tasks

The status of the ticket movement can be found under the Log 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.

``` NOTE: 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 all the tickets (open, in-progress, unresolved, and closed) 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 be applied on the moved tickets. However, tickets that are either ‘Closed’ or ‘Resolved’ will not be impacted. Also, any ticket where the first response time and due date was set manually will also not be impacted.

The "Last Updated At" date of tickets is not changed due to workspace move via the organizer tool.

Here is the detailed impact of moving ‘Incident’ and ‘Service Request’ types of tickets to Business workspaces.


Scenario	Impact	Reason
If the target workspace is of IT type	Entire ticket data can be transferred except on-call responder data.	Target workspace being of IT-type will support Incidents and Service Requests.
If the target workspace is of Business type	Incidents will be converted to ticket type ‘Case/Query/Request/Issue’ and will lose associations (if any) with Problems, Changes, Alerts, On-call responders, and Impacted Services.	Business-type workspaces only support ticket type ‘Case/Query/Request/Issue’ which does not support associations with Problems, Changes, Releases, Alerts, Oncall, and Services.
Service Requests will be converted to the ticket type Case/Query/Request/Issue’ and will lose associations (if any) with Changes.	Cases do not support associations with Changes.

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).

At a time, the tool will be able to support only one ticket movement activity for each account.

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

APPENDIX

Mapping ticket fields and service items between workspaces

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

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 within "Move tickets and tasks" 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.

Mapping fields and values:

- If you are using the Workspace Organizer's "Clone configuration" option to copy the fields, the mapping would be automatically created and would persist even if you update the field name in the destination workspace after cloning the field.

- If you are creating the fields manually, then 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:

- If you are using the Workspace Organizer's "Clone configuration" option to copy the service items, the mapping would be automatically created and would persist even if you update the service item name/fields in the destination workspace after cloning the service item.

- If you are creating the service items manually, then 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.