> ## 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 in the CLI and Console > Run, preview, recover and follow operations from the command line and the console Running operations with `bijection run` and the console's Operations page are in beta. The CLI and the console present each operation as one entry, under its own name, rather than as the companion functions that serve it. They use the same request keys, previews and recovery described in [Calling operations](/operations/calling-operations). ## Running an operation `bijection run` recognizes an operation from your deployment and submits it: ```sh theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} bijection run orders:ship '{"order_id": "...", "expected_revision": 3}' ``` The command: It generates a fresh request key, unless you pass `--request-key`, and prints the acceptance: the invocation ID and the request key. It subscribes to the request's status until nothing is pending, then prints what was established, for example `Local changes committed; provider changes confirmed and published.` An unknown or unacknowledged provider outcome is reported as not confirmed instead of being waited on. If a person must decide before the request can continue, the command says so, prints the command to resume following it later, and exits normally. Keep the request key it prints. It is how you recover the request later. ### Options for operations | Option | What it does | | - | - | | `--preview` | Evaluates the operation on the current data without accepting, reserving or delivering anything | | `--request-key ` | The request's stable identity. Reuse the original key after an uncertain outcome; a new key is a new request | | `--recover` | Looks up what `--request-key` already accepted instead of submitting. Requires `--request-key` | | `--no-wait` | Prints the acceptance without following the status | | `--revise` | Re-admits an accepted request's never-held external calls under their destinations' current definitions. Requires `--invocation-id` and takes no arguments | | `--invocation-id ` | The accepted request that `--revise` re-admits | ```sh theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} # See what cancelling would change, without doing it bijection run orders:cancel '{"order_id": "...", "invoice_id": "..."}' --preview # Find out whether an earlier request was accepted bijection run orders:cancel '{"order_id": "...", "invoice_id": "..."}' \ --recover --request-key 6f1c2e0a-7a4b-4c1e-9d6f-2b8e5d3c1a90 ``` `--recover` must be given the same arguments as the original request. `--watch` and `--inline-query` do not apply to operations and are refused with a reason: a query is watched, while an operation is submitted once and followed through its status. Every caller of an operation needs a grant, including a deployment administrator. Without one, `bijection run` is refused with `OperationAccess`. See [Granting access](/operations/defining-operations#granting-access). ## Following requests in the logs `bijection logs` prints each companion's log lines under the operation's own name. With `--operations`, it streams accepted requests, their review state and their external-call outcomes instead of function log lines: ```sh theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} bijection logs --operations # all accepted requests bijection logs --operations --held # only requests held for review bijection logs --operations --blocked # only requests whose external work is refused ``` `--held` and `--blocked` require `--operations` and cannot be combined. A request that stops being held simply stops appearing; the listing reports a selection, not a transition. A request listed by `--blocked` has an external call whose delivery is currently refused, for example because its integration command changed after the request was accepted. When that call was never sent, re-admit it with `bijection run --revise --invocation-id `. ## Inspecting an external call A deployment administrator can inspect and recover one external call by its ID: ```sh theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} bijection integration command-status bijection integration command-recover ``` Recovery keeps the call's accepted identity. It interprets retained evidence or performs a bounded read, and it never submits a new write. Read on about [unknown outcomes](/operations/external-calls#unknown-outcomes-and-recovery). ## The Operations page In the console, a deployment's **Operations** page has two tabs. **Definitions** lists each deployed operation with its object type. Select one to fill in its arguments, with a form or as JSON, preview the changes, and submit. The page keeps the request key of each submission, so after an uncertain outcome its button becomes **Recover or retry this request**. That first looks up the retained request, and only then retries it under the same key and arguments. It never creates a new request. **Activity** lists accepted requests. The **Show** selector chooses: * **All requests** * **Held for review**: requests waiting for a review decision * **External work refused**: requests with external work that needs to be resolved **Needs attention on this page** narrows the current page to requests 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. Select a request to see its review state and each external call's outcome. For an external call whose outcome is unconfirmed, the request's detail shows the retained evidence and a **Check retained evidence** button. Checking evidence never submits a new request, and an outcome that stays unconfirmed is shown as unconfirmed. The console shows why a request is held and who must decide, but it has no approve or reject button. Decisions are made by your own review operation, under your [access rules](/access/overview). The [Functions](/dashboard/deployments/functions) and [Logs](/dashboard/deployments/logs) pages also show one entry per operation, under its own name.