# Review delete requests

<div class="ng-access" markdown>
**Who can do this:** <span class="ng-badge ng-badge--superuser">Superuser</span> <span class="ng-badge ng-badge--admin">Admin</span> &nbsp;·&nbsp; **Where:** top navigation → **Delete Requests**
</div>

The approval desk for deletions. When someone requests deletion of a client, site, or piece of equipment, nothing happens until an admin approves it here — this page is the second half of every "Request Delete" button in NorthGrid.

<!-- SCREENSHOT: delete-requests-01.png — the three request panels with Approve and Reject actions -->

## Reading the page

Requests are grouped into three panels — **Client**, **Site**, and **Equipment Delete Requests** — each row showing what's to be deleted, who requested it, and when. Empty panels say so plainly (*"No pending client delete requests."*).

## Approve or reject

1. Verify the row — the name, the requester, the date. This is the last checkpoint.
2. **Approve** to carry out the deletion, or **Reject** to decline it. Either way the request leaves the queue, stamped with who reviewed it and when.

## What approval actually deletes

Approvals are deliberately conservative — deleting a container **detaches** its contents rather than destroying them:

- **Client** — the client record is deleted; its **sites are kept** and become *Unassigned* (they'll surface in the Dashboard's Unassigned Sites queue for reassignment or cleanup).
- **Site** — the site record is deleted; its **equipment is kept** and becomes unassigned (visible in the Unassigned Equipment queue).
- **Equipment** — the equipment record itself is deleted.

So approving a client deletion never silently erases years of equipment history — but it does leave orphaned sites and equipment for you to triage afterward. Plan the cleanup pass when approving a large client.

## Troubleshooting

**"Request not found or not pending."**
:   Another admin already handled this request (or it was withdrawn) between your page load and your click. Reload to see the current queue.

**I approved a client and now have a pile of unassigned sites.**
:   That's the detach behavior working. Work through the Dashboard's *Unassigned / Unapproved Sites* queue: reassign the keepers, delete the rest from [Manage sites](../sites-equipment/manage-sites.md).

**I rejected a request but the item still exists.**
:   Correct — rejecting declines the deletion; the record is untouched.

## Related articles

- [Manage clients](manage-clients.md) — where client delete requests originate
- [The Dashboard](../getting-started/dashboard.md) — the unassigned queues that catch detached records
