Review action proposals in Inbox

Open Inbox from the Plainrouter sidebar to review proposals for the current workspace, including changes submitted from Campaigns. Select an action to read its reasoning, target, policy result, and status. In Ask mode, a person approves every change first. Approve and Reject decide the containing batch, including its other actions. Full runs admitted changes automatically without a per-change approval; follow their receipts in Inbox. Account rules can also produce proposals. Their budget increases require human approval even in Full; inspect the stored decision rather than assuming the workspace mode alone authorizes execution.

​

Before you decide

Sign in with a browser session and workspace access. Approval requires the workspace’s human approval permission; a workspace token cannot make this decision for you. Have the complete proposal available, including its account scope, parameters, evidence, and frozen execution_mode_snapshot. The Inbox header shows the workspace’s current policy mode. Do not substitute it for an older proposal’s mode snapshot. A policy change does not turn a suggest-only proposal into executable work. For a complete example, follow Create a paused Meta ad variant.

​

Read the Inbox groups

Counts represent actions, grouped into batches:

​

Review the selected action

​

Batch status and action status

The detail pane shows the selected action’s Status, its reasoning, policy check and activity. Expand All details for Batch status, Action status, receipt status and later outcome fields. Read both action and batch status, especially in a batch with multiple actions. One verified action does not prove that all actions in its batch completed or that recovery succeeded.

​

What does a halted batch mean?

A Meta execution kill switch can stop a batch with execution_kill_switch. If execution is stopped before any provider work, the batch is blocked. A batch stopped after verified work, or after a write attempt is confirmed absent, can be halted. Previously verified actions remain recorded; pending actions are blocked. Halting does not roll back changes that already landed. A halted batch cannot be approved again or resumed by retrying its old approval. Inspect each action, receipt, and current provider state before proposing any remaining work; do not resend the entire batch with a new key.

​

Proposer, target, and reasoning

Read Proposed by, Object or Objects, and Why. System proposals can show PlainRouter’s reasoning instead. Expand All details for identifiers and authorization fields. Compare the complete proposal with the intended Meta ad account and platform-native target IDs. For creative duplication, target_entity.id identifies the source ad; the new ad ID exists only in the execution receipt after a provider write. Confirm the person intended each source ad and asset selection. If the detail pane does not provide enough information to verify the account, mode, evidence, or parameters, check the original proposal before approving. Review every action in the containing batch.

​

What will change, and how fresh is the comparison?

For supported status and daily-budget changes, compare the current value with the proposed value before deciding. Budget amounts use the account currency. A displayed delta is not a performance forecast. Older proposals can lack a recorded policy observation. A comparison alone does not prove the change landed; check action status and the receipt below.

​

Current disposition and late restoration

Expand All details to inspect the current disposition. It shows receipt status, outcome status and check time, compensation reason, and recovery disposition. Not recorded means the field is unavailable, not a successful result. Restored late reports later compensated-receipt evidence. Historical action and batch statuses remain visible, so a prior failure can coexist with a later restoration. Check the receipt and disposition before retrying or claiming the original action succeeded.

​

Evidence and policy checks

Read Policy check, including the decision, reasons, and any unavailable dynamic fields. Executable work fails closed when a required provider or policy field is unknown. Suggest-only recommendations can disclose unavailable state because approval cannot execute them. The proposal’s evidence must support its claims:

• get-creative-library provenance establishes selected-asset identity, approved-account ownership, readiness, and status.
• staged-asset-manifest provenance identifies the frozen bytes, SHA-256 digest, and detected content type for an upload.
• Creative performance is excluded from the durable action-bound citation. Human-supplied targets and aggregate Signals data are not current provider state.

​

Approve a batch

In Ask, policy-allowed agent proposals wait for the Approve button. A Campaigns Pause or Resume click can include that human approval when the person has permission. Full queues allowed changes automatically. Rule violations cannot be approved. Read the proposal’s frozen mode and supported action before clicking; the button label does not describe the execution consequence. For an ad copy, confirm status: paused. Creating the copy cannot activate it; a later resume requires a separate proposal governed by Ask or Full. Approval is authoritative once and does not bypass execution-time policy.

​

How do I verify the outcome?

Follow the action’s status in Inbox, then use Audit and its JSON export to trace the batch decision, receipt evidence, provider observations, and terminal verification. When an action has a stored decision receipt, use Audit → Download decision receipt to inspect its terminal status and verification result. See receipt fields and access. Approved, Executing, and Executed pending verification do not mean a verified change. A paused copy that Meta reports as IN_PROCESS still needs scheduled receipt-addressed verification. Inspect the exported events for progress or failure; do not create another copy to bypass a pending result. Escalate a rollback_incomplete result rather than treating it as restored. Agents and server integrations can follow the same stored action outcomes through the MCP Actions reads or Actions API. These interfaces do not approve or reject the batch; the human decision remains in Inbox.

​

How are later performance outcomes checked?

For a verified Resume or daily-budget change, the detail pane can show Comparison, After change, counted arrivals, spend, cost per counted arrival and the loss threshold used. This later comparison answers whether the observed result held within that threshold. It does not replace verification of the original Meta change, measure purchase CPA or prove causal improvement. The comparison uses complete days in the Meta ad account’s timezone, with UTC as the fallback. It excludes the provider-write day. The first check is scheduled for one hour after the third complete day following that day; delayed or unavailable data can require bounded retries. The configurable Outcome check after delay applies to creative actions, not this management window. Each compared side needs at least 50 counted arrivals and positive spend. Compared spend must come from retained inventory with coverage for the completed days. Each check reads the arrival count and stored spend again before recording its result. Compared daily metrics must have been fetched at least ten minutes after that account-local day ended. This is a completed-day requirement, not a promise that every metric is less than ten minutes old. Missing rows count as zero only when fresh account sync coverage establishes that day. Otherwise the check can request a bounded metrics refresh, at most once per account per hour, within the available recent metrics window. Missing or older data can remain unavailable; refresh does not recover unlimited history.

​

What should I do with the result?

Check the retained inventory comparison and your Signals installation when data is missing. Bounded retries do not require another proposal. A final unavailable outcome leaves the earlier execution verification intact; it does not prove success or failure of performance. For automation, read the outcome payload.

​

What if a completed action has no later outcome?

For completed Pause, Resume and daily-budget batches, Plainrouter periodically recovers overdue outcome checks whose queued follow-up was lost. Follow the existing action rather than submitting the change again. Recovery does not repeat the original Meta write or extend the outcome’s retry deadline. An eligible check still within its retry window can continue. An expired check can finish as unavailable with outcome_check_exhausted, leaving the verified execution intact. A missing outcome is not a held/lost verdict, and recovery does not guarantee sufficient data for comparison.

​

Does a lost outcome create an inverse proposal?

For an eligible verified Resume or daily-budget change, Plainrouter can propose an inverse after recording lost. This includes daily-budget changes made by account rules, as well as eligible changes proposed by people or agents. A rule-made pause is not judged for performance and cannot trigger an inverse. The inverse is a new governed batch, separate from compensation for failed execution: The target must still have the budget or active status produced by the original action. If it already has the inverse state, its budget/status moved, prior-budget evidence is unavailable or a required provider read fails, no inverse is proposed. A lost verdict is not proof that a reversal is appropriate or that it landed. Read disposition.outcome_payload.inverse through the Actions API or MCP Actions reads. status: "proposed" returns batch_id; inspect that batch’s policy result and frozen mode. Ask waits for approval; Full can execute an admitted inverse automatically. Follow its receipt and verification before claiming restoration. The original action’s historical result remains recorded. status: "inverse_not_proposed" includes reason_code, such as already_inverse, budget_moved, status_moved, prior_budget_unavailable, target_state_unavailable or execution_kill_switch. Inspect current state and the reason before retrying manually. An inverse proposal’s own lost outcome does not generate another inverse proposal.

​

What if an approved batch stalls?

Plainrouter can recover an approved batch whose execution job was lost and settle a stalled execution without repeating a provider write. Follow the existing batch; do not approve it again or create replacement proposals to force progress. Read each action and its receipt. Already verified work remains recorded. An action with no provider attempt can finish as failed without a write; an attempted operation whose result cannot be established can remain execution_uncertain with a reconciliation_exhausted receipt. Compensation that cannot be confirmed leaves rollback_incomplete. None of these labels proves that nothing reached Meta. A recorded provider_commit_unknown means Plainrouter could not establish whether an attempted Meta write committed. Follow reconciliation and the exact target before retrying; an error response alone does not prove that Meta made no change. For an uncertain or partial result, inspect the exact target in Meta Ads Manager and the decision receipt and audit history. Resolve that recorded outcome before proposing further work on the target.

​

Reject a batch

Click Reject, optionally explain what the agent should reconsider, and confirm Reject proposal. The reason is stored in the audit event. Like approval, rejection applies to the containing batch. Approval and rejection are idempotent terminal decisions for a pending batch. A second decision does not reopen it.

​

Troubleshoot a missing decision or unexpected status

• The proposal is missing: confirm the selected workspace and proposal or batch ID. Use the returned inbox_url; approval_queue_url remains a compatibility alias for the same Inbox link.
• No decision control is available: check whether the batch is still pending. A completed decision is not reopened from Inbox.
• The decision is forbidden: sign in with an authorized human account in the correct workspace. A bearer token is not a substitute for this browser session.
• An action is blocked: read its exact reason and the policy constraints before resubmitting.
• Approved, not sent: this is a historical suggest_only snapshot. Changing the current policy does not promote it into execution.
• Couldn’t read the current state from Meta: temporary connection, server, or throttling failures leave the proposal pending. Retry approval after the read becomes available; do not create a duplicate proposal.
• Blocked by current policy: missing required provider state or a permanent target refusal blocks the batch. Review the named reason; retrying approval cannot override it. If Meta requires reconnection, reconnect the account before proposing further work.
• Rollback incomplete or Undo failed: inspect each receipt and current disposition. These labels do not mean the earlier provider change was undone.