# Cancellation Requests

https://docs.wisecp.com/fr/cancellation-requests

Answer every cancellation your clients have asked for from a single queue: read why the request was opened, see how urgent it is, and approve or discard it without opening the services one by one.

## Reaching the Screen

Open **Orders › Cancellation Requests** in the left menu: `{admin}/services/cancellation-requests`

The menu entry carries a counter of the service level requests still waiting for a decision, so a new request announces itself while you work elsewhere.

Staff holding either the service viewing or the service operation privilege can open the screen. Everything that changes a request is drawn only for the operation privilege: the selection column, the **Apply to Selected** list and the **Delete** entry in the row menu.

## What Is on the Screen

The page is one list with a short control strip above it. There is no form to fill in: a request is read in a window and answered with one of two decisions, approve or delete.

### Where the requests come from

Rows are written by clients, not by staff. From the service page in the client area a client picks a reason, adds an optional explanation and message, chooses the urgency and confirms with the account password. The request lands here as **Pending Approval** and an administrator notification goes out at once.

Add-on cancellations differ on purpose. A client cancelling one add-on from the Add-ons tab produces a row that is already **Approved** and always carries **End of Term**: it was not decided by an operator, it is waiting for the term to end. The add-on is named on a badge under the service name.

A client can withdraw a request while it is pending or approved, and the row then leaves the list on its own. Only one open request exists per service or add-on.

### The control strip and the filters

Above the list sit two selects. **Apply to Selected** runs one decision on every ticked row and appears only with the operation privilege. **Status** narrows the list to **Pending Approval** or **Approved**. On a narrow screen both are folded behind the **Show Options** button at the top of the page.

The table adds its own header: a search box, a page size selector and, for staff allowed to export tables, a download control shown as a downward arrow icon offering CSV, JSON and XML. The search matches client, company, service and add-on names as well as the e-mail address, and the line under the table reports how many records the filter left.

### The request list

Requests still waiting are listed first, approved ones after them, newest first inside each group. Clicking the **Request Date** header sorts by date instead.

| Column | What it shows | Notes |
| --- | --- | --- |
| Selection | Puts the row into a bulk decision. | Operation privilege only; the header checkbox takes the whole page. |
| Client | Service owner, with the company name underneath. | Opens the client record for staff allowed to view it; a plain name otherwise. |
| Service | The targeted service, with its number underneath. | An add-on request adds a badge with the add-on name. |
| Request Date | When the client opened the request. | In your date format, with the elapsed time next to it. |
| Priority | **Immediate** or **End of Term**, as the client chose it. | Decides what your approval does. |
| Reason | First fifty characters of the client's reason. | A longer reason gets a **View** button. |
| Status | **Pending Approval** or **Approved**. | Approved rows stay as the record of the decision. |
| Actions | Row menu: a vertical three dot icon labelled **Actions**. | Holds **View** and, with the operation privilege, **Delete**. |

### Immediate and End of Term

**Immediate** cancels the service the moment you approve: its status switches to cancelled and, for a service bound to a module, the teardown runs inside the approval request itself, not through the module queue. If the module refuses the call, the approval is not recorded at all: the status does not change, the invoice lines stay where they are, the request remains at **Pending Approval** and no queued job appears.

**End of Term** tears nothing down yet. The request is stamped approved with your name and time, and an hourly automation task cancels the service when its due date arrives. That task only runs inside the processing window of the automation settings (start and end hour, 09:00 to 18:00 by default), so a service whose due date falls overnight is cancelled once the window opens, not at the exact moment the date turns. Until then the client keeps using it and can still withdraw the request.

Both priorities end the billing relationship at approval time (see Things to Watch).

### The request window

The window opened by **View** is where a request is actually read. A coloured strip at the top repeats the priority, the request date and the status; below it the client and the service sit side by side, the service carrying the **In Use** and **Remaining** day counts that show whether an immediate cancellation throws away a paid period.

Then the reason, the **Client Feedback** block when the client wrote one, and for an approved request a green block naming the operator and the time.

The buttons follow the state: **Delete** is always on the left, while **Create Ticket** and **Approve** appear only until the request is approved.

## Fields

- **Apply to Selected**: Optional, empty by default. Choosing **Approve** or **Delete** opens a confirmation window for the ticked rows; the select then clears itself afterwards.
- **Status**: Optional, empty by default, which lists every request. The two values are **Pending Approval** and **Approved**.
- **In Use**: Read only, in the request window. Days spent in the current billing term of the service.
- **Remaining**: Read only, in the request window. Days left until the due date of the service.
- **Client Feedback**: Read only. Free message the client wrote while cancelling; not printed when left empty.
- **Approved By**: Read only. Operator who approved the request and when.

## Tasks

### Approving a single request

1. Find the row, open the row menu with the vertical three dot icon at its end, labelled **Actions**, and choose **View**. A long reason also carries a **View** button in the Reason column.
2. Read the priority, the reason and the client feedback, and check the **In Use** and **Remaining** badges.
3. Choose **Approve** at the bottom of the window.
4. The window closes and the list reloads: the row now reads **Approved**. An immediate request has cancelled the service already, an end of term one waits for the due date.

### Approving several requests at once

1. Tick the checkbox in the first column of every row you want; the checkbox in the column header takes the whole page.
2. Open the **Apply to Selected** list above the table, on a narrow screen after pressing **Show Options**, and choose **Approve**.
3. The confirmation window names how many requests were selected; confirm with **Approve** at its bottom.
4. The list reloads with every processed row showing **Approved**. Requests are handled one by one, so mixed priorities in one selection are treated correctly.

### Deleting a request

1. For one row, open the row menu and choose **Delete**. For several rows, tick them and choose **Delete** in the **Apply to Selected** list.
2. Read the confirmation window, which names the service for a single row and the count for a selection, then confirm with **Delete**.
3. The rows disappear without a page reload. The service itself is untouched, and the client sees the request gone from the client area.

### Asking the client before deciding

1. Open the request window with **View**.
2. Choose **Create Ticket**, the green button at the bottom, shown only while the request is not approved. The form opens in a new browser tab with this client already selected.
3. Come back to the queue tab: the request is still waiting, so a retention conversation never changes its state by itself.

## Things to Watch

> **Approval closes the billing relationship for both priorities**
> 
> Open invoice lines of the service are removed and invoices left with nothing on them are cancelled, end of term requests included: a renewal must not stay payable for a record already scheduled to end. Restoring those lines is manual work in the invoice screens.

> **An immediate approval reaches the server**
> 
> For a service bound to a module the teardown runs while the approval request is still open, so the account on the remote panel goes too. There is no undo on this screen, and the remaining days shown in the request window are lost. If the module refuses the call the whole approval is dropped: the request stays at **Pending Approval** and there is nothing to retry in the module queue.

> **A bulk approval stops at the first row it cannot resolve**
> 
> Requests are handled one after another. If one of them cannot be resolved, the run stops there: everything approved up to that point stays approved and is not rolled back, the rows after it are left untouched, and the list does not refresh itself. After an error message, reload the page and read the **Status** column of the rows you picked.

> **Deleting removes the request, not a cancellation that already happened**
> 
> Deleting an approved end of term row also stops the scheduled cancellation: the automation task no longer finds a request to apply. Invoice lines dropped at approval time do not come back, and the client has to open a new request if the cancellation is still wanted.

## Required Privileges

Opening the screen and reading a request need `SERVICES_LOOK` or `SERVICES_OPERATION`. Approving and deleting need `SERVICES_OPERATION`, wherever they are started from.

## Related Articles

- [Cancelling a Service](https://docs.wisecp.com/en/cancelling-a-service)
- [Services](https://docs.wisecp.com/en/services)
- [Service Addons](https://docs.wisecp.com/en/service-addons)
- [Service Transfer Requests](https://docs.wisecp.com/en/service-transfer-requests)
- [Creating a Ticket](https://docs.wisecp.com/en/creating-a-ticket)
- [Automation Overview](https://docs.wisecp.com/en/automation-overview)