---
description: keynotes.
---

# Operation Request Characteristics

<figure><img src="https://content.gitbook.com/content/uvuyQluEi5QMHcp2TcU7/blobs/OG4Sx3juvH0NMa0C1V6y/image.png" alt=""><figcaption></figcaption></figure>

* **Pending Requests**: \
  Another operation request cannot be submitted if there is a pending operation request for the same transaction. The following message should be displayed: \
  **Requested {Operation} is pending for approval**.
* **Canceled Requests**: \
  Any operation request in the `Pending` state can be canceled by all users except the checker from [Operation Request Table](operation-request-table). If the checker somehow approves a canceled request, an error message will indicate that the request has been canceled.
* **Automatic Execution**: Once the checker approves the request, the operation will execute automatically, transitioning the state to `Done`. If the execution fails, the state will change to **Manual Action Required**, and the maker will be [notified](notification) that manual action is required.
* **Expiration**: \
  If the state transitions to `Manual Action Required` and no changes are made within the specified expiration time, the transaction state will transition to the `Expired` state.

{% hint style="info" %}
The default time will be 48 hrs, defined from backend.
{% endhint %}

* **Post-Done State**: \
  Once the operation request transitions to the `Done` state, a refund or void request is not allowed for the same transaction unless there are remaining funds, in which case only a refund request can be processed.
* **Whitelisted Users**: \
  The user authorized to assign a checker can add whitelisted users through the Administration Panel by navigating to the Operations Approval Plugin and selecting Operations Approval Plugin Config.

