How background tasks work on your store

In short. Background tasks handle work that is too large to complete in a single click — bulk exports, newsletter sends, image regeneration, catalog imports. SGEN starts the task, shows a status pill and a progress count, and emails you when it finishes. You do not need to stay on the page; if a task shows Failed, re-trigger it from the same originating button.

How to how background tasks work on your store

When you click a button in your SGEN admin and the screen says "we're working on it — feel free to keep using the dashboard", that's a background task. Background tasks let your store keep doing the heavy lifting (sending newsletters, exporting catalogs, regenerating images) while you carry on with the rest of your day. This page explains what background tasks are, how to tell when one is running, what to do when one looks stuck, and how to read the progress signals your store gives you.

Imagine the admin at Your Store clicks "Export all orders" on a Friday afternoon. The store has 8,500 orders this quarter. If the export ran instantly, the admin would be staring at a frozen page for ten minutes. Instead, SGEN starts the work in the background and tells the admin: "Your export is running �� we'll let you know when it's ready." The admin can keep editing products, replying to customers, or even close the tab — when they come back, the file is waiting in their downloads.

That's a background task. Across your store, dozens of features use them: bulk imports, mass emails, image regeneration after a theme change, large catalog reshuffles. You don't trigger background tasks directly — they just happen automatically when the work is too big to finish during a single click.

What is this for?

This page is for store admins who want to understand the status signals that appear during long-running operations and what to do when those signals look wrong.

Background tasks are how SGEN handles work that takes more than a few seconds. The admin clicks a button, the dashboard shows a "running" indicator, and the actual work happens behind the scenes. The admin can leave the page; when they come back, the result is waiting.

You don't need to manage background tasks. The store creates them automatically when you trigger an action that's too big to finish during the click — for example exporting your full order history, sending a newsletter to 12,000 customers, or regenerating thumbnails after a theme switch.

Good use cases

You'll see background-task indicators most often in these workflows:

• Bulk product import — uploading a spreadsheet with thousands of products. The store shows a progress count and emails you when done.
• Customer newsletter — sending a campaign to your full list. You'll see "Sending 247 of 12,403" while it runs.
• Order export — exporting orders for accounting. Same shape: a progress counter, then a download link in your dashboard.
• Image regeneration — after switching themes, the store rebuilds product thumbnails in your new theme's sizes. You'll see "Regenerating images" on the theme settings page.
• Storewide reprice — applying a percentage discount to thousands of products at once.
• Catalog reshuffle — re-ordering or re-categorizing large parts of your catalog.

The pill row below is what you'll see in the originating feature's admin panel — at a glance you can tell which jobs need your attention:

What NOT to use this for

• Don't expect a global "All background jobs" page in your admin. Each long-running feature shows its own progress; there's no master list.
• Don't try to manually re-start a stuck job by refreshing the URL — always re-trigger from the original button (e.g. click "Export all orders" again, not the progress page).
• Don't close your browser the very second after clicking a button that says "starting in background". Wait until you see the "running" confirmation, otherwise the dispatch may not complete.
• Don't treat "Cancelled" as the same as "Failed" — cancelled means you stopped it on purpose; failed means something went wrong and you should re-trigger.

How this connects to other features

• Bulk Export — the most common originator of background tasks. The progress UI you see in Bulk Export is reading job status under the hood. See the Bulk Export documentation for export-specific options.
• Mass Mailer / Newsletter campaigns — when you send a campaign, a background task fans out the actual email sends. The Mailer Log surfaces the same status pills described here.
• Theme switch — switching to a new theme dispatches a background image-regeneration task. Until it completes, some product images may render at the old theme's sizes.
• Bulk product import — uploading a CSV starts a background import that processes rows in batches and reports progress.

Before you start

You don't actively start background tasks — they happen automatically. But before triggering an action that you know will run in the background, do these things:

• Use a real device, not a slow phone connection. The dispatch click needs to complete; a flaky network can cause the task to never start.
• Check that you're logged in as a full admin. Some backgrounded actions require admin-tier access; staff or contributor roles may see "Permission denied" instead.
• Leave at least one browser tab open on the originating page until you see the "running" confirmation. Closing too early can interrupt the dispatch.
• Have your email accessible. Many backgrounded actions email you when complete (the export download link, the import success summary, the campaign send report).

Where to go

Background-task status is surfaced inside the originating feature's admin page. There is no central jobs panel.

• For exports: Dashboard → Tools → Bulk Export
• For mailers: Dashboard → Marketing → Newsletters → Send log
• For imports: Dashboard → Products → Import → History
• For theme regeneration: Dashboard → Appearance → Themes → (after activating)

In each location you'll see a banner or panel that lists the running task with its progress. Below is what the Bulk Export list looks like when a recent export has finished and a new one is mid-run:

Steps — Watch a long-running task to completion

1. Trigger the action and confirm the "running" banner

After clicking the button that starts the work, wait for the page to update. You should see one of:

• A progress panel with item counts ("Processing 0 of 8,500")
• A green "Job started — we'll email you when it's done" banner
• A status pill that reads "Running" or "Queued"

If you don't see any of those within ten seconds, the dispatch may not have fired. Try the click once more, then check your email — sometimes the work completes faster than expected and the email arrives before the page has caught up.

2. Leave the page or stay — both are fine

Once you see the "running" confirmation, you can:

• Stay on the progress page and watch the counter advance
• Navigate to other admin pages and come back later
• Close the tab entirely

The work continues in the background regardless. Most tasks email you when they complete, so even if you forget to come back, you'll get a notification.

3. Check status periodically (only if you're impatient)

If you want to know how far along a task is, navigate back to the originating feature page. The progress panel will show a current count. The "Last update" timestamp tells you when the task last reported in — if that timestamp is older than two minutes on a task that should be active, something has gone wrong (see "What to do if it does not work").

4. Confirm the result when done

Once the task finishes, the originating page surfaces a success message and (where applicable) a link to the output. The success banner looks like this:

5. Re-trigger if anything looks wrong

If the task ended with a "Failed" pill, the simplest recovery is to re-trigger from the same originating feature. Don't try to manually re-run by URL or by refreshing the progress page — always start fresh from the same button you clicked the first time.

What success looks like

A successful background task ends with three things in your admin:

1. The status pill on the originating feature flips from "Running" to "Completed" (green).
2. A success banner appears at the top of the originating page, summarizing what got done.
3. (Where applicable) An email arrives at the admin address with a download link or a summary of the work.

For a Bulk Export, that translates to a downloadable file appearing in Tools → Downloads plus an email with the same link. For a Newsletter send, that means the campaign moves to the "Sent" tab in your mailer log with the final delivery counts. For a theme switch, the regen banner disappears and product images render at the new theme's sizes on the public site.

This is what your customer sees on the public site after a successful theme-switch background task — fresh thumbnails at the new theme's sizes, no broken-image placeholders:

What to do if it does not work

If a background task isn't behaving as expected, run through this checklist before contacting support:

• Has the "Last update" timestamp moved in the last two minutes? If it has, the task is still running — be patient. Large exports can take ten minutes or more.
• Is the task showing "Queued" for more than 30 seconds? That can happen briefly when the dispatcher is busy, but if it persists, the dispatch may have misfired. Cancel from the originating page (if a Cancel button is shown) and re-trigger.
• Did you get an email about the task? Many backgrounded actions email you regardless of whether the page updates. Check your inbox before assuming the task failed.
• Does the status pill say "Failed"? Re-trigger from the same originating feature page. Failures are sometimes transient (a momentary network hiccup); a clean re-run usually succeeds.
• Is the task still running after a deploy / maintenance window? Tasks queued before a maintenance window may need to be re-triggered after the window ends.

If none of the above resolves it, contact support with three pieces of information:

• The originating page (e.g. "Bulk Export started Apr 29 around 9:14 AM")
• A description of what you were trying to do
• A screenshot of the status panel showing the pill and the "Last update" timestamp

Support can match those details against the store's internal records and tell you what happened.

Example 1: Your Store runs a quarterly orders export

The Your Store team runs a quarterly export of all orders for accounting. On Apr 29 at 9:14 AM the admin clicks Tools → Bulk Export → All orders Q1 2026 (CSV). The page shows a progress panel with "Processing 0 of 8,500". The admin closes the tab and goes back to answering customer emails.

At 9:32 AM the admin's email pings: "Your export is ready — download here." The admin clicks the link, downloads the CSV, and forwards it to the bookkeeping team. Total time: 18 minutes, of which the admin spent zero time staring at a progress bar.

This is the happy path. The status panel at 9:32 looked like the success banner shown above.

Example 2: A campaign send shows partial progress mid-run

The Your Store marketing team triggers a Tuesday newsletter to 12,403 subscribers. They click Marketing → Newsletters → Send "Spring sale". The mailer log immediately surfaces:

The team can leave this page open and refresh occasionally to watch progress, or come back at end of day to see final delivery counts. Both flows are supported.

Example 3: A failed import that recovers on re-trigger

The Your Store Wholesale admin uploads a 4,200-row product CSV. The progress counter starts moving, but at row 1,247 it stops. The "Last update" timestamp ages from "12 seconds ago" to "2 minutes ago" to "5 minutes ago" — clearly stuck.

The admin clicks Cancel on the import progress panel. The pill flips from "Running" to "Cancelled". The admin then clicks Import again with the same file. This time the import runs cleanly to row 4,200 and surfaces a success banner.

In support's notes the original failure was a transient queue hiccup during a deploy window. The re-trigger after the window ended worked because a fresh dispatch was generated. Always re-trigger from the originating page when you see "Failed" or a stuck task — never try to "force" the same dispatch to retry by hand.

Example 4: Your Store Wine reorders 1,800 SKUs across categories

The Your Store Wine team is overhauling its category structure for spring. They use Products → Bulk reorganize to move 1,800 SKUs across 14 categories. That click triggers a background reorganize task — far too much work to finish during a single page request.

The admin can navigate away and come back. When the panel flips to a green "Completed" pill and the success banner appears, every product is in its new home. The marketing team can then publish the spring landing page knowing the catalog matches.

Reading the progress signals

When you're watching a background task, three signals tell you what's happening:

1. The status pill — top-right of the progress panel. Will show one of: Queued (light grey), Running (yellow), Completed (green), Failed (red), Cancelled (grey).
2. The progress count — for tasks that process individual items (orders, products, emails), you'll see "Processing X of Y". The denominator is fixed once the task starts; the numerator climbs.
3. The "Last update" timestamp — every active task reports a heartbeat every few seconds. If this stops moving for more than two minutes on a task that should be active, the task has likely stalled.

A healthy running task has all three signals moving in sync: the pill is yellow, the numerator is climbing, the timestamp is recent. If any of those breaks, treat it as a problem and re-trigger.

Tips for working with background tasks

• Trigger large operations at the end of your day. Exports and imports finish while you sleep — you come back to results, not a progress bar.
• Always wait for the "running" confirmation before closing the tab. The dispatch click and the actual task start are two separate moments. Closing immediately after clicking can orphan the dispatch.
• Use email as your primary completion signal, not the progress page. Most backgrounded actions email you when done. You do not have to watch the progress panel — checking your inbox is enough.
• Re-trigger from the originating page, not the progress URL. Bookmarking or refreshing the progress URL does not restart a failed job; it just shows you the stale failed state. Go back to the button that started the work and click it again.
• If a task fails twice in a row, contact support before a third attempt. Two consecutive failures usually point to a data or configuration issue, not a transient network hiccup. A third attempt without investigation is unlikely to succeed.
• Coordinate with your team on large catalog operations. If two admins trigger a bulk reorganize at the same time, the tasks may conflict. Agree on a window before triggering anything that touches thousands of records.

Scope

This reference covers background tasks — operations dispatched asynchronously when an action is too time-consuming to run in a single page request. It applies to all SGEN plans. Common triggers include bulk exports, newsletter sends, image regeneration, and large catalog imports. It does not cover:

• Cron scheduling or server-level task runners — those are infrastructure concerns, not admin-configurable.
• Real-time actions (saving a single page, editing a product) — those are synchronous and complete before you navigate away.
• Email delivery queuing — that runs on the email transport layer, not the SGEN background task system.

Examples

Example 1: Bulk order export running in background. You trigger a full order export for Your Store — all 847 orders for the year. The progress page shows "Running". Close the tab and check your inbox 10 minutes later. The download link is waiting in the email. Click it, download the CSV, and open it in your spreadsheet tool.

Example 2: Newsletter send dispatched overnight. You schedule a Your Store newsletter for 09:00. At 09:00, the background task queues 1,200 emails. The progress page shows a count incrementing. Leave the page and check back at 09:45 — 1,198 delivered, 2 bounced (shown in the bounce report).

Example 3: Image regeneration after theme switch. You activate a new theme on Your Store that uses different image crop dimensions. SGEN queues a background image regeneration task. The public site serves the old crops until the task finishes — about 4 minutes for 312 images. Confirm completion on the progress page before announcing the new design.

Fields

Next steps

• See the Bulk Export customer doc for the originating feature most associated with background tasks.
• See the Newsletter campaigns doc for how mailer-related background tasks are surfaced.
• See the Theme switching doc for what to expect when activating a new theme triggers image regeneration.
• See the Bulk product import doc for how large CSV imports surface progress.
• See the Tools → Downloads doc for where background-generated files end up.

One more thing — your store keeps working while tasks run

The single most useful idea to take away from this page: background tasks do not pause your store. Customers keep browsing, buying, and signing up while a Bulk Export or a Newsletter Send is running. The admin side and the customer side are independent. Even during a long catalog reshuffle, the public site keeps rendering — the only thing customers might notice is that recently-moved products briefly show in their old categories until the background task finishes the move. Plan large operations during quieter hours if you want to minimize that brief inconsistency, but you do not have to "pause the store" to run them.