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



TABLE OF CONTENTS


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.

- Only resolved or closed tickets and completed tasks can be moved. 
COMING SOON: We would be supporting the movement of Open and In-progress tickets and tasks by the end of July 2024.

- 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, Agents, Agent Groups, and Roles’ privilege at an account-wide level 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.



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 draft workspace will be visible ONLY to agents who are members of the draft workspace and account-wide admins. It will be visible to them in 

    • ‘Create’ and 'Filter' dropdowns

      • By default, draft workspace members will be able to create tickets/tasks in the draft 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 draft workspace is of type business, it will be visible in the move dropdown of ticket, task, and other business workspace modules.

      • If the draft 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. 



  1. Click on the Organizer workspaces button at the top right part of the screen.



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



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

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.

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


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 resolved or closed tickets and completed tasks 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 and then . However, we would soon be supporting movement of Open and In-progress tickets and tasks. 

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


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



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 Move Tickets and Tasks 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. 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. 


You will 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 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. 
  • 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.