Returning or swapping services follows the same structured logic as ordering services, but from a different angle. Instead of requesting something new, an existing service is changed, replaced, or returned.
As an administrator, your role is not to initiate these requests, but to review and approve them once they are submitted.
Swap or return requests are initiated directly on the service itself. The process is described in detail in the documentation and focuses on how a request is created from an active service.
Once submitted, the request does not execute immediately. It is routed into the approvals, just like a regular order.
If you want to understand how swap requests are created from a service, you can find the full step by step explanation in the documentation linked below.
For administrators, swap and return requests appear in the approvals view as changes.
While the flow is similar to approving an order, the context is different:
the service already exists
the request modifies or replaces it
no new service is being requested
This allows you to clearly distinguish between new orders and changes to existing services.
When reviewing a swap or return request, you see all relevant information needed to make a decision. This includes the affected service, the assigned employee or location, and the requested change.
From an admin perspective, this keeps the process consistent. Whether it is a new order or a service change, approvals always follow the same pattern.
Once the swap or return request is approved, the change is executed. The existing service is updated accordingly and continues through the standard fulfillment process.
This may include returning hardware, exchanging devices, or adjusting the service configuration, depending on the request.
Last updated
Was this helpful?
Was this helpful?