> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bijection.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Operations

> Submit, preview and recover operations, and follow accepted requests and their external calls, from the console

<Warning>The Operations page is in beta.</Warning>

A deployment's **Operations** page lists the deployment's
[operations](/operations/overview) and the requests it accepted. You can fill in
and preview an operation, submit it, recover a submission whose response was
lost, and follow each accepted request through review, delivery and
publication. It uses the same request keys, previews and recovery as
[`bijection run`](/operations/cli-and-dashboard) and your own
[callers](/operations/calling-operations).

The page has two tabs, **Definitions** and **Activity**. For a deployment with
[components](/components/using), the selector at the top right chooses the
component.

## Running operations as

The **Run operations as** panel at the top shows the identity the page's
requests run as: **Deployment administrator** by default. Open it and check
**Act as an application user** to enter a user identity as JSON and click
**Use this identity**; this needs permission to act as a user. The identity is
remembered in the browser tab and shared with the
[Files page](/dashboard/deployments/files). Changing it opens a separate request
context: requests retained under one identity are never sent as another.

The identity decides what the deployment lets these requests do and see. Every
caller of an operation needs a grant on it, including a deployment
administrator; without one, a submission is refused with `OperationAccess`. See
[Granting access](/operations/defining-operations#granting-access).

## Definitions

The **Definitions** tab lists each deployed operation with its object type.
When none is deployed, it shows **No operations deployed**. Select an operation
to open it. The page shows its object type and whether it is public or
internal, links to its deployed function on the
[Functions page](/dashboard/deployments/functions), and **View definition**
shows the object type's definition.

Enter the arguments in **Inputs**, a JSON editor checked against the
operation's argument validator, or in a form where one is declared for the
operation (**Advanced inputs (JSON)** switches to the editor). Validation errors
are listed below the inputs.

Other pages open this tab too. On the [Data page](/dashboard/deployments/data),
a view's **Operations** link shows only that object type's operations, and a
definition panel links each of its operations. From a record, an operation that
declares a [`target`](/operations/defining-operations#the-target-target) opens
with the record's ID already filled in.

### Previewing

For an operation with a preview, **Preview changes** evaluates it on the
current data without accepting anything or sending any request. The result
says whether the preview checks are satisfied, found an execution restriction,
or could not be evaluated completely, and lists the checks, the proposed local
changes with each row before and after, and the proposed external requests,
which were not sent. When some effects can't be shown to you, the result says
the display is limited. **Native report and provisional basis** shows the whole
report. Submitting checks current facts and permissions again. See
[Previewing an operation](/operations/calling-operations#previewing-an-operation).

### Submitting and recovering

**Submit operation** sends the request. Before sending, the page keeps a
[request key](/operations/calling-operations#request-keys) and the exact
arguments in the browser tab, per deployment, component, operation and
identity, and it refuses to send a request it could not keep.

* When the deployment accepts, the page shows **Local changes committed.** and
  the request's detail, as on the Activity tab. **Start a new request** clears
  the kept request.
* When the response is lost, the page shows **Acceptance not yet confirmed**,
  never a failure, because the request may still commit. The button becomes
  **Recover or retry this request**. It first looks up what the kept key
  already accepted, and only if nothing was accepted sends the request again
  under the same key and arguments. It never creates a new request.

A kept request survives a reload of the tab. Opening the operation again first
checks for it (**Checking for an interrupted request…**), and while one is kept
its inputs are locked and shown under **Retained request inputs** with its key.

**Submit operation** is disabled without permission to write data, for an
internal operation without permission to run internal mutations, when acting as
a user without permission to act as a user, and for an unmounted component.
**Result contract** shows the operation's result validator.

## Activity

The **Activity** tab lists the accepted requests the selected identity may
see, newest first. **Show** chooses the list, selected by the deployment:

* **All requests**
* **Held for review**: requests waiting for a review decision
* **External work refused**: requests with an external call whose delivery is
  currently refused

**Needs attention on this page** narrows the current page to requests whose
retained result expired, that await a review decision, or that have an external
call whose outcome is not confirmed, was refused, did not take effect or was
executed more than once, or whose publication is blocked.

Each row shows the operation, the retained state (**Accepted** or **Retained
result expired**), a summary of the outcome, the review state and the reason it
needs attention, and the invocation ID. The summary keeps local acceptance
separate from what the provider confirmed, for example **Local changes
committed; provider outcome is not confirmed**. Lists are paged with **Next
page** and **First page**; a page of a selected list can be short or empty with
more behind it.

**Activity targeting this object**, on a record in the Data page, opens this tab
with only the requests aimed at that record. The **Operations** card on the
[Overview page](/dashboard/deployments/health) links here too.

### A request's detail

Click a request to see its detail. It is read through the operation's status
under the selected identity, so a request whose result you may not see shows
the refusal instead.

* **Review** shows the [review state](/operations/calling-operations#review-state)
  and its facts, such as the blocker, who is responsible and since when. The
  page has no approve or reject control: a decision is made by your
  application's own review operation, under its own rules, and the page links
  to that operation when it is deployed.
* For each external call, **Write progress** shows three steps: accepted,
  the provider's answer (confirmed, refused, outcome unknown or awaited) and
  whether the confirmation was recorded. The call's
  [delivery state](/operations/external-calls#delivery-outcomes) and
  publication follow.
* **Recovery guidance and revisions**, on a request with a refused external
  call, gives the command that re-admits a never-held call under the
  current definitions, `bijection run <operation> --revise --invocation-id <id>`,
  and the contract, code and policy revisions it was accepted under. See
  [Revising a blocked request](/operations/calling-operations#revising-a-blocked-request).

### Provider outcome

Under each external call, the **Provider outcome** section shows the original
request, the requested change and table, the connection and source, the
outcome, the number of attempts, the last HTTP status and when the response was
observed. It explains the outcome and, where it applies, that:

* automatic attempts stopped at the delivery deadline, the attempt limit or the
  response limit;
* the provider asked the connection to wait for an operator, or its readiness
  statement could not be read;
* current authority no longer permits recovery;
* the request is held, and should be checked before it is released.

When the outcome is unconfirmed, the section is titled **Review an unconfirmed
change** and says to keep the request, compare the retained evidence with the
provider's own audit trail, and not submit a replacement.
**Check retained evidence**, offered for an unknown or held outcome, is
`bijection integration command-recover`: for this same request, it interprets
the retained evidence or performs a bounded read, and never sends a new write. An outcome that stays
unconfirmed is shown as unconfirmed. It needs permission to write data and is
disabled when authority changed. **Retained evidence and technical details**
shows how many response bytes are retained, their SHA-256 and any provider
refusal; credentials and response contents are never shown.

A completed change that needs repair is a separate business operation, reviewed
against current provider facts. See
[Unknown outcomes and recovery](/operations/external-calls#unknown-outcomes-and-recovery).

## Permissions

| Permission | What it allows on this page |
| - | - |
| View data (`deployment:data:view`) | The Activity lists and a request's provider outcome |
| Write data (`deployment:data:write`) | Submitting an operation, Check retained evidence |
| Run internal mutations (`deployment:functions:runInternalMutations`) | Submitting an internal operation |
| Act as a user (`deployment:functions:actAsUser`) | Running operations as an application user |

A control you lack permission for is shown disabled, and the deployment checks
the same permissions itself. The operation's own grants and access rules apply
on top of these. Admins and Developers hold all four; Viewers can read the page
but submit nothing. See [Role Actions](/team-management/role-actions).