orderApprovalStatusUpdate
Approve or reject an order approval flow. Enforced server-side: the buyer may never approve their own order, and only an eligible approver role may decide.
Arguments
| Argument | Type | Description |
|---|---|---|
businessUnitId | ID! | |
id | ID! | |
version | String | Expected optimistic-concurrency token, to fail the write if the approval changed meanwhile. Omit to apply the decision to the current version; engines without versioning ignore it. |
status | OrderApprovalStatusType! | |
reason | String |
Returns
| Field | Type | Description |
|---|---|---|
orderApproval | OrderApproval | The updated approval flow |
orderApprovalErrors | [OrderApprovalError!] | Error details if the decision failed |
Example
mutation OrderApprovalStatusUpdate( $businessUnitId: ID! $id: ID! $version: String $status: OrderApprovalStatusType! $reason: String) { orderApprovalStatusUpdate( businessUnitId: $businessUnitId id: $id version: $version status: $status reason: $reason ) { orderApproval { id version status pendingApproverRoleKeys viewerCanDecide } orderApprovalErrors { __typename ... on ValidationError { message } } }}{ "businessUnitId": "id-1", "id": "id-1", "version": "Example", "status": "PENDING", "reason": "Example"}{ "data": { "orderApprovalStatusUpdate": { "orderApproval": { "id": "id-1", "version": "Example", "status": "PENDING", "pendingApproverRoleKeys": [ "Example" ], "viewerCanDecide": true }, "orderApprovalErrors": [ { "__typename": "ValidationError", "message": "Example" } ] } }}The query selects the return type's fields two levels deep; pick the ones you need. The response shows its shape with placeholder values.
Served by
| @evolve-framework/commercetools | Resolved |
| @evolve-framework/medusa | Resolved |
| @evolve-framework/sfcc | Resolved |
Used by
The storefront packages that send it, in these GraphQL documents:
- @evolve-storefront/feature-organization:
OrderApprovalStatusUpdate

