Move Request Across Customers
ServiceDesk Plus MSP Cloud allows you to move requests from one customer to another customer. This is useful when a technician creates a request under the wrong customer or identifies/associates the request with the wrong customer while handling it.
Prerequisites for Moving Requests Across Customers
To move a request across customers, ensure the following requirements are met:
Requirement | Details |
Permission | The technician must have the Move Request Across Customers permission. This permission is available by default for SDAdmin and SDSiteAdmin roles. For custom roles, administrators can enable it under Setup > Users & Permissions > Fine-Grained Access > Request > Edit. |
Customers | The MSP instance must contain more than one customer. |
Customer scope | If customer-based scoping is enabled, the technician must have access to at least two customers. |
Move a Request Across Customers
Use Move Request Across Customer option to transfer a request to appropriate customer without creating a new request.
To move a request across customers
- Go to Requests details page.
- Click Actions > Move Request.
- In Move Request pop-up,
- Select Across Customer.
- If your organization has multiple instances, select Across Customer or Across Instance, depending on where you want to move the request.
- If your organization has only one MSP instance, the Move Request pop-up opens with the Across Customer option selected by default.
Organization with multiple instances
Organization with single instance
- Enter the required fields:
- Customer: Select the destination customer. The current customer is not listed.
- Site: Select a site associated with the destination customer. If the destination customer has only one site, it is selected automatically.
- Template: Select a request template available for the destination customer. Customer-segmented templates are available only if the destination customer is associated with the template.
- Requester: Select an existing requester associated with the destination customer. If the requester does not exist, technicians with the Adding Requester permission can enter and add the requester directly from Requester field. When the request is moved, the requester is created under the destination customer and associated with the request.
- Comments (Optional): Enter why you are moving the request. The comment is recorded in the system log for the destination customer.
- Click Move.
Restrictions for Moving Requests Across Customers
You cannot move a request across customers under the following conditions:
Category | Details |
Request status | Request is closed, resolved, canceled, or has a pending cancellation request. |
Request source | Request was created from a maintenance schedule or generated from a contract expiry. |
Request relationships | Request is linked to another request or is the parent of merged requests. |
Tasks and checklists | Request contains completed tasks or completed checklist items. |
Worklogs | Request contains worklogs. |
Approvals | Request contains approved or rejected approvals. Note: Requests with only pending approvals can be moved. |
On Behalf Of (OBO) | Request has an On Behalf Of (OBO) user. |
Associated records | Request is associated with Problems, Changes, Purchase Orders, Projects, Solutions, Announcements, Spaces, Assets, Configuration Items (CIs), or other related records. Note: Remove these associations before moving the request. |
Request Movement Based on Request Origin
The ability to move a request across customers depends on how the request was created.
Request Origin | Can Be Moved Across Customers |
Created by an MSP technician | Yes |
System-created from an email sent by a user without login access | Yes |
System-created from an email sent by a user with login access | No |
Created directly by a requester with login access | No |
Requests created through customer-facing channels cannot be moved.
What Happens After the Move
When a request is moved across customers, some request details are retained, while others are updated based on the destination customer and request template.
Data That Is Retained
The following request information remains unchanged after the move:
Data | Description |
Request ID | Request retains its original ID. |
Subject and Description | The existing subject and description are preserved. |
Created Time | The original request creation time is retained. |
Tasks | Existing tasks, including task assignments, comments, worklogs, and dependencies, are retained. |
Tags | Existing tags are retained. |
Private Notes | Existing private notes remain unchanged. |
Attachments | Existing attachments are retained. |
Data Updated During the Move
The following request details are updated based on the destination customer and request template.
Data | Description |
Customer | Updated to the selected destination customer. |
Site | Updated to the selected destination site. |
Request Template | Updated to the selected destination template. |
Requester | Updated to the selected or newly created requester in the destination customer. |
Category, Subcategory, and Item | Updated based on the destination template. |
Group/Technician | Updated based on the destination template and selected site. If the group or technician configured in the request template is not associated with the selected site, the corresponding field is cleared. |
Priority, Impact, Urgency, Level, and Mode | Updated based on the destination template. |
Status | Updated to the default status defined in the destination template. |
Additional Fields | Updated using the destination template defaults. Fields that are unavailable or do not have default values are cleared. |
Conversations and Notes | Public conversations and notes are changed to private when the request is moved. |
Data Removed or Reset
The following information is removed or reset during the move.
Data | Description |
Email Notification Recipients | The To and CC recipients are cleared. |
Pending Approvals | Pending approvals are removed. Requests with completed approvals cannot be moved. |
Followers | Followers who do not belong to the destination customer are removed. |
Shares | Request shares are updated based on the destination customer's access. Invalid shares are removed. |
Drafts | Existing drafts are removed. |
Requester Reminders | Existing requester reminders are removed. |
Worklog Timers | Worklog Timers associated with technicians who are restricted to the destination site are removed. |
Workflow Timers | Active workflow timer executions are removed. |
Fields Not Available in the Destination Template | Values for fields that are not part of the destination template are cleared. |
Request Behavior After Moving Across Customers
The following table summarizes how different request settings are handled after a request is moved to another customer.
Feature | Behavior |
SLA | The application re-evaluates the request SLA based on the destination template and site. If the existing SLA is not applicable, it is removed and a suitable SLA is applied. Incident SLAs are site-based. If the site changes during the move, the application automatically evaluates and applies the appropriate incident SLA.Service SLAs are not site-specific. Use condition-based SLAs Same template: The SLA remains unchanged. Different template: The SLA is re-evaluated based on the conditions of the moved request. A new SLA is assigned if a matching condition-based SLA is found. If no condition matches, no SLA is assigned. Use SLA selected by the user Same template: The SLA remains unchanged. Different template: The SLA is cleared. If the destination template has a default SLA configured, it is assigned. If no default SLA is configured, no SLA is assigned. Use both user selected and condition based SLAs – Without Override Same template: The SLA remains unchanged. Different template: The SLA is cleared. The SLA assigned next depends on the destination template: • If the destination template has SLA associations and a default SLA is configured among them, the default SLA is assigned. • If the destination template has no default SLA, condition matching runs and an applicable SLA may be assigned. Use both user selected and condition based SLAs – With Override Same template: The SLA remains unchanged. Different template: The SLA is cleared. Condition matching runs based on the request field values after the move, and an applicable SLA may be assigned. The destination template's default SLA is not considered in this mode. |
Business Rules | The destination template's business rules are evaluated. If the request matches the configured criteria, corresponding actions are applied. |
Triggers | The destination template's triggers are evaluated, and applicable trigger actions are executed. |
Workflow/Lifecycle | If the destination template has a workflow or life cycle configured for the destination customer, it is applied to the request. The life cycle history entry is recorded at the time the request is moved, instead of the request creation time. |
Notifications | If enabled, request creation notifications are sent based on the destination customer's notification settings. |
System Log | The move operation is recorded in the system log, including the source customer, destination customer, request ID, and the reason for the move, if provided. |
Request History | The original request creation entry is retained. Previous history entries are removed, and new history is generated based on the destination customer's configuration. |
- When a request is moved to a template different from the source template, fields and user-defined fields that have values but are not available in the destination template are cleared.
- If the resolution contains only text and has no associated solution, the default Resolution value configured in the destination template is applied. If no default value is configured, the Resolution field is cleared.
- Active worklog timers associated with technicians who are not mapped to the destination site are removed when the request is moved.
- The Move Request option is not available for closed requests.
- When a request is moved, its status is updated to the default status configured in the destination template.
- After a request is moved across customers, the destination customer receives a request creation notification instead of a request update notification.
- Bulk move is not supported. Requests are moved one at a time.
- Moving the requester from one customer to another is not supported. A new requester from the destination customer must be selected or created from the Move Request across customer form itself.
- The destination request template determines the default values applied to the request after the move.
- Request continues to use the same Request ID after the move.