When Buying Policies block an order, Operators can force validation to move the order forward. Every action is audited so you can track who unblocked what, when, and why.

Key points

• Force validation is an operator action with mandatory justification.
• The action unblocks the order and records an audit entry.
• You can list and inspect the full unblock history for any order.
• Use this sparingly; the preferred path is to fix the underlying cause.

---

🔎 When to use

• Critical exceptions where business must fulfill despite a policy block.
• False positives or known tolerances not yet encoded in rules.
• Post-mortem needs: link the unblock to a ticket or case ID in the comment.

---

🔄 Unblock lifecycle

graph LR
  %% ---------- Flow ----------
  B[Order blocked by policy] --> R[Review blocking reasons]
  R --> DEC{Proceed with<br>force validation}
  DEC -->|No| KEEP[Keep blocked<br>fix root cause]
  DEC -->|Yes| UNB[POST unblock<br>ADM-ORDER-150]
  UNB --> H[Audit entry created]
  H --> V[GET unblock history<br>ADM-ORDER-550]

  %% ---------- Styles ----------
  classDef inter fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;
  classDef diff fill:#fff4e5,stroke:#f59e0b,stroke-width:2px,color:#7a3e00;
  classDef visible fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
  classDef resp fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;

  class B inter;
  class R,UNB,V visible;
  class DEC diff;
  class KEEP resp;
  class H visible;

  style B rx:8,ry:8
  style R rx:8,ry:8
  style DEC rx:8,ry:8
  style KEEP rx:8,ry:8
  style UNB rx:8,ry:8
  style H rx:8,ry:8
  style V rx:8,ry:8

---

🧾 API actions

• Force validation
  • POST /v1/logistic-orders/unblock - ADM-ORDER-150
• Read audit history
  • GET /v1/logistic-orders/:logisticOrderId/unblock-history - ADM-ORDER-550

Pair these with blocking reasons: GET /v1/buying-policies/blocking-reasons - ADM-BUYING-POLICY-552

---

🧭 Roles and safeguards

• Who: Operators (and Customer Admins if you allow) with the right to override.
• What is recorded: user identity, timestamp, previous status, and any correlation ID.
• Guardrails:
  • Action is idempotent per order and safe against double-clicks.
  • The order becomes eligible for execution after unblock, downstream checks apply as usual.

---

🗂️ Typical UI flow

graph LR
  L[List blocked orders] --> O[Open order details]
  O --> RSN[Show reasons<br>ADM-BUYING-POLICY-552]
  O --> BTN[Trigger unblock action]
  BTN --> MOD[Modal asks for comment]
  MOD --> CALL[Call POST unblock<br>ADM-ORDER-150]
  CALL --> OK[Show toast success<br>order unblocked]
  OK --> HIS[Link to history<br>ADM-ORDER-550]

  %% ---------- Styles ----------
  classDef total fill:#e8f1ff,stroke:#2f6feb,stroke-width:2px,color:#0b3d91;
  classDef visible fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
  classDef resp fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;

  class L total;
  class O,RSN,BTN,MOD,CALL,OK,HIS visible;

  style L rx:8,ry:8
  style O rx:8,ry:8
  style RSN rx:8,ry:8
  style BTN rx:8,ry:8
  style MOD rx:8,ry:8
  style CALL rx:8,ry:8
  style OK rx:8,ry:8
  style HIS rx:8,ry:8

---

✅ Operator checklist

• Check reasons first; unblock only when justified.
• Provide a clear comment with ticket or case reference if you're design allows it.
• After unblocking, verify downstream status and history.
• Periodically audit unblocks to refine policies.

---

🔗 API quicklinks

• POST /v1/logistic-orders/unblock - ADM-ORDER-150
• GET /v1/logistic-orders/:logisticOrderId/unblock-history - ADM-ORDER-550
• GET /v1/buying-policies/blocking-reasons - ADM-BUYING-POLICY-552

---