Shopify order-change policies

Order-change policies describe the changes customers may ask your bot to make to an existing Shopify order. Use them to set a separate rule for items, pickup, warehouse notes and other requests. A policy is not a new store action: the ability that carries it out must also be available and switched on.

The bot can make a small set of changes to a customer’s own Shopify order after they ask. There are four separate abilities: Add order note, Change an order (unfulfilled items), Change order details (delivery date, delivery instructions, gift message and tags), and Change shipping address & contact. Each one is off until you turn it on. This guide is for owners deciding which of them to enable.

How it works

Each change type has its own eligibility wording, ways to make the change, customer-proof requirement and approval choice. The bot uses the applicable type alongside the action’s existing rules. Store-action limits and approvals still apply.

Every ability works on one order at a time and only after the customer meets the verification your store requires for that kind of change. See verification and User identification. The bot changes only what the customer asked for. Nothing else on the order is touched.

Ability	What it can do	What it never does
Add order note	Appends one dated line to the order note for your team.	Rewrite or remove the existing note.
Change an order	Changes unfulfilled items, shipping charges or item discounts after a preview, and settles any balance.	Cancel an order or change its address.
Change order details	Sets the delivery date, delivery instructions or a gift message in your store’s own order fields, and adds or removes tags. Can also set extra order fields your store has opened for apps.	Change items, money or the address. Overwrite other fields.
Change shipping address & contact	Corrects named shipping-address fields before the order reaches the warehouse, or the order’s email or phone on any eligible order.	Change the billing address, items or money. Replace address fields the customer did not ask to change.

Examples for order details

A customer asks to move delivery to another day. The bot sets your store’s delivery-date field to that day and leaves every other field as it was.
A customer asks to add a gift message. The bot fills the gift-message field.
A customer asks for a call before delivery. The bot adds a tag your team already uses for that.

Each kind of request is a change type in your store’s policy, with when it is allowed and how the bot does it. The bot explains what it can and cannot do. Requests outside these abilities follow Anything else below.

Turning an ability on does not grant it Shopify access. Address corrections need additional access that the store owner must approve in Shopify once the updated authorization is available. Order email and phone corrections use the existing order-writing access, without the extra address permissions. See Shopify access and reauthorization if a change reports missing access.

Two different questions have different fields:

When it’s allowed says whether this kind of change is still possible for the order, such as before it ships.
The action’s rules in the Handbook When section say when the bot should use that ability and how your store handles the request. The link below When it’s allowed opens those rules. The action’s rules link back to the order-change policies. Changing one does not replace the other.

Delivery date, courier instructions and gift message now use Change order details. When it is off, their Turn on to use link opens its existing switch. Shipping address and contact corrections use Change shipping address & contact. When it is off, their Turn on to use link opens its switch in Our policies → Service actions. Saving a policy does not turn on the ability.

Adding an order note and changing an order’s items use the existing separate abilities. All four abilities start off. An order note records a request; it does not change items, an address or a payment, and does not prove that staff carried out the request. Product search and new checkout links are separate from changes to an existing order.

The bot explains what it can and cannot do and hands unsupported requests to your team, subject to the Anything else policy below.

Where to find it

Open Bot → Handbook → Our policies → Order changes with Shopify connected. The action’s invocation rules are under What [assistant name] does when…; the heading uses your bot’s name.

Set it up

Connect Shopify if it is not already connected.
Open a change type by selecting its name, Who can ask or Approval value.
Review When it’s allowed for your store’s fulfilment process.
Select the available methods under How it’s done and fill in any required option details.
Choose Who can ask and Approval.
Check On and the ability’s availability message. If the existing ability is off, follow its link to turn it on only when your store is ready.
Review Anything else for requests that fit no type.
Wait for the save status at the top of the page before leaving.

For each ability, review its own Approval as well as the type’s approval choice. Choose Always ask if staff should approve each change, or Auto for eligible changes to go through. Set who may approve and write guidance in its invocation rules about when the bot should offer it. The bot may explain this policy to the customer.

Existing policies save as you edit: text saves after a short pause, while switches and choices save when selected. Done closes the editor; it is not a separate Save step. Errors appear in the editor, with field-specific messages where available.

To create a policy, choose Add a change type, select an Ability, enter a Name, then choose Save. Open the new type to choose its methods and other rules. A new custom type has no methods selected and no custom instructions, so it is not yet in effect. Its ability cannot be changed after creation.

Settings

Shared fields and defaults

Setting	What it does	Default
When it’s allowed	Your eligibility wording for this type. Clearing a preset’s custom wording restores its current standard wording. It does not edit the action’s invocation rules.	See the preset table below. A custom type starts without an extra eligibility limit.
How it’s done	Selects ways to carry out this type. An option requiring another ability also needs that ability to be available and on.	See below. Custom types start with none selected.
Custom instructions (optional)	Broadens what the bot may do within the type’s primary ability; see the warning below.	Empty.
Who can ask	Verified on the order accepts verified contact details carried by that order, or the customer’s proven store account. Proven account owner requires proof of the customer’s own store account. Typed contact details alone are not proof.	Items: Proven account owner. Every other preset, including pickup: Verified on the order. Both choices are selectable for every type. Custom types use proven account for the order-edit ability and verified on the order for the other abilities.
Approval	On its own removes this type’s extra person-approval requirement. A person approves adds that requirement. Neither bypasses the ability’s own approvals, limits or customer-proof checks.	On its own.
On	Includes this type only if its ability is supplied and it has a selected method or nonblank custom instructions.	On, but this does not turn on the ability.
Name	Names a custom type. Preset names are fixed.	Required when creating a custom type; 1–60 characters.

Custom instructions are not just an extra note. Nonblank instructions let the bot use any supported operation of the type’s primary ability, rather than only its selected methods and their parameter restrictions. Methods belonging to another ability still need their checkbox and that ability to be available. This does not enable missing abilities, remove the customer’s proof requirement or override money limits. For Anything else, custom instructions remain limited to its order-note ability.

Preset defaults

All presets start On, with Approval → On its own. These are policy defaults, not a promise that their methods can run in this build. Unlisted optional methods start unselected.

Change type	Standard When it’s allowed	Selected methods by default
Delivery date	Not shipped yet; the date is at least one business day away.	Set the store’s delivery-date field, with Field name set to `Delivery-Date`.
Courier instructions	Not delivered yet.	Set the delivery-instructions field; its field name starts empty.
Note for the warehouse	Not shipped yet.	Add an order note.
Gift message	Not shipped yet.	Set the gift-message field; its field name starts empty.
Pickup instead of delivery	Not shipped yet; the customer chooses a pickup location from the store’s list.	Remove the shipping charge and refund it, and Add an order note.
Shipping address correction	Not yet reached the warehouse.	Change only the corrected fields, and Add an order note saying what changed.
Contact email or phone	Any order.	Change the order contact.
Items, size, grind, quantity	Unfulfilled items, until the order is picked.	Preview and confirm the new total, which stays selected, and Refund the difference to the original payment.

An item change still follows the existing preview, customer go-ahead and payment-or-refund process described in the store-actions guide. Selecting this type does not replace that process.

Option details appear under the method that uses them. Tag and other editable field names start empty unless listed above. Address fields takes field keys separated by commas; blank allows any address field. The courier method for address line 2 has a fixed field selection, not an editable list. Do not guess your store’s field names: confirm them with the person managing the store before using a method that needs one.

Anything else

What should happen selects the fallback when no change type fits:

Choice	What happens
Note it and tell the customer — default	Adds an order note when that ability is available, and tells the customer. If notes are unavailable, hands the request to the team instead.
Hand it to the team	Asks the team to handle the request rather than changing the order.
Decline politely	Declines the request rather than changing the order.
Custom instructions	Follows your Custom instructions. Empty text authorizes no order change. These instructions do not unlock abilities beyond order notes.

The optional instructions field stays available as a collapsed field whichever fallback choice is selected. You can open it and prepare or save text without changing the active choice. That text is used only when you select Custom instructions; preparing it does not replace Note it and tell the customer, Hand it to the team or Decline politely.

The fallback’s note uses Verified on the order and On its own, subject to the existing note ability’s checks. This editor offers the fallback choice and custom text, not separate Who or Approval controls.

Money limits

For an order-edit type, the table and editor show the existing ability’s money bounds. Change limits opens that policy. Amounts, approval audiences and other ability limits remain owned by the store-action policy; choosing a type or On its own does not replace them.

Shipping address and contact ability

Change shipping address & contact starts off. Once you enable it, its Approval starts on Auto. Always ask instead requires staff approval; Who may approve selects the staff allowed to give it and starts without a selected audience restriction. The change type’s own approval rule still applies.

By default, address and contact corrections accept a customer’s verified email or phone carried by that order, or proof of their own store account. Your store can require the stronger account proof instead. Typed contact details or an order number alone are not enough. Staff approval does not replace customer verification. Item changes keep their stronger account-proof default.

What happens when…

A customer asks to correct an address or contact detail

The bot changes only the fields the customer asked to correct. For example, a city correction keeps the street, name, postcode and other address fields as they were. If the requested correction is unclear, the bot can ask which changed value the customer means. The request itself is the go-ahead for the named correction; your staff approval rules still apply.

The result tells the customer which fields were confirmed changed and that the rest was kept. It does not repeat the untouched address. For an address correction that needs staff approval, the card includes the full proposed address for the team to review.

Courier instructions belong in the second address line

If your store’s courier policy uses the second address line, it also needs Change order details enabled, that delivery-instruction option selected in the store policy, and Change shipping address & contact enabled with the extra address access. Enabling the shipping ability alone does not make this courier option available.

The order has reached the warehouse

The bot refuses a new address correction and directs the customer to the team. Email and phone corrections do not have this warehouse restriction. If the warehouse takes the order while the address is changing, staff must confirm the new address with the warehouse. Saving an address in Shopify is not proof that the warehouse will use it.

An address correction changes the balance

The team must check and settle it in Shopify. The address-correction action does not charge the customer, refund them or send a payment request. A balance issue and a warehouse-confirmation issue can both need attention.

The order email changes while an item edit is pending

The old edit proposal and any approval for it can no longer be used. The bot needs a fresh proposal tied to the current order email before committing the edit. Your current approval rules decide whether that new proposal also needs a person; Auto is not changed into mandatory staff approval.

A customer asks to change the billing address

This ability does not change it. The bot gives the customer the team route instead.

Two people change the same order field at once

For ordinary order fields, the later save wins. For extra order fields that Shopify protects, the bot’s change is refused if the field changed in between, and it is never written over the newer value.

Shopify does not confirm a change

The bot does not say the change was made. It does not repeat it blindly. Your team gets a request to check the order in Shopify first. See Team channel and staff requests.

A customer asks for something the abilities do not cover

Requests outside these abilities follow Anything else. These four abilities do not cancel orders, issue standalone refunds or change the billing address. Refunds that settle an item or shipping-charge change still follow the existing order-edit process.

A policy is saved but is not in effect

There are three different cases:

Not available yet: the underlying ability is missing in this build. There is no ability switch here that can enable it.
The ability exists but is off: the message names the ability, and its link opens the existing switch. Turning on the type alone is not enough.
The ability is available but the type is off, or has no selected methods and no custom instructions: turn on the type and choose a method or add instructions.

An unavailable secondary method cannot be selected in the editor. Its saved selection does not make that missing ability executable.

You reset or delete a policy

Reset to defaults on a preset or Anything else asks for confirmation, then removes your overrides for that policy. It does not reset the ability’s switch, invocation rules or money limits. Presets cannot be renamed or deleted.

A custom type can be renamed and edited, or removed with Delete change type after confirmation. It cannot be reset like a preset. Requests that no longer fit a type follow Anything else. Deleting a policy does not undo an earlier order change.

Someone else changes the same policy

The save is refused and the latest saved values are shown. Review those values before editing again; do not assume your earlier text was saved or automatically combined with theirs.

Troubleshooting

Address corrections are unavailable, but email or phone corrections work. Address changes need additional Shopify access. Follow the authorization guidance; switching the ability off and on does not grant it.
The result is not confirmed. Have your team check Shopify before trying again. omotto checks what happened rather than blindly repeating an uncertain change.
The order is with the warehouse. Ask the team to coordinate the correction; another approval does not make the address action eligible.
The block is missing: check that Shopify is connected and that you can view the Handbook. Ask a workspace administrator if you cannot edit it.
A field value is refused: your text and the field errors stay visible. Correct the value to save a new change, or choose Dismiss failed change to return to the saved values. Eligibility and custom-instruction text each allow up to 1,000 characters.
A save fails because of a connection or service problem: choose Retry failed change to send that failed change again. It is not retried automatically. Dismiss failed change drops the failed draft and restores the saved values.
You close the editor or fold its section after a failure: the failed draft stays available for review when you return on the same page. Reopening it does not send it again. Do not rely on this draft surviving a page reload or closing the browser.
You move to another type with unsaved changes: choosing Discard in the confirmation drops the draft you are leaving. Choose Keep editing if you still want to review or correct it. Dismiss failed change also explicitly drops a failed draft.
Someone else changed the policy: the latest saved values replace your earlier draft. Review them before editing again; your earlier change is not automatically resent.
A policy says On but nothing runs: check the ability status and selected methods as described above. A catalog entry is not proof that a Shopify write is supported.
A customer still needs staff approval: check both the type’s Approval and the ability’s own money and approval policy.
You cannot confirm whether a store change completed: check the recorded result and the order before retrying. A saved policy is not proof of a completed store change.

If the problem remains, contact omotto support with the change type, approximate time and error shown. Do not send passwords, verification codes or store credentials.