I’ve been researching how Shopify merchants currently handle workflows like:
• Upsells and product recommendations
• Discount campaigns
• Preorder setup for out-of-stock products
• Back-in-stock product visibility
• Store banners and promotional updates
In many stores, these still seem to require multiple apps and a lot of manual configuration.
Another thing I’ve noticed is that merchants often spend significant time checking reports manually to understand:
• which pages customers visit most
• where users drop off
• which products get attention but don’t convert
• which offers improve AOV or conversions
Curious how other merchants here are currently handling these operational workflows.
Are most people using multiple specialized apps together, custom workflows, or more centralized operational tools?
Recently I’ve also been exploring AI-assisted operational workflows where merchants can describe what they want in plain English, review the generated workflow, and approve it before publishing live changes.
Would love to hear how others approach this today. Happy to share more about what I’ve been exploring as well if useful for the discussion.
A lot of these workflows split into two categories.
For storefront rendering, such as real-time upsells, recommendations, and banners, you usually still need a theme/app layer that controls what the customer sees.
For the operational side, such as scheduling campaigns, updating product tags/metafields, publishing or hiding products, handling back-in-stock actions, syncing campaign data from Sheets/Airtable, and sending internal review tasks, a workflow approach can work well.
The reporting side depends on the data source. Shopify order/product data is straightforward to automate around, but page visits and drop-off analysis usually need analytics data from another source before a workflow can act on it.
So in practice I’d separate it into:
- customer-facing UI/personalization
- backend operational automation
- analytics/reporting inputs
Trying to solve all three with one generic app can get messy. The cleaner setup is often a storefront tool for presentation plus workflows for the operational logic around it.
The annoying bit is when the storefront looks updated but one rule is still hanging around. A preorder banner might still be driven by an old product tag even after the variant is back in stock or the discount campaign is already over.
If you’re looking for a simple preorder setup, I’m Emma, co-founder of REZ Preorder.
- You just select the products you want in a campaign
- REZ auto shows the Preorder button when they’re out of stock, then switches back to Add to Cart once they’re back in stock.
No manual changes needed.
You can also easily set an estimated shipping date for each product.
We have a generous free plan if you’d like to try it, and I’d be happy to help you get everything set up!
A few of these are handled natively now, worth checking before adding apps. Shopify Flow covers a good chunk of the automation side (restock triggers, discount scheduling), and native metaobjects can handle simple banners without a separate app. Preorder setup is usually the one that still needs a dedicated app since it touches inventory logic Shopify doesn’t expose out of the box.
For back-in-stock visibility specifically, wishlist tools like Growave handle it by notifying customers automatically when a saved item is restocked, so it’s one less manual check on your end. Doesn’t solve the other items on your list, but it’s a decent way to cut one recurring task.
two things that dont usually get said in these threads.
first, the “too many apps” pain is less about the count and more about how many of them ship an app embed. app embeds live in theme.liquid and load on every page of the store once theyre toggled on, whether the feature is used on that page or not. app blocks, the ones you drop into a section, only load where you actually placed them. so five apps that all use blocks can be lighter than two that both use embeds. theme editor, app embeds, is worth going through once with that in mind.
second, on “which offers improve AOV”: you cant verify any app dashboard from your side unless the line the offer added is marked. if the app writes a line item property when it adds the product (something like properties[_added_by]), that property lands on the order, shows up in the order admin and in your order export, and you can split orders with and without it yourself. no marker means youre taking the vendors number on trust with no way to reconcile it against your own data. so its a fair question to ask any upsell vendor straight out: does the added line carry a property i can see in my own order export? disclosure, i build a cart drawer app (Verve - drawer, upsells, bundles and announcements in one, which covers a few of the boxes on your list), and we dont stamp that property yet either, so im not pointing at anyone here.
on preorder the earlier answers are right that its the one item that genuinely needs its own app, because it has to flip the per variant inventory policy, not just render something different.
What helped me was to stop counting apps and think in layers, roughly what YOD_Solutions said above. Storefront rendering is one job: popups, badges, banners, cart stuff. Automation is another: discount rules, preorder logic, back-in-stock triggers. Reporting is a third. A generic app that swears it does all three usually nails one and fumbles the rest.
wilhelmpa’s point is the real lever. App embeds load on every page whether the widget shows or not. App blocks only load in the section where you drop them. So two block-based apps can cost you less than one heavy app injecting a script everywhere. Fewer apps and faster storefront aren’t the same thing. Blocks are how you get both.
The sneaky source of bloat is one app per widget. A popup app. A badge app. A banner app. A preorder app. They overlap hard, and merging the ones that live in the same layer is where I’ve actually seen people cut the count.
Disclosure: I build one of those, PopBoost. It rolls the storefront-conversion widgets into a single app, so social proof, countdown, free shipping bar, preorder and back-in-stock badges, and the announcement bar are one block instead of five installs. It does nothing for your automation or reporting layers. But for the widget pile specifically, that’s one way to go from several apps down to one.
Last thing. Someone mentioned the storefront looking updated while an old rule is still live. That one’s real, and it bites regardless of which apps you run. Toggle the widget off and actually load the page. Don’t trust the admin telling you it’s off.
The drift @order_ops_guy describes is what I’d optimise for, more than app count.
An app that’s “one less app” but keeps its own copy of state is worse than two
apps that both read from source.
Concretely, for anything the storefront displays about stock or price, the
question worth asking a vendor is: where does this number come from at render
time? If the answer is a setting, a tag, or a synced field, it will drift the
first time someone edits inventory outside the app. If it reads the live product
object, it can’t.
Same test for banners. A preorder banner driven by a tag needs a human to
remember to remove the tag. One driven by variant availability doesn’t.
A fair amount of this doesn’t need an app at all, incidentally. Theme blocks
reading inventory_quantity and compare_at_price cover more than people expect,
and they can’t go stale because they have nothing stored to go stale.
Where I’m not neutral: I build a free theme app extension (Flowpack) for badges,
low-stock, sold-out states and a shipping bar, and it works that way on purpose,
nothing stored. But it only touches the display layer. It does nothing for
upsells, recommendations, preorder flows or campaign scheduling, which is most of
what you listed, so it’s a partial answer at best.