Skip to main content

​
Navigate the dashboard Home page

The Home page (/home) is the first surface that renders after you sign in — a composite of the daily-triage widgets, so a new seat can answer “is my account healthy right now?” in one screen before it opens any menu. This page orients you: what the sections are, which question each widget answers, where the Quick Actions take you, how branded domains are resolved after sign-in, and what to check when sections get stuck. For the widget-by-widget deep read — every tile, the API endpoint behind it, and the fetch-layer behavior — see Read the dashboard Home page.

​
1. What the Home page composes, and what each widget answers

Top to bottom, the page composes six sections. Each one answers a specific question for a first visit:
  1. Greeting strip — “how much went out in the last 24 hours, and how much of it was delivered.” A time-aware greeting with today’s date, a one-line activity summary (“N messages sent in the last 24 hours — X% delivered”), and quick-stat pills for the rolling-24-hour trend and the open inbox count. When the window is empty it says so explicitly instead of inventing a zero-percent rate, and when delivery receipts have not come back yet the ”% delivered” clause drops rather than claiming an unknown rate.
  2. Overview (bento metric tiles) — “is the headline number moving?” Hero KPI tiles (messages sent, delivery rate, spend, channel mix), each pairing its value with a trend sparkline. A 24h / 7d / 30d / 90d / Custom timeframe picker scopes the tiles — section 2.
  3. Channels (health cards) — “which channel, if any, needs attention first.” One card per connected channel (SMS, WhatsApp, email, voice, and any other enabled channel) with a roll-up impact banner when any cluster degrades. Section 5 decodes the three colors.
  4. Trial, balance, and KYC banners — “what account-level state blocks or nudges me today.” The trial-number promotion card (until you own a number), the balance widget (billing roles only), and the KYC reminder banner (until verification is approved). An empty state hides itself rather than rendering a placeholder.
  5. Quick Actions — “what can I actually do next.” Role-filtered deep-link tiles — section 6 maps which tiles appear per role.
  6. Intelligence grid — “what changed that I did not already know about.” The below-the-fold cluster of Smart Insights (generated observation cards), Customer Health (predictive contact segments, click to open filtered contacts), and the billing-gated Spend Forecast card (30-day cadence plus a 7-day projection, shown to billing-seated roles only).
Every section below the greeting renders inside its own error boundary, so one failing cluster cannot take the page down with it. If any cluster cannot load, a single warning ribbon spans the full width at the top of the page naming the affected sections (for example, “Smart Insights, Spend Forecast”) with a Retry all button; healthy sections stay put the whole time. Never read the remaining numbers as complete while that ribbon is up — it disappears once every section is healthy again.

​
2. How the timeframe picker scopes the bento tiles

The picker above the bento grid (24h / 7d / 30d / 90d / Custom) re-reads the delivery and spend tiles over the selected window. The 24h preset is the default and matches every other 24-hour surface in the dashboard. Two behaviors keep a range switch from being destructive:
  • No mid-switch blink. Switching ranges keeps the previous values on screen while the new window loads — the tiles never flash empty or zero mid-switch.
  • Custom pins the window. Accepting a custom calendar range re-reads the tiles pinned to those exact dates rather than a rolling bucket.
The greeting strip sits above the picker and always reads the rolling 24 hours; only the bento tiles below it re-scope.

​
3. How a white-label domain resolves after sign-in

When your organization operates a branded (white-label) domain, sign-in lands on the primary product domain first, then checks in the browser whether your session’s organization has an active branded host. The resolution order:
  1. Session established on the primary domain. Sign-in completes there regardless of branding.
  2. One branded-host lookup. A single client check reads whether the session’s organization carries an active branded domain.
  3. Hand off, or stay put. If a branded domain exists, the page hands the established session to that branded origin; if none exists, you simply stay on the primary domain.
The check runs once per sign-in and never navigates you anywhere your session cannot reach. The practical effect: a subaccount member who signs in from the primary domain still ends up on their branded dashboard, and a session with no branded domain skips the hop entirely.

​
4. Diagnosing “stall on skeletons”

If the page holds on placeholder skeletons instead of settling, work through these three cases in order — each has a different remedy:
  1. The fetch is still in flight. The Home page’s widgets share one consolidated stats request, and channel health refreshes on a 30-second cadence. A slow API tick or a cold first payload keeps the skeleton up as the intended pending state. Remedy: wait a few seconds; if the top-of-page warning ribbon appears naming a failed section, use its Retry all (or that section’s own retry) to re-run the fetch. Healthy sections stay put while the failing one reloads.
  2. A permissions error (401 / 403) is gating the data. A tile that shows skeletons followed by the page-level warning ribbon — or an empty state that the widget self-hides — often traces to an expired session (401) or a role without read scope for that endpoint (403). Remedy: sign in again to refresh the session. If a 403 persists, ask an owner or admin to adjust your role — the ribbon’s named section tells you which read failed.
  3. Region misrouting. If your workspace is provisioned in a region other than the one your request lands on, the stats request can hang against the wrong origin and never resolve. Remedy: use the region your organization is provisioned on (from your organization’s entry in the account switcher); if you cannot resolve it locally, quote the page-level error panel’s error ID to support — the ID identifies the failing route.
Two non-issue stalls to recognize rather than troubleshoot:
  • Post-sign-up provisioning window. Immediately after signup, the page intentionally renders a “Setting up your workspace” panel with a live progress indicator over a skeleton bento grid. It polls setup progress in the background and resolves on its own within ~90 seconds; you do not need to keep this page open for it to finish. If setup crosses five minutes, the panel swaps to a retry button plus a support path instead of spinning forever — retry once, then contact support.
  • A whole-page error panel. If the page-level error panel replaces the dashboard entirely (“Something went wrong” with a message and an error ID), use its Try again re-load, or the Back to Dashboard link as an escape route. A persistent failure after retry warrants a support ticket quoting the shown error ID.

​
A concrete stall walk: fetch in flight, not a failure

A worked example of the most common case — a fresh account with traffic whose API is momentarily slow:
  1. Sign in. The greeting renders immediately (it is the headline element, painted first) and the bento grid paints skeleton shapes that reserve the final footprint.
  2. The shared stats request is in flight; the channel-health poll is on its first 30-second tick. Skeletons are the intended pending state for both.
  3. Within a few seconds the tiles settle into real values — no warning ribbon appears, because no section failed.
  4. If the window were still empty of traffic, the greeting would say so explicitly rather than claim a 0% rate; the bento tiles settle on the real zero rather than staying on skeletons.
If instead the ribbon appears naming “Channels,” the fix is a Retry all — not a browser reload, which would only re-issue the same request.

​
5. Reading the channel-health track before opening Messages

Each channel card reads your tenant’s last-24-hour delivery picture — measured against your own traffic, not the platform status page. Three colors, three meanings:
  • Green — operational. The channel’s rolling window is healthy: delivery succeeds, and measured latency (end-to-end, where the channel reports it) sits within the healthy band.
  • Amber — degraded. Delivery is succeeding but with elevated failure counts or congested latency (tens of seconds rather than a few). The card surfaces an Investigate link into that channel’s message hub (/messages/<channel>) with the failure context pre-filtered.
  • Red — down. Sending through the channel is failing outright in the window. The banner above the row groups red cards into one operational-impact headline instead of one red tile per affected channel.
A per-channel example — the email card on a workspace where email is congested but SMS is fine:
  1. The email card reads amber (degraded): the card’s “Delivery rate” line drops below the SMS card’s, its “Failed” row counts the failed deliveries over the window, and its latency row reads in the tens-of-seconds band.
  2. The impact banner above the row names email as the affected channel, so the row reads as one headline rather than one screaming tile.
  3. Clicking Investigate on the email card opens /messages/email pre-filtered to the failing receipts — the delivery receipt explains which domain or recipient is rejecting.
  4. Once the card returns to green, you open the Messages hub for routine traffic; the card amber/red step is the triage that tells you whether the hub needs attention first.
The card’s scope line (“Tenant 24h delivery”) plus its Platform status escape hatch distinguish your tenant’s delivery rate from platform-wide synthetic uptime at status.orbit.devotel.io — an amber email card while the status page reads green is about your traffic, not the platform.

​
6. Role-gated Quick Action tiles

Quick Actions renders four tiles filtered to your role, so the row only offers actions you can complete — a tile the API would 403 never appears (the same RBAC courtesy the sidebar applies to nav entries). The per-role sets:
  • Owner / admin — Send message (opens the channel-chooser, then the compose dialog for that channel), Import contacts (/audience/import), Create campaign (/outbound/campaigns/create), Build flow (/flows/builder).
  • Developer — Send message, Build flow, Create campaign, and API keys (/settings/api-keys) as the fourth tile.
  • Agent — Open inbox (/inbox, with a live assigned-open count badge), Send message, View contacts (/audience/contacts), View reports (/insights).
  • Billing — Add credits (/billing/payment), View invoices (/billing/invoices), Usage overview (/insights), Billing settings (/billing).
  • Viewer — Open inbox, View reports, View contacts, Voice overview (/voice).
Two behaviors worth knowing:
  • Compose deep links. Send message opens the channel-chooser; the chosen channel opens its page with the compose dialog mounted via a ?dialog=compose URL parameter — the same deep-link pattern described in Quick-action deep links.
  • Degraded-channel swap. When the SMS health card reports down, the primary Send-message tile is replaced by an investigate-first tile that routes you to the channel hub instead of the composer — the role gate and the health gate compose.

​
See also