How Rulic rules work.

Introduction

Rules compile into native Shopify Functions — payment logic, delivery logic, cart and checkout validation, upsell logic, B2B terms — so agencies stop hand-writing Rust for every client. Today that compiling happens on our end, as part of a custom rule build; the self-serve builder that does it for you is in development as the Rulic Platform.

A rule has three parts: a condition (WHEN), an optional chain of additional conditions (AND / OR), and one or more actions (THEN). Conditions read live checkout, customer, and cart data; actions change what the shopper sees or whether checkout can proceed at all.

Everything on this page — every field, operator, and action — is real, in the sense that it's the actual model we build rules against today. What's still BUILDING is the self-serve UI around it, clearly marked wherever it applies.

Quick start

Here's a complete rule chaining five conditions — tag, approval status, a metafield, cart total, and geography — to decide who actually sees Net 30 terms. This is the level of complexity apps can't express; it's also what we build by default, not the exception:

Drop the resale certificate check and this rule silently overcharges customers who qualify, or the wrong customers get net terms — that's the kind of edge case a single-condition app has no way to express. This is the exact format we turn into a deployed, simulated Shopify Function during a custom rule build. Once the self-serve builder ships, you'll compose and deploy chains like this one yourself — no scoping call, no redeploys.

# want this rule, or a more complex one, built and deployed this week? Request a custom rule →

Conditions

Conditions read from live checkout data: customer, cart, shipping, catalog, and order-history context, plus any metafields you expose. Grouped by where the data comes from:

• Customer & company — customer.tag, customer.company, customer.order_count, customer.email, company.approved, company.metafield(...)
• Cart & line items — cart.total, cart.weight, cart.contains(sku), cart.contains(collection), line.quantity, line.price
• Geography & market — shipping.country, shipping.province, market, currency
• Catalog — product.tag, product.collection, product.vendor
• Metafields — customer.metafield(namespace.key), cart.metafield(...), product.metafield(...) — any metafield you expose becomes a condition, subject to the size constraints below

Combine conditions with AND / OR, and nest them for more complex logic. Most of the rules apps can't express aren't exotic fields — they're 3-5 of these chained together.

Operators

Every condition compares a field to a value with one of these:

• = / != — equals / not equals
• > / < / >= / <= — numeric comparison (cart totals, weights, quantities)
• in [...] / not in [...] — membership in a list (markets, countries, tags)
• exists — a metafield or field is set at all, regardless of value
• contains(...) — cart contains a given SKU or collection
• is empty — a field (typically customer.tag) has no value, for targeting untagged/retail customers

Actions

Actions span payment, delivery, validation, and upsell logic — this isn't a payment-customization tool that happens to also touch shipping.

• Payment — show / hide / rename / reorder a payment method
• Delivery — show / hide a shipping method, force freight, set carrier or rate
• Validation — block checkout with a custom message, enforce MOQ or quantity caps
• Upsell — surface a bundle or add-on, apply a conditional discount, cross-sell based on cart contents
• Any type — set attaches metadata, such as priority, to any action above

Technical constraints

Shopify Functions run inside a WASM sandbox with hard ceilings that most teams discover in production, usually the hard way. We design rules around these from day one — they're the reason a Scripts-era rule or a naive port can fail silently once it's a Function:

• 11M instruction limit — a Function that loops over every line item on a genuinely large cart can exceed this and fail. Rules that scan carts need to be written to bail out early.
• 128kB function input cap — the entire checkout context (cart, customer, shipping, metafields) has to fit in this budget. Large carts with many line items can hit it.
• Metafields over 10,000 bytes return null in function input — a metafield-based condition on an oversized metafield doesn't error, it silently evaluates as absent. This is the single most common cause of a rule that "should have matched" and didn't.

Pattern: B2B net terms

Net 30 for approved wholesale accounts only — the exact rule from the quick start above, in context. The pattern generalizes to any company-account gating: tiered pricing, PO-only checkout, or hiding retail payment methods entirely for wholesale accounts.

Pattern: freight & shipping

Force freight for oversized items instead of leaving Express Shipping visible for a cart it can't actually fulfill:

Pattern: order validation

Block checkout below a wholesale minimum, with a message explaining why — rather than a silent decline:

Pattern: conditional discounts

A loyalty discount scoped to repeat customers buying a second unit from one collection — the kind of condition a flat percentage-off app can't express:

Simulating rules

Every rule set runs against any checkout context — customer type, region, cart total — with a full execution trace showing which rules matched and why, so nothing ships unsimulated. See it working in the interactive preview on the homepage.

Templates BUILDING

Common patterns — wholesale terms, MOQ, freight, COD control, VIP handling — will ship as ready-made templates you adjust instead of writing rules from scratch. Until the library ships, our engineers already have most of these built from prior rule work — mention what you need when you request a custom rule.

Import / export BUILDING

Configurations will export as portable JSON — keep them in version control, clone them to development stores, or import them straight into the next client's store. Today, every custom rule and migration we deliver already ships with that same exported JSON config, built by hand.

Get it built

Everything on this page describes the language — not a tool you can log into yet. If you need one of these rules, or a chain more complex than the examples above, live on your store now: our engineers build it, the same way they build everything documented here.