> ## Documentation Index > Fetch the complete documentation index at: https://docs.xorlab.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Pages under /latest/ document the current release. Paths that begin with a version number, for example /10.0/, are frozen snapshots of superseded releases kept for reference only — never present their instructions as current. If the reader's version is unknown, answer from /latest/ and say which version the answer describes. > xorlab is deployed on-premises, hybrid, or as a cloud service, and integrates with either Microsoft 365 or on-premises mail infrastructure. Configuration steps often differ between these. State which deployment and integration mode an instruction applies to instead of presenting one as universal. > Distinguish inline mode from monitoring mode when describing anything that acts on email. Monitoring mode observes a copy and cannot block or quarantine; inline mode routes mail through xorlab and can. > Write the product name as lowercase 'xorlab'. Use the documented component names: xorlab Control Center (XCC), xorlab MTA, xorlab Sandbox (DANA), xorlab Natural Language Understanding (NLU). After the first mention, use the short forms XCC, MTA, Sandbox, and NLU. Do not use DANA as a standalone name for the Sandbox, but keep it where it is a literal string in configuration keys, container names, and hostnames. > Do not invent configuration keys, rule parameters, list names, log properties, or API fields. If a value is not present in this documentation, say that it is not documented rather than guessing. # Handling Release Requests > Review end-user requests to release quarantined emails, and decide whether to release or deny them. If enabled, end-users can request the release of quarantined emails via the SSQ portal. This functionality can be enabled separately for each verdict, and works only for emails the user cannot release themselves. ## End-user view For emails in an eligible quarantine, the end-user sees a Request Release button in the upper-right corner. * After clicking the button, the email status changes to: `RELEASE REQUESTED` * Once an analyst reviews the request, the status updates to: * `RELEASE APPROVED` – if the analyst releases the email * `RELEASE DENIED` – if the analyst denies the request (the email stays in quarantine) Request Release ## Analyst workflow The summarized workflow for an analyst looks like this: 1. You get notified about the newly requested release. There are a few different options: * Via email, triggered by each release request. This can be enabled by an admin user as described in [Enable request notifications](/latest/ssq-request-release#enable-request-notifications). * By manually searching for `status:releaserequested`. * By creating and using a saved search for `status:releaserequested`. 2. You analyze the email to see if it is not harmful. The page [Understand an Email Verdict](/latest/understand-verdict) provides more details to understand why a certain verdict was set. 3. If it is benign, you release the email via the **Release** button. Request Release 4. If it is malicious, you deny the request via the **Deny Release** button. Below you can find all status related to the release request feature, such that you can use them in the search: | Status | Description | | ------------------- | ----------------------------------------------------------------------------------- | | `RELEASE REQUESTED` | An end-user requested the release for this email, but no action has been taken yet. | | `RELEASE APPROVED` | An analyst approved the request. The email has been released. | | `RELEASE DENIED` | An analyst denied the request. The email is still quarantined. | **Saved Search** Create a saved search for the status `RELEASE REQUESTED` to quickly access all pending requests.