Message operations and searches are **asynchronous**. Searches have their own status/results resources and progress display; a search ID is not an operation job ID. The API accepts the request (HTTP `202`) and the work runs on a separate background worker. Each operation is tracked as a job so you can monitor its progress to completion and read an execution report.

## Jobs list

The Jobs page provides:

-   search across job ID, environment, VPN, queue, submitter, reason, and change reference
-   filtering by job status
-   filtering by operation type
-   configurable visible columns
-   pagination
-   a link into each job detail view

## Job statuses

The API status vocabulary includes the values below. Normal execution uses accepted/queued, running and a terminal result. Approval-related values are reserved states: v1.7.1 does not expose a customer approval/rejection workflow. The UI formats underscores as spaces.

-   accepted
-   pending approval
-   approved
-   queued
-   running
-   completed
-   partially completed
-   failed
-   cancelling
-   cancelled
-   rejected

## Job detail

The job detail page shows:

-   execution summary
-   timing information
-   request body
-   result summary
-   item-level report rows
-   event history
-   error payloads when present

The report section is especially useful for move and delete jobs because it shows how each selected message was processed.

### Live status and cancelling

While a job has not yet reached a terminal status, the job detail page **polls** automatically and updates the displayed status as the worker advances the job (queued → running → terminal) — no manual refresh is needed.

If the job is still `accepted`, `queued`, or `running` and you have `jobs:cancel` permission, a **Cancel Job** button is available. It requires explicit confirmation. Items already processed are not rolled back, and the job cannot be resumed. Requesting cancellation moves the job to `cancelling`; the current item may finish before remaining work is stopped. The final state is `cancelled` if nothing completed, or `partially_completed` if work already completed. The page shows `Cancellation requested — finishing the current item…` while this completes.

Terminal statuses (`completed`, `partially_completed`, `failed`, `cancelled`, `rejected`) stop polling.

## Reconcile uncertain outcomes

Resubmit leaves the source in place. A successful item means the destination broker acknowledged the publication, not that a downstream application processed it. Move requires that acknowledgement before deleting the source. A `delete_failed_after_publish` item means a copy was published but source removal failed; inspect both queues before retrying. A confirmation timeout or session loss can be indeterminate: the destination may already contain the copy. Do not blindly retry.

`GET /api/v1/jobs/{jobId}/report` returns a structured item report. Public job responses omit internal idempotency and execution-context metadata. v1.7.1 has no customer message-file/object-storage export workflow; the internal export job type produces only a durable-state report summary. [Compliance evidence exports](https://portal.cjcit.io/knowledge-base/message_ops/1.7/usage/audit-and-evidence/) are a separate feature.