notifications

Rolling Notifications for Snapshot Pushes: How to Monitor and Manage Large-Scale Updates in the Platform

Charles Higgins

Charles Higgins

— 9 min read
Featured
Featured

In the original tutorial video by our channel's creator, we walked through a simple but powerful improvement to how the platform notifies you when you push snapshot updates to multiple client accounts. In this article, we expand on that content, explain what snapshots are, why rolling notifications matter, and show practical, step-by-step ways to use this change to save time, reduce noise, and keep large teams focused on what matters.

Table of Contents

Why this change matters

If you maintain templates, funnels, automations, or full site systems for multiple clients, you already know that pushing updates can create a lot of noise. Each account receiving an update used to generate its own notification in the activity center, which could leave us sifting through dozens — sometimes hundreds — of messages just to confirm that a push succeeded.

We designed rolling notifications to fix that exact pain point. With this update, when we push a snapshot update to many client accounts at once, the platform groups progress into milestone notifications so we can get a quick, meaningful overview without drowning in messages. It’s automated, zero-setup, and currently enabled for any push to more than ten locations.

What is a snapshot?

We use the term “snapshot” to describe a reusable system we create and distribute to client accounts. A snapshot can include:

  • Workflows and automations
  • Funnels and pages
  • Site templates and settings
  • Preconfigured integrations and tags

Snapshots let us package a full operational system once and install it into a new or existing account in a single click. They’re ideal for agencies, consultants, and any business that repeatedly sets up similar services for different clients.

How notifications worked before

Previously, pushing a snapshot update to multiple subaccounts generated one notification per account. For small batches that might be okay, but when we pushed updates to dozens or hundreds of client accounts, the notification area quickly became overwhelmed. We had to manually inspect each notification to see failures, and that created friction:

  • Time wasted scanning a long list of nearly identical messages
  • Missed failures hidden among success notifications
  • Extra clicks to reach push history and details

What rolling notifications change

Rolling notifications group progress into milestones and only appear in stages when we push updates to more than ten locations. Instead of receiving one notification per account, we’ll see grouped updates at four key points:

  • After 10% of locations have processed the update
  • After 30% of locations have processed the update
  • After 70% of locations have processed the update
  • After 100% of locations have processed the update

Each milestone notification shows us how many locations have completed successfully and how many have failed so far. This gives immediate visibility into overall progress without filling the notification area with dozens or hundreds of messages.

When grouping is applied

Grouping applies only when we push updates to more than ten locations. If we push to ten locations or fewer, the behavior remains the same as before: individual notifications appear, one per location. This design balances simplicity for small batches with improved manageability for larger ones.

What a grouped push looks like — a concrete example

Here’s a realistic example to visualize the new system. Suppose we push a snapshot update to 25 client locations. The notifications would appear like this:

  • 10% milestone: 3 out of 25 processed (3 completed, 0 failed)
  • 30% milestone: 8 out of 25 processed (8 completed, 0 failed)
  • 70% milestone: 18 out of 25 processed (18 completed, 0 failed)
  • 100% milestone: 25 out of 25 processed (25 completed, 0 failed)

Each milestone provides a clear checkpoint so we know where the update stands. If no failures appear, we get clean confirmation that the update is rolling out as planned. If failures do appear, those are highlighted separately (see the “failures” section below).

How failures are handled

When a specific subaccount fails during a snapshot push, the platform still makes it easy to act fast. Each failed snapshot generates its own individual notification rather than being grouped. That distinction is deliberate: we want failures to be highly visible so they don’t get lost in an aggregated message.

Failure notifications include:

  • The exact name of the location/account that failed
  • A clear status (failed) so it stands out
  • A “view details” action that takes us straight to the push history filtered for that snapshot

This means we can immediately jump to the account that needs attention, see the error details, and re-push or troubleshoot without extra navigation or guesswork.

Using the “View Details” action

One of the biggest time-savers with this update is the “view details” button. It appears on each milestone notification and on each individual failure notification. Clicking it opens the snapshot push history page already pre-filtered for the specific push we were monitoring.

That saves us several clicks and lets us quickly:

  • See the timeline and status of the push
  • Identify which account failed and why
  • Rerun the push for that single account if necessary

Overall, “view details” reduces the friction between spotting an issue and resolving it.

Best practices for pushing snapshots at scale

Rolling notifications make life easier, but we still recommend a set of best practices to reduce errors and protect client experience when updating many accounts at once:

1. Test on a small set first

Always validate your changes in one or two sandbox or staging accounts before pushing to production accounts. If the snapshot affects critical automations or customer-facing pages, testing catches errors early.

2. Start with a pilot batch

Rather than pushing to all accounts at once, consider rolling updates in batches — for example, 10–20 accounts at a time — especially when changes are big. This gives you human eyes on the system and a chance to stop or adjust before a full rollout.

3. Schedule updates for low-traffic times

Plan pushes during off-peak hours when changes have the least impact on customers. That reduces the risk of disrupting live campaigns and handling spikes.

4. Communicate with affected clients

When updates include user-facing changes, communicate what’s changing, why, and how to revert if needed. Clear communication reduces surprise and support tickets.

5. Keep a rollback plan

Even with careful testing, unexpected issues can happen. Keep a plan to restore the prior state or manually correct accounts if needed. Documenting rollback steps saves panic time in a real incident.

6. Monitor failures immediately

Thanks to ungrouped failure notifications, we’ll spot problems quickly. Assign a team member to monitor the grouped milestone and individual failure updates during a big push to ensure swift responses.

Common causes of snapshot push failures and how to fix them

When a push fails for a specific account, the root causes often fall into a few repeatable categories. Here are common causes and practical fixes we can use without calling support in most cases:

  • Permission or account state issuesSome accounts may be restricted, suspended, or missing owner-level permissions required to accept certain snapshot elements. Check the account’s admin permissions and account status before re-pushing.
  • Conflicting existing assetsIf an account already has an asset (like a funnel or workflow) with the same identifier, the snapshot may fail. Resolve conflicts by renaming or removing the existing asset, or choose to skip conflicting elements during a redo.
  • Missing integrations or external dependenciesSnapshots can reference external resources (tracking codes, third-party integrations, or custom domains). Verify those resources exist or update the snapshot to be more flexible.
  • Network or transient errorsTemporary network issues can cause failures. Often, simply re-pushing to the failed account resolves the issue after a short wait.
  • Versioning or structural changesLarge changes to how a system is structured (for example, replacing a major workflow with a new set of automations) can fail if the snapshot assumes a particular prior state. In those cases, staging and migration scripts can help.

How we handle single failures quickly

When a failure appears, our usual process is:

  1. Click the failure notification’s view details button to go straight to the push history for that snapshot.
  2. Read the specific error message and note the account name included in the notification.
  3. Try re-pushing the snapshot to that single account after verifying permissions and removing any obvious conflicts.
  4. If the failure persists, collect a screenshot of the error and the account details and escalate with precise notes for the support team or internal engineer.

This approach keeps resolution simple: re-run where safe, escalate with evidence where necessary, and avoid wasting time hunting through unrelated notifications.

How to interpret milestone percentages

It helps to understand exactly how the milestone thresholds translate into numbers for your batch sizes. Here are a few quick examples so we can instantly know what counts as 10%, 30%, and 70%:

  • For 11 locations: 10% = 2 locations, 30% = 4 locations, 70% = 8 locations
  • For 25 locations: 10% = 3 locations, 30% = 8 locations, 70% = 18 locations
  • For 50 locations: 10% = 5 locations, 30% = 15 locations, 70% = 35 locations

Numbers round to the nearest whole location where needed. This means you’ll see milestones trigger quickly for smaller batches and slightly later for larger ones, but always at meaningful progress checkpoints.

Benefits we see from rolling notifications

We focused this change on practical time savings and better clarity. The benefits include:

  • Reduced notification clutter — fewer duplicate messages for large pushes
  • Faster status checks — milestone updates give clear checkpoints without extra clicks
  • Immediate visibility of failures — failed pushes are still highlighted individually
  • Streamlined troubleshooting — “view details” opens pre-filtered logs so we can act immediately
  • Lower cognitive load for teams — fewer notifications to scan means less context switching

For growing teams managing dozens or hundreds of client systems, these benefits compound into real time savings and fewer support interruptions.

When grouping is not helpful

Most of the time rolling notifications improve our workflow, but there are scenarios where we might prefer the old behavior:

  • When pushing to a very small number of accounts (ten or fewer), we already get individual notifications so grouping does not apply.
  • When we deliberately want a notification for every single account for audit or compliance reasons. In the current implementation, the grouping is automatic and cannot be turned off, so if we need per-account notifications for every push, we would need to use smaller batches.

If per-account messages are essential, our workaround is to split a large push into multiple pushes of ten or fewer accounts each. That will produce individual notifications for those batches while still letting us control rollout size.

Practical workflow for a typical update

Here’s a practical end-to-end workflow we recommend based on the new notifications model. It’s designed to be simple and safe for small teams handling many client accounts.

  1. Create and test the snapshot in a staging account.
  2. Run a pilot push to 3–5 accounts to validate behavior in real client environments.
  3. Schedule a larger batch, considering off-peak times and client schedules.
  4. Start the push. Monitor the grouped milestones and watch for any individual failure notifications.
  5. Click “view details” on any milestone or failure to get pre-filtered context and logs.
  6. Re-push or fix accounts with failures, following the troubleshooting checklist.
  7. Complete the final full rollout once the pilot and larger batch succeed.

Following these steps keeps our rollout predictable, reduces interruptions, and takes full advantage of the new, cleaner notification experience.

Real-world testimonial snapshots

“We recently pushed a system update to 120 client sites. The milestone notifications gave us quick checkpoints and made it obvious where a handful of failures occurred. We resolved those in minutes instead of combing through hundreds of messages.”
“Before this change, our notification area was cluttered after each mass update. Now we get meaningful progress updates and a direct link to the push history — huge time saver for our support team.”

FAQ

Q: When do grouped notifications appear?

A: Grouped notifications appear automatically when we push a snapshot update to more than ten locations. If we push to ten or fewer, we get individual notifications per account as before.

Q: Can we turn the grouped notifications off?

A: No. Grouping is applied automatically for large pushes and cannot be turned off. If you need individual notifications, push to batches of ten or fewer locations.

Q: How many grouped notifications will we receive?

A: For a large push, we receive four grouped milestone notifications — after 10%, 30%, 70%, and 100% of locations have completed the push.

Q: Are failures grouped too?

A: No. Failures generate individual notifications per failed account so they remain highly visible and actionable.

Q: What information is included in the failure notification?

A: Each failure notification includes the name of the location that failed and a “view details” action that opens the push history filtered for that snapshot and account.

Q: How do we troubleshoot a failed push?

A: Click “view details” to see the filtered push history, review the error message, verify account permissions and resource availability, and re-push. Common fixes include adjusting permissions, resolving conflicts, and re-running after a short wait for transient network errors.

Q: Does grouping affect audit trails?

A: No. The push history still records the status of every account individually. Grouped notifications only change how progress is summarized in the notification area.

Q: What are best practices for large rollouts?

A: We recommend testing in staging, piloting with a small batch, scheduling during low-traffic windows, communicating changes to affected clients, and keeping a rollback plan handy.

Conclusion — what this change unlocks for us

Rolling notifications for snapshot pushes are a small but impactful usability improvement. They reduce noise, surface meaningful progress, and make failures easier to spot and fix. For teams that manage many client accounts, that translates into less manual monitoring, fewer interruptions, and a more efficient update workflow.

This feature is automatic and requires no setup. We can take advantage of it right away while following the simple best practices outlined here: test early, stage carefully, push in controlled batches, and use the built-in “view details” action to resolve issues quickly.

Our goal is always to help teams spend less time on repetitive admin tasks and more time on strategic work that grows the business. Rolling notifications bring us one step closer to that ideal by keeping our notification area focused, our updates visible, and our teams moving forward without needless friction.

Read more