Discover workflows

Review a proposed business rule, settle its policy questions, then approve the draft.

2 workflows found in resolved tickets · 0 new proposals. Historical behavior is evidence of practice, not proof that a rule is correct.

Refund requests

8 resolved tickets · 8 agent-approved · 8 sampled

Monitoring

When the support agent approves a refund request and resolves the ticket, the payment for the order named in the ticket must carry a succeeded refund for exactly the requested amount, in the requested currency, within two minutes. Refunds on other payments of the same customer do not count.

Already covered by Approved refund is issued correctly. 3 policy decisions still need acceptance on version 1.

Review existing decisions

Proposal policy questions

These questions describe the proposal. The count and link above refer to pending decisions on the existing rule.

1.Partial refunds: a request without a structured amount is treated as a full refund of the payment. Confirm this matches policy.
Source references and sampled evidence
- 8 resolved refund ticket(s), 8 approved by the agent, 8 sampled · historical records
  Most recent sampled ticket: tkt_mvv2neqm52n5a1b6
- Support API · api schema
  GET /support/tickets?status=resolved|updatedAfter=, GET /support/tickets/:id, POST /support/tickets/:id/approve, POST /support/tickets/:id/resolve {message}. Tickets carry requesterEmail, category, optional orderRef, age
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Approved refund workflow · policy document
  Support agent approves a refund request, looks up the charge of the order named in the ticket, issues one refund for the requested amount (minor units, requested currency) against that charge, then resolves the ticket qu
held on 4 of 8, violated on 3 (possible real failures, not exceptions), 1 could not be correlated. held on 0 of 8, not applicable to 7, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 6 of 8, violated on 1 (possible real failures, not exceptions), 1 could not be correlated.
2.Split refunds: the proposal allows at most one refund per payment per request.
Source references and sampled evidence
- 8 resolved refund ticket(s), 8 approved by the agent, 8 sampled · historical records
  Most recent sampled ticket: tkt_mvv2neqm52n5a1b6
- Support API · api schema
  GET /support/tickets?status=resolved|updatedAfter=, GET /support/tickets/:id, POST /support/tickets/:id/approve, POST /support/tickets/:id/resolve {message}. Tickets carry requesterEmail, category, optional orderRef, age
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Approved refund workflow · policy document
  Support agent approves a refund request, looks up the charge of the order named in the ticket, issues one refund for the requested amount (minor units, requested currency) against that charge, then resolves the ticket qu
held on 4 of 8, violated on 3 (possible real failures, not exceptions), 1 could not be correlated. held on 0 of 8, not applicable to 7, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 6 of 8, violated on 1 (possible real failures, not exceptions), 1 could not be correlated.
3.Escalation: tickets the agent did not approve (declined or handed to a human) are treated as acceptable terminal states and are not monitored.
Source references and sampled evidence
- 8 resolved refund ticket(s), 8 approved by the agent, 8 sampled · historical records
  Most recent sampled ticket: tkt_mvv2neqm52n5a1b6
- Support API · api schema
  GET /support/tickets?status=resolved|updatedAfter=, GET /support/tickets/:id, POST /support/tickets/:id/approve, POST /support/tickets/:id/resolve {message}. Tickets carry requesterEmail, category, optional orderRef, age
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Approved refund workflow · policy document
  Support agent approves a refund request, looks up the charge of the order named in the ticket, issues one refund for the requested amount (minor units, requested currency) against that charge, then resolves the ticket qu
held on 4 of 8, violated on 3 (possible real failures, not exceptions), 1 could not be correlated. held on 0 of 8, not applicable to 7, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 6 of 8, violated on 1 (possible real failures, not exceptions), 1 could not be correlated.
4.Deadline: two minutes after resolution comes from the template, not from a policy document.
Source references and sampled evidence
- 8 resolved refund ticket(s), 8 approved by the agent, 8 sampled · historical records
  Most recent sampled ticket: tkt_mvv2neqm52n5a1b6
- Support API · api schema
  GET /support/tickets?status=resolved|updatedAfter=, GET /support/tickets/:id, POST /support/tickets/:id/approve, POST /support/tickets/:id/resolve {message}. Tickets carry requesterEmail, category, optional orderRef, age
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Approved refund workflow · policy document
  Support agent approves a refund request, looks up the charge of the order named in the ticket, issues one refund for the requested amount (minor units, requested currency) against that charge, then resolves the ticket qu
held on 4 of 8, violated on 3 (possible real failures, not exceptions), 1 could not be correlated. held on 0 of 8, not applicable to 7, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 6 of 8, violated on 1 (possible real failures, not exceptions), 1 could not be correlated.
5.1 of 8 records could not be evaluated for "Succeeded refunds on the named payment equal the requested amount" (no order reference on the ticket); those would be reported as indeterminate, not as failures.
Source references and sampled evidence
- 8 resolved refund ticket(s), 8 approved by the agent, 8 sampled · historical records
  Most recent sampled ticket: tkt_mvv2neqm52n5a1b6
- Support API · api schema
  GET /support/tickets?status=resolved|updatedAfter=, GET /support/tickets/:id, POST /support/tickets/:id/approve, POST /support/tickets/:id/resolve {message}. Tickets carry requesterEmail, category, optional orderRef, age
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Approved refund workflow · policy document
  Support agent approves a refund request, looks up the charge of the order named in the ticket, issues one refund for the requested amount (minor units, requested currency) against that charge, then resolves the ticket qu
held on 4 of 8, violated on 3 (possible real failures, not exceptions), 1 could not be correlated. held on 0 of 8, not applicable to 7, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 6 of 8, violated on 1 (possible real failures, not exceptions), 1 could not be correlated.
6.1 of 8 records could not be evaluated for "Without a requested amount, the payment is refunded in full" (no order reference on the ticket); those would be reported as indeterminate, not as failures.
Source references and sampled evidence
- 8 resolved refund ticket(s), 8 approved by the agent, 8 sampled · historical records
  Most recent sampled ticket: tkt_mvv2neqm52n5a1b6
- Support API · api schema
  GET /support/tickets?status=resolved|updatedAfter=, GET /support/tickets/:id, POST /support/tickets/:id/approve, POST /support/tickets/:id/resolve {message}. Tickets carry requesterEmail, category, optional orderRef, age
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Approved refund workflow · policy document
  Support agent approves a refund request, looks up the charge of the order named in the ticket, issues one refund for the requested amount (minor units, requested currency) against that charge, then resolves the ticket qu
held on 4 of 8, violated on 3 (possible real failures, not exceptions), 1 could not be correlated. held on 0 of 8, not applicable to 7, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 6 of 8, violated on 1 (possible real failures, not exceptions), 1 could not be correlated.
7.1 of 8 records could not be evaluated for "The payment's currency matches the requested currency" (no order reference on the ticket); those would be reported as indeterminate, not as failures.
Source references and sampled evidence
- 8 resolved refund ticket(s), 8 approved by the agent, 8 sampled · historical records
  Most recent sampled ticket: tkt_mvv2neqm52n5a1b6
- Support API · api schema
  GET /support/tickets?status=resolved|updatedAfter=, GET /support/tickets/:id, POST /support/tickets/:id/approve, POST /support/tickets/:id/resolve {message}. Tickets carry requesterEmail, category, optional orderRef, age
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Approved refund workflow · policy document
  Support agent approves a refund request, looks up the charge of the order named in the ticket, issues one refund for the requested amount (minor units, requested currency) against that charge, then resolves the ticket qu
held on 4 of 8, violated on 3 (possible real failures, not exceptions), 1 could not be correlated. held on 0 of 8, not applicable to 7, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 6 of 8, violated on 1 (possible real failures, not exceptions), 1 could not be correlated.
8.1 of 8 records could not be evaluated for "At most one refund was issued against the payment" (no order reference on the ticket); those would be reported as indeterminate, not as failures.
Source references and sampled evidence
- 8 resolved refund ticket(s), 8 approved by the agent, 8 sampled · historical records
  Most recent sampled ticket: tkt_mvv2neqm52n5a1b6
- Support API · api schema
  GET /support/tickets?status=resolved|updatedAfter=, GET /support/tickets/:id, POST /support/tickets/:id/approve, POST /support/tickets/:id/resolve {message}. Tickets carry requesterEmail, category, optional orderRef, age
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Approved refund workflow · policy document
  Support agent approves a refund request, looks up the charge of the order named in the ticket, issues one refund for the requested amount (minor units, requested currency) against that charge, then resolves the ticket qu
held on 4 of 8, violated on 3 (possible real failures, not exceptions), 1 could not be correlated. held on 0 of 8, not applicable to 7, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 6 of 8, violated on 1 (possible real failures, not exceptions), 1 could not be correlated.
9.1 of 8 records could not be evaluated for "No other payment of the customer was refunded for this request" (no order reference on the ticket); those would be reported as indeterminate, not as failures.
Source references and sampled evidence
- 8 resolved refund ticket(s), 8 approved by the agent, 8 sampled · historical records
  Most recent sampled ticket: tkt_mvv2neqm52n5a1b6
- Support API · api schema
  GET /support/tickets?status=resolved|updatedAfter=, GET /support/tickets/:id, POST /support/tickets/:id/approve, POST /support/tickets/:id/resolve {message}. Tickets carry requesterEmail, category, optional orderRef, age
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Approved refund workflow · policy document
  Support agent approves a refund request, looks up the charge of the order named in the ticket, issues one refund for the requested amount (minor units, requested currency) against that charge, then resolves the ticket qu
held on 4 of 8, violated on 3 (possible real failures, not exceptions), 1 could not be correlated. held on 0 of 8, not applicable to 7, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 7 of 8, 1 could not be correlated. held on 6 of 8, violated on 1 (possible real failures, not exceptions), 1 could not be correlated.

Proposed checks and historical examples

Succeeded refunds on the named payment equal the requested amount
held on 4 of 8, violated on 3 (possible real failures, not exceptions), 1 could not be correlated. Already in the current rule.
Without a requested amount, the payment is refunded in full
held on 0 of 8, not applicable to 7, 1 could not be correlated. Already in the current rule.
The payment's currency matches the requested currency
held on 7 of 8, 1 could not be correlated. Already in the current rule.
At most one refund was issued against the payment
held on 7 of 8, 1 could not be correlated. Already in the current rule.
No other payment of the customer was refunded for this request
held on 6 of 8, violated on 1 (possible real failures, not exceptions), 1 could not be correlated. Already in the current rule.

Existing rule policy

When

A refund ticket is resolved after the agent approves the request.

Verify

Succeeded refunds on the named payment equal the requested amount
Without a requested amount, the payment is refunded in full
The payment's currency matches the requested currency
At most one refund was issued against the payment
No other payment of the customer was refunded for this request

4 checks are conditional. Their applicability is defined under Accepted alternatives.

Within

2 minutes after the ticket is resolved. Observed unmet conditions become violated at that deadline; condition evidence still unknown after the deadline is indeterminate.

Missing evidence handling

Use the order explicitly named in the ticket. If that reference cannot be resolved, the result is indeterminate and needs review. No match is inferred from email or recency.

Accepted alternatives

When the 4 conditional checks apply

Succeeded refunds on the named payment equal the requested amount
Check only when a payment is present and the requested refund amount is specified. Otherwise this check is not applicable.
Without a requested amount, the payment is refunded in full
Check only when a payment is present and the requested refund amount is not specified. Otherwise this check is not applicable.
The payment's currency matches the requested currency
Check only when a payment is present and the requested currency is specified. Otherwise this check is not applicable.
At most one refund was issued against the payment
Check only when a payment is present. Otherwise this check is not applicable.

Order cancellations

4 resolved tickets · 4 agent-approved · 4 sampled

Monitoring

When a support agent approves an order cancellation and resolves the ticket, the corresponding order must be canceled, the correct payment refunded, and any pending fulfillment canceled within two minutes.

Already covered by Approved cancellation is fully executed. 2 policy decisions still need acceptance on version 1.

Review existing decisions

Proposal policy questions

These questions describe the proposal. The count and link above refer to pending decisions on the existing rule.

1.Delivered shipments are exempt from cancellation; confirm whether returns should be opened instead.
Source references and sampled evidence
- 4 resolved cancellation ticket(s), 4 approved by the agent, 4 sampled · historical records
  Most recent sampled ticket: tkt_mvv2ng8x61fgxipf
- Commerce API · api schema
  GET /commerce/orders?email=|customerId=, GET /commerce/orders/:id, POST /commerce/orders/:id/cancel. Order status: placed|paid|canceled|fulfilled. A customer may have several orders; email is not unique to an order.
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Fulfillment API · api schema
  GET /fulfillment/shipments?orderId=, GET /fulfillment/shipments/:id/eligibility, POST /fulfillment/shipments/:id/cancel. Cancellation is subject to carrier eligibility and the caller's permissions; rejected requests retu
- Approved cancellation workflow · policy document
  Support agent approves a cancellation request, cancels the order in commerce, refunds the charge in payments, cancels any pending shipment in fulfillment, then resolves the ticket. The ticket may only be resolved as comp
held on 4 of 4. held on 4 of 4. held on 4 of 4.
2.Escalation: tickets the agent did not approve are treated as acceptable terminal states and are not monitored.
Source references and sampled evidence
- 4 resolved cancellation ticket(s), 4 approved by the agent, 4 sampled · historical records
  Most recent sampled ticket: tkt_mvv2ng8x61fgxipf
- Commerce API · api schema
  GET /commerce/orders?email=|customerId=, GET /commerce/orders/:id, POST /commerce/orders/:id/cancel. Order status: placed|paid|canceled|fulfilled. A customer may have several orders; email is not unique to an order.
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Fulfillment API · api schema
  GET /fulfillment/shipments?orderId=, GET /fulfillment/shipments/:id/eligibility, POST /fulfillment/shipments/:id/cancel. Cancellation is subject to carrier eligibility and the caller's permissions; rejected requests retu
- Approved cancellation workflow · policy document
  Support agent approves a cancellation request, cancels the order in commerce, refunds the charge in payments, cancels any pending shipment in fulfillment, then resolves the ticket. The ticket may only be resolved as comp
held on 4 of 4. held on 4 of 4. held on 4 of 4.
3.Deadline: two minutes after resolution comes from the template, not from a policy document.
Source references and sampled evidence
- 4 resolved cancellation ticket(s), 4 approved by the agent, 4 sampled · historical records
  Most recent sampled ticket: tkt_mvv2ng8x61fgxipf
- Commerce API · api schema
  GET /commerce/orders?email=|customerId=, GET /commerce/orders/:id, POST /commerce/orders/:id/cancel. Order status: placed|paid|canceled|fulfilled. A customer may have several orders; email is not unique to an order.
- Payments API · api schema
  GET /payments/charges?orderId=|customerId=, GET /payments/charges/:id/refunds, POST /payments/charges/:id/refunds {amountMinor?} (minor units; omitted = remaining balance; amounts above the refundable balance are rejecte
- Fulfillment API · api schema
  GET /fulfillment/shipments?orderId=, GET /fulfillment/shipments/:id/eligibility, POST /fulfillment/shipments/:id/cancel. Cancellation is subject to carrier eligibility and the caller's permissions; rejected requests retu
- Approved cancellation workflow · policy document
  Support agent approves a cancellation request, cancels the order in commerce, refunds the charge in payments, cancels any pending shipment in fulfillment, then resolves the ticket. The ticket may only be resolved as comp
held on 4 of 4. held on 4 of 4. held on 4 of 4.

Proposed checks and historical examples

The order named in the ticket is canceled
held on 4 of 4. Already in the current rule.
Succeeded refunds equal the original charge
held on 4 of 4. Already in the current rule.
Any pending shipment for the order is canceled
held on 4 of 4. Already in the current rule.

Existing rule policy

When

A cancellation ticket is resolved after the agent approves the request.

Verify

The order named in the ticket is canceled
Succeeded refunds equal the original charge
Any pending shipment for the order is canceled

2 checks are conditional. Their applicability is defined under Accepted alternatives.

Within

2 minutes after the ticket is resolved. Observed unmet conditions become violated at that deadline; condition evidence still unknown after the deadline is indeterminate.

Missing evidence handling

Use the order explicitly named in the ticket. If that reference cannot be resolved, the result is indeterminate and needs review. No match is inferred from email or recency.

Accepted alternatives

When the 2 conditional checks apply

Succeeded refunds equal the original charge
Check only when a payment is present. Otherwise this check is not applicable.
Any pending shipment for the order is canceled
Check only when a shipment is present and the shipment status is not delivered. Otherwise this check is not applicable.

How discovery uses records and policy

Resolved tickets are grouped by workflow. Candidate checks are evaluated against the sampled business records and compared with available policy documents and API schemas. Proposals keep their sources and unresolved assumptions. A person decides the policy and approves a draft before it is monitored.