Merging Tier & Wholesale Pricing UI (with old Shopify Functions)

Functions
1

Hi Community,

In our Wholesale B2B app we’ve built two main pricing features: Tier Pricing and Wholesale Pricing. Right now, here’s how things are set up:

Tier Pricing

  • Tier Pricing for Variant → saved in variant metadata
  • Tier Pricing for Product → saved in product metadata

Wholesale Pricing

  • Offers for Product → saved in shop metadata
  • Offers for Collection → saved in shop metadata

Each of these features has its own Shopify Function, and in our app admin we also show separate create and listing pages for each one.

:backhand_index_pointing_right: What we want to change:
We’re planning to simplify the UI so merchants see fewer separate pages. Instead of two different create pages for Tier Pricing, there will just be one “Tier Pricing” page. Same for Wholesale Offers — one page to cover both Product and Collection offers.

But under the hood, we’ll still save the data in the same separate metadata locations (to avoid complicated data migration for thousands of stores already using this).

Here are my main questions to the community:

  1. UI vs Metadata

    • Has anyone else built a single dashboard interface but continued saving data in different metadata fields behind the scenes?
    • Any issues with syncing, performance, or confusing merchants when reporting data later?

  2. Shopify Functions Limitations

    • We currently use separate Shopify Functions because of some limits (like instruction count and input size).
    • Example: if we tried combining too much logic into one function, it sometimes hit the instruction limit.
    • When using the new discount functions, do these limits get better? Or do we still need to split into multiple functions?

  3. Migration Timing

    • Should we first migrate to the new discount functions before merging the UI, so that we don’t build something we’ll need to rework later?
    • Or is it safe to unify the UI now and worry about migrating to the new discount API afterwards?

  4. Real-World Challenges

    • For those who already migrated to the new discount functions, did you face any surprises? (e.g. performance issues, changes to how input data is structured, or limitations we might not expect?)

We’re trying to make things easier for merchants (with less clutter in the admin UI) but still need to keep technical constraints in mind. Any stories, lessons learned, or best practices from this community would be super helpful.

Thanks a lot!

2

Hey @Shrutika_Lokhande :waving_hand: You can definitely unify your app’s UI while continuing to store data in separate metafields. Lots of apps do this successfully as long as you define a clear model for how you’re using metafield data (for example, variant tier over product tier over product offer over collection offer, etc) and apply it consistently in both the UI and your Functions.

The newer Discount Functions don’t remove core WASM limits (more info here), so the best practice is to keep the run target as efficient as possible and move any heavy implementations and large rule sets to a fetch target.

If your current functions read shop-level metafields directly in run, I’d recommend migrating that read path to fetch or discount.metafield first so you don’t have to rework twice.

I’d say that It’s safe to unify the UI now if you keep a stable service layer behind it that can later switch to Discount Functions, but I’d still prototype the Discount API early to validate instruction, input, and operation sizes. One thing I’d also note is that, as always just make sure your UI isn’t trying to completely replicate native Shopify functionality (from your description it doesn’t sound like it is, but I wanted to mention this for clarity as well)

Hope this helps a little bit from a Shopify perspective on things.