Home / Use cases / Order changes
Proposed workflow · commerce

Change the right thing.Leave the rest alone.

A new address. One item removed. A box skipped. These requests need more than a polite reply. Here's how we would design a flow that changes the right thing and leaves the rest alone.

Proposed workflow, not a generally available feature. Partial-item editing still needs validation before broader rollout. This guide shows the intended behavior; specific actions need a supported integration, approved rules and testing.

What the flow needs

“Change my order”can mean several different things.

The first job is to understand the change. The second is to check whether it is still possible. Only then should anything be written to the store.

Read

Verified customer, exact order or subscription, items, address, fulfilment state and any relevant change deadline.

Change

Only the requested fields or items, through actions approved for this flow. A different price, shipping cost or renewal date may need confirmation.

Hand off

Already shipped, locked by fulfilment, conflicting records, an unsupported action or an exception outside the rules? Route it to the team that can help.

A proposed flow

Check before changing.

  1. Verify the person and order

    Match the request to the correct account and order using your verification process. Do not act on an order number alone.

  2. Confirm the scope

    One item or the whole order? This delivery or future renewals too? Ask when the request leaves room for two different changes.

  3. Check the current state

    Read fulfilment and change restrictions. Recheck at the point of action where the integration supports it; an order can leave the warehouse while a conversation is open.

  4. Explain any consequences

    Surface changes to totals, delivery or subscription terms. Get the required customer or human approval before proceeding.

  5. Update and read back

    Apply the approved change, then inspect the returned or refreshed record. Check that unrelated items and renewals remain as intended.

  6. Confirm what changed

    Reply with the actual result and leave the work record for your team. If confirmation is unavailable, do not report the change as complete.

Proposed outcome · not live

One item out.Not the whole subscription.

This is the outcome the flow must prove before rollout, not a completed product test. Example assumptions: the next bundle is editable, removing the item is allowed, and the customer has confirmed the change applies to future boxes. Prices below are sample data.

What if the box has already shipped?
Explain that this shipment cannot be edited through this flow. Follow the agreed return or carrier process, or hand off. Do not claim an address or item was changed in a parcel already on its way.
What does the scorecard check?
The requested item changed, the rest of the order stayed intact, the response matches the confirmed record, and all required approval and communication steps were followed.
Example #ORDER-01Proposed flow
CustomerTake the socks out of my future boxes, please. Keep everything else.
  • ✓Customer and subscription matched
  • ✓Bundle editable under the example rules
  • ✓Only the socks removed
  • ✓Next renewal verified: two items, $29
  • ✓Subscription remains active
Example replyDone. I've removed the socks from future boxes and kept your other items. Your next box is $29 instead of $38. The subscription stays active.
Correct action. Correct scope.A successful API call is not enough if it changes the wrong thing.

Start with one kind of change.

Map one request, confirm the integration can support it, and review it in shadow mode. Add more changes only after the team has checked the results.

Check the access requirements · Watch the scripted replay

Bring your version

Your rules. Your first flow.

Bring an anonymized ticket and the policy behind it. We'll work through the checks, access and handoffs with you.

Next: refunds & cancellations →