Advanced Shipping Rules, Shopify: A Step-by-Step Setup Guide

Advanced shipping rules, Shopify’s own delivery customizations and rate-calculation apps, are what’s needed once a shipping profile’s zones and flat rates can’t express the condition you actually want — hide a rate for one product tag, rename an option for a VIP customer, reorder the list so the cheapest option isn’t the default. Basic profiles, zones and weight bands are covered in Shopify shipping rates; this article picks up where that setup stops working.

Advanced Shipping Rules, Shopify’s Delivery Customizations Explained

A shipping profile decides which rates exist. A delivery customization decides how the rates that already exist are shown to a specific buyer. That split is the whole mechanism behind advanced shipping rules in Shopify, and most of the confusion in setting them up comes from trying to do one job with the tool built for the other.

Delivery customizations live under Settings > Checkout > Customizations, built on Shopify’s Functions platform. A function attached there runs at checkout, reads the delivery groups already calculated for the cart — each one carrying the options a shipping profile, a zone, or a connected rate-calculation app produced — and returns instructions against that list: hide one option, rename its title, reorder the whole set, or move a specific option to a new position.

That’s the ceiling on what a customization can do. It can’t add a rate, change a price, or invent a delivery date. A shopify advanced shipping rules app built on top of this API is doing the same thing through a rules interface instead of code — reading conditions, returning the same four operations.

What You Need Before Building an Advanced Shipping Rule

Three things have to exist before a delivery customization can act on them. First, the condition data itself — a product tag, a customer tag, a cart subtotal, a destination field — has to already be attached somewhere the function can read it, which usually means tagging products and customers in the admin ahead of time rather than inventing a field that doesn’t exist yet.

Second, every rate the rule might need to hide, rename or reorder has to already be returned by a shipping profile, zone or app. A customization can’t act on an option that was never in the list; that constraint drives most of the setup decisions in this article.

Third, decide who’s building it. A store with developer resource can build a custom app with a Functions extension and read any field on the cart object. A store without one needs an app from the Shopify App Store that exposes conditions and operations through a rules interface — narrower, but no-code.

Step 1: Decide Whether the Rule Belongs in a Shipping Profile or a Delivery Customization

Ask one question before building anything: does the rule change a price, or does it change what’s displayed? A rule that says “charge $15 more for orders over 50lb shipping to a remote zip code” is a pricing decision — it belongs in a shipping profile’s zone rates or a rate-calculation app. A rule that says “don’t show the local-pickup option to customers outside a 20-mile radius” is a display decision — it belongs in a delivery customization.

Teams that skip this question tend to build a customization first because it’s the newer, more flexible-looking tool, then discover partway through that the option they need to surcharge doesn’t exist yet. Settling the pricing-versus-display question first avoids that rebuild.

Step 2: Map Every Condition to Real Cart, Customer or Product Data

Write the exact field each condition checks before opening the Customizations screen. “VIP customers get free shipping” isn’t a condition a function can evaluate — “customers with the tag vip-2026” is. The gap between a plain-English rule and a field the cart object actually carries is where most delivery customizations fail silently.

Product-level conditions usually check a tag or a metafield on a line item. Customer-level conditions check a tag on the customer object. Cart-level conditions check the subtotal, the item count, or a cart attribute set earlier in the buying flow. Destination conditions check the shipping address’s country, province or postal code. Pick the smallest set of fields that actually distinguishes the cases you need.

Step 3: Turn On Delivery Customizations in Settings > Checkout > Customizations

Open Settings > Checkout in the Shopify admin and find the Customizations section, which lists any active checkout, cart and delivery customizations on the store. Adding a delivery customization from here means either installing an app built specifically to wrap the delivery customization API in a rules interface, or connecting a custom app that includes a Shopify Functions extension of the delivery-customization type.

A custom app needs to be built and deployed through Shopify’s developer tooling before it shows up as an option to add here — this screen manages and activates customizations, it doesn’t write the logic for you. Confirm the extension type is delivery customization specifically; Shopify’s Functions platform also supports cart, discount, and payment customization types that won’t appear in this section.

Step 4: Write the Function Logic: Hide, Rename, Reorder or Move

Inside the function, the input is the cart’s delivery groups, each one holding the list of delivery options a shipping profile or app already calculated — a title, a handle, and a cost per option. The function’s job is to look at the condition data mapped in Step 2 and return one or more operations against that list, addressed by the option’s handle rather than its display title, since the title is exactly what a rename operation might change.

The four operations cover everything a delivery customization can do: hide removes an option from what the buyer sees, rename changes its displayed title without touching its price, reorder sets the full display order, and move repositions one specific option. Combining operations — hiding one option and renaming another in the same function — is normal and often how a single rule expresses two related conditions at once.

Step 5: Set the Execution Order When Multiple Customizations Are Active

The Customizations screen lists every active delivery customization in the order Shopify runs them, and that order is set by dragging entries in the list, not by anything inside each function’s own code. Each customization receives the delivery-option list as the previous one left it, so a second customization written to rename an option that a first customization already hid has nothing left to act on.

Stores running more than one delivery customization — one for tag-based hiding, another for a loyalty-tier rename, say — need the execution order documented somewhere outside the admin screen itself, because the order is easy to change by accident and hard to debug from the storefront alone once it’s wrong.

Step 6: Add a Rate-Calculation App Where the Rule Needs a New Price

Where the condition genuinely needs a different price — a surcharge, a discount, a rate that only exists for one shipping zone under one condition — a delivery customization on its own can’t deliver it. That work belongs to a rate-calculation app, which connects to a carrier or a custom rate table and returns a carrier-calculated option with the adjusted price already baked in.

Once that app-supplied rate is in the delivery group, a delivery customization can hide it from customers who don’t meet the condition, rename it to something the buyer recognises, or reorder it above the standard options — but the price itself came from the rate-calculation app, not from the customization layer sitting on top of it.

Step 7: Test Every Condition Path With a Real Checkout

Build a real cart for every branch of every condition: the tagged product and the untagged one, the customer with the loyalty tag and one without it, a cart just under and just over a subtotal threshold, and an address inside and outside any zone-based condition. Run an actual checkout for each combination rather than only reading the function’s code, since a condition can be logically correct and still check the wrong field name against a live cart.

Pay particular attention to combinations across more than one active customization — a product-tag rule and a customer-tag rule interacting on the same cart is the scenario most likely to produce a result nobody predicted from reading either rule in isolation.

The Step Most Teams Get Wrong: a Delivery Customization Can’t Invent a Rate

The single most common mistake in building advanced shipping rules in Shopify is treating the delivery customization as if it could create a price. It can’t. It operates strictly on delivery options a shipping profile, a zone, or a connected rate-calculation app already returned to that cart — hiding, renaming, reordering or moving them, never pricing them.

Teams that build a customization to “give VIP customers a $5 shipping rate” find, after testing, that the $5 rate simply doesn’t appear for anyone, because no shipping profile or app was ever configured to produce it. The fix isn’t more logic inside the customization — it’s a new zone rate or a rate-calculation app rule that returns the $5 option in the first place, with the customization then doing the much smaller job of showing it only to the customers who qualify.

How Do You Verify an Advanced Shipping Rule Is Actually Working?

Verification means confirming the rate list a real customer sees, not just confirming the function deployed without an error. A customization that saves cleanly and shows no errors in the admin can still evaluate a condition against the wrong field, or run in an order that undoes what it was meant to do.

Use a draft order or a genuine test checkout for each condition path identified in Step 7, and read the actual delivery options presented at checkout — their titles, their order, and which ones are missing — against what the rule was supposed to produce. A customization is verified when every condition path has been checked this way, not when it has been read once and looked correct.

Who Should Build Advanced Shipping Rules In-House vs With an App?

A store with in-house developer resource, or an ops-automation partner comfortable in Shopify’s Functions platform, gets the full range of conditions the cart object exposes and can combine operations in ways a rules-interface app won’t anticipate. That flexibility costs build and maintenance time — a function is code, and code needs testing on every future edit to the store’s tagging or product structure.

A store without that resource is better served by an app built specifically around the delivery customization API, accepting a narrower set of pre-built conditions in exchange for a UI a non-developer can maintain. This isn’t the right investment for a store running one or two static shipping rules that a zone and a rate can already express — that’s still a shipping-profile problem, not an advanced-rules one.

Advanced shipping rules in Shopify are an ops-automation problem before they’re a checkout problem: the condition logic, the tagging discipline it depends on, and the testing across every path are the same kind of manual-step-turned-repeatable-process that ops automation exists to build and maintain, alongside the shipping software and order management it usually connects to.