Scheduled-sends drawer opens properly from Analytics
The scheduled-sends drawer failed to render correctly when opened from the Analytics screen, even though it worked elsewhere. It now opens and displays properly from Analytics too.
The scheduled-sends drawer in Analytics now opens the way it should. It used to fail to display correctly when triggered from that particular screen, even though it worked fine from other parts of the product.
What changed
Opening the scheduled-sends drawer, the panel that shows you which emails are queued to go out and when, had a display problem specifically when triggered from the Analytics view. The drawer itself worked correctly elsewhere in the product; the issue was isolated to how it rendered when opened from Analytics, where it wasn't laying out or displaying properly. That made the Analytics screen an unreliable place to check your scheduled sends, even though checking sends from Analytics, right after reviewing your campaign's performance, is a natural place to want that information.
That's fixed. The drawer now opens correctly regardless of which screen you open it from, including Analytics, and displays your scheduled sends the same way it does everywhere else in the product.
How to use it
From Analytics, open the scheduled-sends drawer the way you normally would when you want to check what's queued to go out. It now displays correctly, showing your scheduled sends with the same detail and layout you'd see if you opened it from elsewhere in the product.
If you were previously avoiding checking scheduled sends from Analytics because of this issue, there's no longer a reason to; it behaves the same way from that screen as from any other. If you still see a display problem when opening the drawer, note exactly which screen and action triggered it, since that detail helps narrow down whether it's a new issue or a variant of the one already fixed.
Why it matters
A feature that works inconsistently depending on which screen you open it from is a small thing until it happens to be the screen you actually use most. If Analytics is where you naturally go to check on a campaign's performance, it's also a natural place to want to glance at what's still queued to send, and a drawer that doesn't render properly there breaks that workflow even though the same feature works fine one click away in a different part of the product. Inconsistencies like that erode trust in a specific feature in a way that's disproportionate to how minor the underlying bug actually is, since you start to wonder where else it might not work reliably.
Fixing it means you can rely on the scheduled-sends drawer the same way from Analytics as from anywhere else in the product, without needing to remember a workaround or double-check information you already trusted elsewhere.
The underlying cause was specific to how the drawer was mounted within the Analytics layout rather than anything wrong with the drawer's own logic or the scheduled-sends data it shows. That's part of why it only affected Analytics: the drawer component itself was correct, and every other screen that opens it does so in a context where the display issue didn't occur.
One screen for your whole check-in
There's no separate action needed beyond opening the drawer as usual. If your normal workflow is to review a campaign's performance in Analytics and then check what's still scheduled to go out, you can now do both from that same screen without switching over to a different view just to get a reliable look at scheduled sends.
If you manage multiple campaigns and use Analytics as your main check-in screen, it's worth confirming the drawer opens cleanly there now, particularly if you'd previously built a habit of navigating elsewhere specifically to check scheduled sends. That workaround shouldn't be necessary anymore.
Nothing about what the drawer shows has changed, only where it can be reliably opened from. The information in it, which sends are queued, for which contacts, at what time, is the same whether you get to it from Analytics or from a campaign's own view. This fix is entirely about making that access point in Analytics behave the way the same drawer already behaved everywhere else.
Why small fixes like this matter
Small display bugs tied to one specific screen are easy to deprioritize individually, but they add up to a product that feels less trustworthy in aggregate, especially when the screen in question is one you use often. Analytics is where you're already looking to understand how a campaign is performing; being able to check what's still queued from that same view, without a rendering problem getting in the way, keeps that whole check-in in one place instead of splitting it across screens for no real reason.
It's a small fix on its own, but it's the kind of detail that adds up. A product you check daily earns trust through consistency in exactly these moments, a drawer that opens the same way no matter where you open it from, rather than through any single large feature.
If you'd previously reported this behavior or noticed it yourself and worked around it by checking scheduled sends from a campaign's own view instead, that workaround is no longer necessary. Either path now shows you the same information, reliably, so use whichever screen fits naturally into how you already review your campaigns. This kind of small consistency fix is exactly the sort of thing worth reporting when you notice it, since a display issue tied to one specific screen can be easy to miss unless someone happens to hit it and mentions it. If you're the kind of user who checks scheduled sends often as part of your daily routine, this is a small quality-of-life improvement that removes one more reason to hesitate before clicking into the drawer from wherever you happen to be. It's a narrow fix, scoped to one screen and one interaction, and that narrowness is by design: the goal was to correct exactly the case that broke, without touching the drawer's behavior anywhere else it was already working correctly, so nothing about how the drawer looks or behaves from any other screen changes as a result.
Availability
This applies to the Analytics view.