Shopify actions, limits and staff approvals

Shopify actions let your bot issue discounts, arrange refunds or credit, manage customer codes, resend payment emails, add order notes, change order details and correct shipping addresses or order contact details. This guide is for owners who want to choose which actions are available and when staff must approve them.

How it works

Looking up an order is different from changing something in your store. A lookup reads information; an action changes something or sends an email. First connect your Shopify store. Product search, product cards and checkout links are covered in the Shopify catalog guide. The rules for assessing complaints and repeated allowances are in complaints and allowances.

You can limit issuing a discount, changing store credit, refunding an order, sending its payment request email, changing an order or adding an order note to Verified user · Shopify. First enable the Shopify user source and select it in the action’s membership requirement. If a store account the action would change is not the account that passed that check, the bot refuses without making the change. Staff approval does not override this check. Turning the source off before execution also stops an action that already passed the check; turning it back on does not revive that earlier authorization. This additional account-agreement rule does not apply to updating or deactivating an existing discount code; those actions keep their existing ownership checks.

Orders, discounts and store credit

These four capabilities start on for a connected store. Order and discount lookups do not change the store. Moving an existing balance between the same customer’s own accounts is a separate action. It starts on and runs on its own; adding new money still needs the allowance rules.

Capability	What the lookup covers	What it does not do
Find my orders	Finds orders from the customer’s accessible store accounts, including accounts associated on conversation evidence as explained below, with status and available tracking details.	Does not create, edit, cancel or refund an order.
Order lookup	Reads a specific order by number after checking ownership. Results can include payment and fulfilment status, items, tracking links and delivery estimates supplied by the store.	An order number alone is not proof of ownership. It does not change the order.
Discounts lookup	Checks an exact code the customer supplies. For a verified linked store account, it also supports reading that customer’s codes, including codes staff created in Shopify.	Does not create a code or change an existing one. Other customers’ private codes are not disclosed.
Store credit lookup	Reads balances from accessible store accounts, including accounts associated on conversation evidence, separately for each account and currency.	The separate Move store credit between the customer’s own accounts action moves existing credit, as explained below. A missing account association or failed read is not a zero balance.

If the store-account or discount search is incomplete, the discount list is partial even when no codes were found. If the store cannot be checked, a linked customer may see only codes the bot previously issued, clearly marked as a limited fallback rather than the store’s complete list.

An order-status link is not always returned, even when some order details are available. Tracking links and delivery estimates are included only when the store supplies them. If an order search reports an incomplete history, treat it as a partial list, not proof that no other order exists.

Verified ownership and missing orders

A customer’s typed email, phone number or order number is not enough by itself. Order reads use verified contact details or an established store-account link. Where related-customer sharing permits it, the accessible orders may also include an authorized related customer’s orders.

If an order cannot be matched, check which email or phone was used at checkout. The customer may need to verify that address or number with a one-time code before another lookup. See verification and User identification and linked identities. Do not ask customers to send someone else’s order details as proof.

Store accounts associated on conversation evidence

Sometimes an order connects another store account to the customer’s verified contact details only through its delivery or billing details. That match alone does not establish ownership of the whole account. The bot can judge the relationships in the evidence and the conversation, then associate the account with this customer. This is called adoption; it is not proof that the customer controls the account’s email or phone.

An active association makes the account’s order history available to Find my orders and its balances available to Store credit lookup, subject to current access checks and search limits. It applies across linked profiles of the same person. Other members of a customer group do not inherit that association, even if other sharing is allowed.

Staff get a short explanation in the conversation, not a customer message, bell notification or approval request. The customer profile shows Adopted store accounts with the connecting order and explanation. Staff with permission can choose Undo. Undo removes this association’s access across the same person’s profiles, not access supported by independent verification. Changed evidence can also invalidate an association automatically; the profile guide explains how this differs from staff Undo.

An active association also counts as the customer’s own account for order lookup, refunds, payment requests and supported order changes. Discount lookup includes codes bound to their adopted accounts. Updating or disabling a code still requires that the code belong exclusively to one of this customer’s own accounts, not a public or shared code. Existing capability, limits and approval rules still apply.

Adoption does not change the default destination. A new discount uses the usual default account unless the bot explicitly chooses another account the customer owns. Approval fixes that account; it is checked again before issuance. Credit moves have separate account-ownership and balance checks. Staff Undo withdraws the association’s authority. If the phone evidence becomes too old, customer-facing actions pause until that evidence is confirmed again.

Moving existing store credit

When credit is stranded on another account that belongs to the same customer, the bot can move it between their own accounts. This includes an active adopted account. The total must stay unchanged in each currency; amounts are never converted. The move action starts On its own. Choose A person approves to send each move to an approval card. Under that setting, a batch that also adds or removes money is refused; send the move separately. A move does not count as a new allowance or use an allowance frequency window.

Adding money follows your existing complaint-handling limits, allowance frequency window and approval rules, separately for each currency. Reducing the total in any currency always needs a person to approve it, even when automatic approval is otherwise enabled. If one currency increases and another decreases, both sets of rules apply. Staff see fixed account targets and currencies on the approval card; they may change the amounts, not those targets.

The source balance is checked again before money moves. A completed move leaves a short note in the conversation. Undo on an adopted account removes its association; it does not reverse money already moved. The Move store credit between the customer’s own accounts switch is in Handbook → Our policies → Service actions. Turning it off stops new moves. Reconciliation and restoration of a move already under way still complete.

If Shopify’s answer is uncertain, omotto stops further changes on the affected accounts and checks what actually happened. Your team receives a notification if reconciliation is needed. Do not repeat the change manually until you have checked the store’s balances and transactions; contact support if it remains unresolved.

What the store-action rows cover

The Handbook’s Our policies section has Allowances, Existing codes nested under Discount, and Service actions.

Row	Scope
Discount	A new single-use code for this customer: percentage off, a fixed amount off, or free shipping.
Refund	A refund against an existing owned order to its original payment method, subject to the order’s refundable amount.
Store credit	Credit added to an established customer store account. This is a balance for later purchases, not a refund to a bank card.
Update discount code	Changes combination permissions, expiry or a minimum purchase/item requirement on this customer’s existing code. It does not change the code’s discount value.
Deactivate discount code	Stops this customer’s existing code from being used.
Send payment request	Resends Shopify’s payment request email for an owned order that still has an unpaid balance. It is not a tax invoice or receipt, and it does not charge or refund the customer.
Add order note	Appends a dated line to the note on the customer’s own order for the store team. It keeps the existing note; it does not change the ordered items or arrange fulfilment by itself.
Change an order	Changes supported unfulfilled items, shipping charges or item discounts on the customer’s own order after a preview. The same action handles its resulting payment request or refund. Starts off.
Move store credit between the customer’s own accounts	Moves existing credit between this customer’s own accounts; each currency’s total stays the same. Starts on, runs on its own.
Change order details	Sets delivery dates, delivery instructions and gift messages in your store’s own order fields, and adds or removes tags, on the customer’s own order. Starts off.
Change shipping address & contact	Corrects named shipping-address fields before warehouse handoff, or order email and phone on any eligible order. Keeps other address fields. Starts off.

These are specific supported actions, not a general order editor. They do not cancel an order or change its billing address. Shipping-address corrections use their own action and additional Shopify access. Arrange work outside the supported actions with your Support Team, or use a manual allowance for something the team will fulfil.

Where to find it

Open Settings → Bot → Handbook → Our policies for store-action switches, amounts and approvals. Store-action rules and built-in lookup instructions are in What [assistant name] does when…. The Complaints & goodwill rule hosts Who is this for and Required verification; Discount’s ordinary approvers are in its separate staff approval row. Customer sharing is under Customers → Settings → Related customers.

Set it up

Open Our policies in the Handbook listed above.
Turn on the actions your business wants to offer.
Open the relevant Allowances or Service actions row.
Choose Show advanced options in the page header.
Set the relevant limits using the settings reference below.
Choose the staff audiences for approvals you require.
Review Who is this for and Required verification on the Complaints & goodwill rule.
Wait for saving to finish before leaving the page.

Advanced options start hidden. Policy changes save automatically; text and number fields may save when you leave the field. Wait for saving to finish before leaving the page. Viewing settings does not give you permission to change them. If controls are unavailable, ask your workspace owner to check your permissions.

Enabled does not mean automatically approved. The policy row’s on/off switch controls whether a store action is available; its other controls set the conditions under which it may proceed. Shopify’s built-in allowance rows start enabled, but existing choices in your workspace are preserved. The four order-change abilities each start off and have their own switch. There is no second Order changes switch. Enabling a lookup does not enable a write action.

Settings

Instructions and advanced verification

Open the lookup’s built-in rule in Handbook → What [assistant name] does when… to see its editable fields. Unchanged abilities are under Unchanged rules; use Show to reveal them. Instructions customizes how that lookup should be used; clearing a custom override restores the built-in instructions. Instructions do not turn a read-only lookup into a store action. Change Required verification inside the rule’s Who is this for control. Proof and audience changes count as customization on that rule.

Where a Verification section is present, its controls are:

Setting	Options and meaning	Starting behavior
Required verification	No verification, Resource verified or Identity verified. These select the kind of customer proof required; Default (…) restores the capability’s built-in choice. See verification types.	Find my orders: Identity verified. Order lookup: No verification at this configurable layer; its separate ownership check still applies.
Proof recency	Any time accepts earlier proof; This conversation requires proof in the current conversation; Within a set time takes a number of minutes. Until you enter a valid time of at least one minute, changing another setting keeps the saved proof recency. Default (…) restores the built-in choice.	Any time for the order lookups. A short timed window can require another code when proof expires.
When verification applies	Automatic (…) uses the built-in timing. At the action allows discussion before verification but checks before the protected lookup. From the start also withholds that skill’s detailed instructions until verification.	Automatic. This is not a way to bypass ownership.
Who may approve	Restricts the staff who may sign off where an approval is needed. It does not turn the lookup into a paid action or switch automatic approval on.	No restriction to a selected staff audience.

Discounts lookup and Store credit lookup do not have these same configurable verification controls. Their account and disclosure checks still apply.

Shared customer verification for store actions

The Verification controls in Complaints & goodwill apply to issuing discounts, refunds and store credit, updating or deactivating existing codes, sending order invoices, adding order notes, changing order details and correcting a shipping address or order contact. They are separate from the order-lookup settings above.

Setting	What it does	Default
Required verification	Chooses No verification, Resource verified or Identity verified for these writes. Default (…) restores the built-in choice.	Identity verified.
Proof recency	Chooses Any time, This conversation or Within a set time in minutes. Until you enter a valid time of at least one minute, changing another setting keeps the saved proof recency. Default (…) restores the built-in choice. An expired proof can require a fresh verification code.	Any time.

Customer verification proves the customer’s identity or access; staff approval authorizes the action. One is not a substitute for the other. Setting an action to Auto does not remove its verification or ownership checks. Changing these shared controls affects all the listed writes, not only new discounts.

Allowance amounts and automatic approval

Discount, Refund and Store credit use numeric limits rather than a separate Always ask / Auto selector on their Policy row.

Control	What it means	Default
Opening offer (%): / Opening offer (store currency):	The starting value for a proposal. It is not an amount already granted or a promise to the customer.	Discount: 10%; Refund: 10%; Store credit: 10 in store currency.
Blocked below	Minimum permitted value. A proposal below it is blocked unless a bounds-exception approver is selected.	No floor.
Auto up to	Upper end of the automatic-approval band, subject to the remaining identity, policy and frequency checks.	No auto-approve.
Maximum	Upper end of the normal approval range. Above it, the proposal is blocked unless a bounds-exception approver is selected. Absolute limits still apply.	Discount: 30% and 100 in store currency for fixed amounts. Refund: 100% of the original order total, still limited by what is refundable. Store credit: 100 per currency unless overridden.
Who may exceed the bounds:	Routes proposals below the minimum or above the maximum only to the selected exception approver. This is different from the ordinary approval audience.	No exception approver; outside-bounds proposals are blocked.
Guidance	Explains when this allowance applies and what must be checked. Blank uses the built-in guidance.	Built-in guidance calls for a real, corroborated problem and an appropriate remedy.

With no automatic band, proposals inside the limits need staff approval. With an automatic band, proposals above that band but within Maximum still need staff approval. Repeated goodwill within your frequency window can require staff approval even for a small amount. A repeat refund also has additional review checks; raising a ceiling does not remove them.

The opening offer can be adjusted independently within the minimum and maximum. If you lower a maximum past the opening offer, the editor brings the opening offer inside the new range. An opening offer above Auto up to does not become automatic just because it is the default.

For example, with no floor, automatic approval up to 10% and a maximum of 20%, an 8% proposal is in the automatic band, 15% needs approval, and 25% is blocked unless an exception approver is configured. Other checks still apply in all three cases.

Currency-specific limits

Store credit supports Max per currency:

Choose + Add currency.
Enter a three-letter Currency code, such as ILS for Israeli shekels or USD for US dollars.
Fill at least one of Minimum amount, Automatic approval ceiling or Maximum amount.

Each amount left blank uses its corresponding general limit. This applies even when the currency has its own row. For example, setting only a currency maximum keeps the general automatic approval ceiling; it does not turn automatic approval off. A currency with no row uses all the general limits. Each currency can appear only once. To remove an override row, choose Remove currency cap.

Refund has its main percentage limits and optional per-currency monetary ceilings. Its currency rows contain a maximum, not a second minimum or automatic band. Both the percentage limit and any applicable monetary ceiling matter. A cap is not a currency-conversion instruction.

Store credit must use a currency the store supports. The default is the store currency; omotto does not silently convert an unsupported request. Review the actual currency on the approval request. For customers, Shopify shows spendable credit in the checkout’s currency; see Shopify’s store-credit guide.

Refund details are separate from the policy defaults

A refund proposal can specify a money amount in the order’s currency or particular items and quantities. Restocking those items and refunding shipping are separate choices; both start off unless requested. A refund is not an order-cancellation action. Review the proposed details as well as the amount before approving.

Absolute limits: not overridable by staff

These are omotto limits, not claims about Shopify’s own maximums. A percentage discount must be a whole number from 1% to 90%. A refund or store-credit grant cannot exceed 100,000 units of its transaction currency — for example, 100,000 ILS, not 100,000 agorot. An exception approver cannot override these limits. Refunds also cannot exceed the amount still refundable on the order.

Discount settings: type, prefix, validity and combinations

After enabling the page’s Show advanced options action, find Discount settings in the Discount row. The advanced-options action is in the page header, not inside the row.

Setting	What it does	Default
Percentage	Makes percentage discounts the default kind. Its percentage band remains separately configurable.	Selected; opening offer 10%, maximum 30%, no automatic band.
Fixed amount	Makes an amount in the Shopify store’s currency the default kind. Set its own minimum, automatic ceiling and maximum.	Not selected; maximum 100 in store currency.
Free shipping	Makes a shipping-discount code the default. Percentage and amount bands do not apply to this kind.	Not selected. With no numeric automatic band, it needs approval.
Code prefix	Beginning of newly generated code names. English letters are uppercased; only English letters and digits are kept. An empty result uses the default.	`SAVE`.
Maximum validity (days)	Caps new-code validity and extensions of an existing code, measured from the code’s start. If no expiry is requested, a new code automatically expires after this interval. Use a positive whole number of days; zero does not disable expiry. Clearing the override restores 90 days. Shortening an existing expiry remains possible even if the code is older than this window.	90 days.
Combination policy	A read-only explanation of the combinations omotto permits, not a switch to allow arbitrary stacking.	Percentage/amount codes combine with shipping discounts only. Free-shipping codes combine with order and product discounts only.

Selecting a default kind does not disable the other supported code kinds. New-code proposals may include a minimum purchase amount or minimum item count, dates, and a shipping-price restriction for free shipping. Those are details of the proposed code, not extra permanent settings in this panel.

Shopify also checks whether the other discount permits the combination. The policy above describes omotto’s restrictions, not every combination Shopify supports. See Shopify’s official combination rules.

Existing codes: inherited policy, not a second discount allowance

Update discount code and Deactivate discount code appear under Discount → Existing codes. Their enabled state follows Discount; they do not have separate on/off switches.

Update discount code inherits Discount’s numeric limits and ordinary approval audience. Who may approve shows Inherited from Discount rather than another editable pool. The code’s existing value is used when evaluating the limits. The row keeps its own Guidance.
Updates are limited to combination choices, expiry and the minimum purchase or item requirement. Unchanged details stay unchanged. Updates cannot be used to bypass the validity or combination policy.
Deactivate discount code has its own Approval choice: Always ask or Auto. It starts on Auto, and has its own Who may approve and Guidance controls.
These management actions are for the current customer’s own supported codes. Public/shared codes and another customer’s private code are not editable through this flow. A code being readable does not make it editable.

If an existing code cannot be changed under the policy, have staff review it rather than repeatedly asking for the same blocked edit.

Service actions: change an unfulfilled order

Change an order supports adding a product option, changing a quantity, adding or removing a shipping charge, and adding an item discount. A replacement combines removing the old item with adding the exact new option. It does not edit the shipping address or cancel the order.

Enable Change an order only when your store is ready. This action has one switch; it does not require a separate Order changes switch. A store reconnection may be needed to grant the additional Shopify permission.
Set the action’s approval audience, money limits and store-specific guidance.
Review the preview before confirming a change: exact items and options, discounts, shipping charges, currency, price difference and remaining balance.
If the balance changes before execution, review a fresh preview and obtain the customer’s go-ahead again.

Ownership follows the store’s policy for the kind of change. It can require a verified email or phone carried by that order, or proof that the store account belongs to the customer. A typed order number, email or phone alone is not enough. Permission to read a related customer’s order is not permission to preview or edit it.

By default, item changes require the customer’s own proven store account. Switching to pickup and adding order notes instead accept verified contact details carried by the order, or the customer’s proven account. Each kind of change can use either requirement. Ownership and the current store policy are checked again before execution; staff approval does not replace those checks. Configure these choices in the order-change policies guide, which separates each type’s eligibility and methods from the action’s invocation rules and money limits.

The bounds apply to the size of the price difference, whether the change costs more or less. The default maximum is 100 in the order’s currency, with no positive automatic-approval ceiling. A permitted zero-difference change can run automatically after you enable the action; a positive minimum still applies. Ordinary nonzero changes start with staff approval required. The maximum, any currency-specific bounds and the absolute execution limit still apply when manual approval is not required. There is no opening-offer or discount-code setting on this service action.

The approved change includes its settlement. If money remains owed, omotto requests Shopify’s payment-link email for the order. If this change owes money back, it refunds that attributable amount to the original payment method. Do not create a separate goodwill refund for the same difference. An earlier unpaid balance can mean the amount due is larger than the change itself. A zero balance needs no payment email. An accepted email request is not proof of delivery or payment. If the order’s email changes while an edit is pending, the old proposal and approval cannot be used; a fresh proposal must bind the current recipient. The current policy decides whether it also needs staff approval.

If the result is unconfirmed, stop retrying. Staff must check Shopify and settle any payment or refund manually. Only someone allowed to approve this action can then mark its internal need as handled; doing so does not send another edit or refund. Automatic recovery reads back a completed change; unfinished settlement is handled separately. Large or incomplete order previews are handed to staff rather than applied from partial details.

Service actions: resend an unpaid order invoice

Under Service actions, Send payment request has:

Setting	Meaning	Default
Approval	Always ask requires staff sign-off. Auto removes that manual approval step for an eligible send; it does not skip ownership, recipient or daily-limit checks.	Auto.
Who may approve	Limits who can sign off when staff approval is required. Select a person, role, group or other offered staff audience.	No selected audience restriction.
Daily limit	Caps payment-request resends per day across the whole store, not per customer. Use a positive whole number; zero does not disable sending. Clearing the override restores 20. Checked before a proposal and again before sending; unconfirmed attempts use space too. Even an approved request is blocked if the day’s allowance has been used up.	20.
Guidance	Your store’s policy for when to resend a payment email. Eligibility checks always apply.	When the customer needs the payment email resent for an owned order. Blank restores this guidance.
Related customers	Points to the sharing policy rather than creating a separate Shopify sharing rule.	Managed in the customer sharing settings listed above; see customer groups.

The daily count uses your business’s time zone, not the signed-in staff member’s time zone.

Only a pending or partially paid order with a positive outstanding balance qualifies. Shopify sends the saved payment request to the order’s email address. A different recipient must be an address the customer verified with a one-time code; related-customer use also depends on sharing permission. The order must still have a saved email address. If it is missing, have staff add it in Shopify before trying again.

The email contains a way to pay. Sending it is not collecting payment, and Shopify accepting the send is not proof that the email was delivered or the customer paid. See Shopify’s payment-email explanation.

Payment-request resends and existing-code management are service work, not new goodwill grants. Complaint frequency windows and allowance-offer wording do not apply to those actions.

Service actions: add an order note

Use Add order note to pass an agreed packing request or promised extra to the store team. The bot appends one dated line and keeps the existing note. A saved note does not change the ordered items, shipping address or payment, and is not proof that the store team fulfilled the request.

Enable Add order note under Service actions in Our policies. It starts off and has one switch; there is no separate Order changes switch. Then review that action’s settings:

Setting	What it does	Default
Approval	Always ask requires staff approval; Auto allows an eligible note without that manual step. Customer verification and order ownership still apply.	Auto, once the feature is enabled.
Who may approve	Restricts who can approve when staff approval is required.	No selected audience restriction.
Your rules	Explains when an order note is appropriate and your store’s workflow for it. Edit the store action’s rules in the Handbook. This is store policy the bot may explain to the customer; it cannot change the built-in append-only behavior.	Record changes or promises the warehouse needs to act on.

There is no monetary limit for a note. It is service work, not an allowance, so allowance frequency windows do not apply. Being allowed to read an order does not necessarily prove permission to add a note to it. If Shopify access is missing, have staff reconnect the store. If the result is unconfirmed, check the note in Shopify before treating it as saved or starting another request.

Service actions: change order details

Use Change order details to let the bot set the delivery date, delivery instructions or a gift message that the customer asked for, in the order fields your store already uses, and to add or remove tags. Examples: moving the delivery date to a day the customer picks, adding a gift message, or tagging an order gift. See Order changes for how the four order abilities fit together.

Enable Change order details in Handbook → Our policies → Service actions. It starts off and has one switch; turning it on does not ask you to authorize your store again. Then review that action’s settings:

Setting	What it does	Default
Approval	Always ask requires staff approval; Auto allows an eligible change without that manual step. Customer verification and order ownership still apply.	Auto, once the feature is enabled.
Who may approve	Restricts who can approve when staff approval is required.	No selected audience restriction.
Guidance	Explains when changing order details is appropriate. This is store policy the bot may explain to the customer.	When the customer wants details on their own order set or corrected.

The bot changes only the fields it was asked to change. Every other field, tag and value on the order is kept. It never changes items, money or the shipping address. If two people save the same order field at nearly the same moment, the later save wins for ordinary fields; a metafield that changed in between is refused instead of overwritten.

If the result is unconfirmed, do not ask the bot to repeat it. Check the order in Shopify first; the team is told when a change could not be confirmed.

Service actions: correct a shipping address or order contact

Change shipping address & contact starts off. Its Approval starts on Auto after enabling; Always ask requires staff approval. Who may approve starts without a selected audience restriction. Guidance describes when your store wants to use the action. A change type’s own requirement for a person still applies.

Address and contact types default to accepting verified contact details carried by the order, or the customer’s proven store account. Your store can require proven account ownership instead. A typed order number or contact detail is not enough, and staff approval does not replace this customer proof.

The customer’s request is the go-ahead for the named fields, with clarification if the correction is unclear. The result reports only confirmed changed fields and that the rest was kept; it does not repeat untouched address fields. For an address correction requiring staff approval, the card includes the full proposed address. Address corrections stop at warehouse handoff and need additional Shopify access approved by the store; email and phone corrections have neither that fulfillment restriction nor those extra address-permission requirements. Billing-address changes are not supported.

This action never settles money. If an address correction changes the balance, the team must check and settle it in Shopify. If handoff races the correction, staff must also confirm the new address with the warehouse. For examples, missing-access steps and uncertain results, read Order changes.

Ordinary approvers, exception approvers and reset

Who may approve and Who may exceed the bounds: serve different purposes. The first restricts ordinary staff sign-off. The second authorizes a specific outside-bounds review route. Selecting an ordinary approver does not by itself permit exceeding a maximum.

Approver choices can include a person, a team role, a group or the whole workspace. Keep those memberships current under team members and groups, and configure the team channel for staff requests.

Discount’s ordinary approvers belong to the separate staff approval row on the Complaints & goodwill rule, not its customer audience. Refund and Store credit expose their own Who may approve controls in the advanced Policy options. Existing-code updates inherit Discount’s audience; deactivation, payment-request resends and order notes own their own audiences.

Reset to default on a customized Shopify row restores that row’s amounts, code configuration and guidance. It does not change the on/off choice. Separate approval choices are not reset by that button.

omotto may count a sale as bot-assisted within a set time after the bot’s help; omotto sets this window, not your workspace.

Read Analytics for the difference between sales linked through checkout evidence and sales associated through identity and timing. Association does not prove that the conversation caused a purchase. Sales that cannot be linked are not included in attributed totals.

What happens when…

A proposal is outside your configured limits

Only the selected bounds-exception approver can authorize that review route. Their approval can override your configurable minimum or maximum, but never the absolute limits above. Customer verification, ownership and the other action checks still apply.

A code proposal has no requested expiry

The new code automatically expires after Maximum validity (days), counted from its start. With the shipped default, that is 90 days. Leaving the expiry out does not create a never-expiring code.

Staff approved an action, but it did not complete

An allowance may be proposed, approved, and then fail to complete. A store disconnection, changed order, insufficient refundable amount, unsupported currency or provider error can prevent fulfilment. Check the recorded action result and Shopify before telling the customer that a refund, credit or code is complete.

If a refund, credit or invoice send has an uncertain result, do not repeat it just to get a clearer answer. Have staff check the order, balance or email send in Shopify first. A second approval does not resolve an uncertain first attempt. Refund availability and destination are also subject to Shopify’s rules; see Shopify’s refund guide.

Troubleshooting

A lookup works but allowances are unavailable. Check the separate action switch, the Shopify connection and Complaints & goodwill in Core. Enabling Discounts lookup or Store credit lookup is not enough to enable issuing.
An amount below the maximum still asks staff. Check Auto up to, the ordinary approval audience, recent goodwill and any repeat-refund warning. Maximum is not an automatic-approval threshold.
An outside-bounds proposal is blocked. Check the absolute limits as well as Who may exceed the bounds:. Leaving that selection empty blocks exceptions, even if its shared picker describes the empty choice as unrestricted.
A valid code cannot be edited. Reading a public code is allowed in circumstances where editing it is not. Check customer ownership, the supported code type, expiry and combination policy.
Payment-request resend is blocked. Check ownership, the unpaid status, positive outstanding balance, recipient verification, daily limit and whether an earlier send remains unresolved. Do not keep retrying an unconfirmed send.
Credit balance cannot be read after connecting. Review the connection’s permissions and reconnect Shopify if needed. Do not assume a lookup failure means the credit was not issued.

If these checks do not resolve the issue, contact omotto support with the affected action, approximate time and the error shown. Do not send passwords, verification codes or store access credentials.