With the recent update, checkout customisations (i.e. hiding shipping options) are now also implemented in admin/draft orders.
I would like to know, what is the rationale behind this decision? Why did the developers/management think this was a good idea?
For context, we have two shipping options that our CX/Marketing team use exclusively: “CX Free Shipping” and “CX Free International Shipping”. These are used when creating draft orders for product replacement, testing, and marketing. We then use checkout blocks to permanently hide these from regular customers in the front-end.
With the recent update, because checkout customisations are also implemented in admin/draft orders, these options are now hidden from everyone.
At the moment, we have two workarounds:
Create a marketing customer account, tag that account as “staff”, and update the checkout blocks to not hide those shipping options if customer is tagged as “staff”. And then for every draft order that we make, we change the address. This works for b2c but not for b2b where customer obviously wants to keep their own record of their order history.
Update checkout blocks to show those shipping options if customer is tagged as “cx free shipping”, tag customer, finish the draft order, then un-tag the customer so they don’t see those shipping options when they place their own order. Works but is exhausting as it adds too many unnecessary steps.
So again, what is the rationale behind this update? And how can we circumvent this in the admin side without exposing said shipping options in storefront / checkout side?
A simple solution would be to add a “disable in admin” option for all checkout customisations.
I think a checkout context variable we can pull from the input would be helpful. Something where we can check the value and see if we’re running on “Online Store” “Draft Order” “Accelerated Checkout” etc, then we can have our functions take that context into consideration.
Previously when these did not run on draft orders, I had also pitched a similar set up you’re dealing with “Since these won’t run on draft, we’re good to just hide them for systems that do support these”
At the moment, we ended up instructing our marketing/cx staff to use custom shipping option and set value to $0.00. Still not a fool-proof method as the custom shipping option has to be mapped in our WHS and is prone to human error as it is case-sensitive and all.
Hey @iconjen, could you clarify if the issue is that you don’t want delivery customizations to run in the admin context, but you’re okay with them running during draft order (buyer-facing) checkouts?
What’s the rationale behind this preference?
We’ve seen strong demand from merchants with CX teams who want consistent business rules, including delivery customizations and checkout validations, to apply in draft order contexts. Without this, CX teams often make errors or create orders that conflict with store policies, leading to order cancellations and poor customer experiences.
That said, I understand there are cases like yours where it’s preferable for delivery customizations or checkout rules not to apply in the draft orders context. I’d love to explore a resolution that can accommodate both scenarios.
Hey mate, sorry for the confusion. We only want the customisations running in the storefront (customer-facing). That includes draft orders made by customers in checkout.
Thank you for answering my question. I guess it made sense at the time that decision was made. But forward-looking, it’s not very flexible. So hopefully this can be amended.