Using the Interface

This guide explains how to get around the AtlasAI Tenant Plane UI and use key interface patterns. Knowing these will make your daily work faster and reduce friction.

Command palette

What it is

The command palette is a single entry point for navigation and common actions. You open it with a keyboard shortcut (e.g. Cmd+K / Ctrl+K) or from the menu, type a few characters, and jump to a page or run an action.

Why use it

• Speed: Reach Incidents, Runbooks, Dashboards, Data Sources, or Settings without clicking through the sidebar.
• Consistency: Same flow on desktop and smaller screens.
• Discoverability: You can search for features by name.

When to use it

• When you know the name of the section you want (e.g. “Incidents”, “Runbooks”).
• When you’re on a small screen and the sidebar is collapsed.
• When you want to run a quick action (e.g. “New incident”) without using the mouse.

How to use it

1. Press the shortcut (e.g. Cmd+K or Ctrl+K) or open it from the header/menu.
2. Type part of the destination or action (e.g. “incident”, “dashboard”).
3. Use the arrow keys to select, Enter to go (or click).
4. For “New incident” or similar, choose that action to open the create flow.

Sidebar and layout

What you see

• Sidebar: Main navigation (Command Center, Incidents, Runbooks, Automation, Dashboards, Data Sources, Settings, etc.). It may show icons only or icons + labels depending on width.
• Collapse/expand: A control (e.g. chevron or hamburger) collapses the sidebar to icons only or hides it so you get more space for content.
• Responsive behavior: On narrow screens, the sidebar may be off-canvas (e.g. hamburger menu); opening it overlays or pushes content.

Why it matters

• Efficiency: Collapse when you need maximum space for a dashboard or incident; expand when you’re navigating.
• Consistency: Same structure on desktop and tablet so you always know where to find things.
• Tenant context: If you manage multiple tenants, the current tenant is usually shown in the sidebar or header; switch tenant from there or from Settings.

When to use what

• Full sidebar: When you’re exploring or switching between areas often.
• Collapsed sidebar: When you’re focused on one page (e.g. incident detail, dashboard) and want more horizontal space.
• Hamburger/menu: On small screens, use it to open the sidebar, then pick the section you need.

Forms and validation

What to expect

Forms (e.g. New Incident, Edit Runbook, Create Policy, Invite User) use:

• Clear labels and, where needed, help text.
• Validation before or on submit: invalid fields are highlighted with a short message (e.g. “Title is required”, “Invalid email”).
• Consistent controls: text inputs, dropdowns, checkboxes, and date/time pickers behave the same across the product.

Why it helps

• You fix errors before submitting, so you don’t lose work or create bad data.
• Messages tell you what to change, not just that something is wrong.

When and how

• While filling: Optional fields are usually marked; required ones are indicated (e.g. asterisk).
• On submit: If validation fails, the page stays open and invalid fields are marked; correct them and submit again.
• After submit: A success message or redirect confirms the action; if the server returns an error, it’s shown in the form or at the top of the page.

Charts and data views

What’s available

• Time-series charts: Metrics over time; zoom and time-range controls.
• Topology / dependency graphs: Services and dependencies; click nodes to drill down.
• Tables: Sortable, filterable lists (e.g. incidents, runbooks); some support pagination (see What’s new — pagination).

Why it matters

• Accessibility: Charts and tables are built so they can be used with keyboard and screen readers (e.g. labels, structure).
• Clarity: Axes, legends, and tooltips help you interpret data correctly.

When to use what

• Charts: In Dashboards and in incident evidence when you’re analyzing metrics.
• Topology: In RCA and impact analysis to see blast radius and dependencies.
• Tables: When you need to sort, filter, or page through lists (alerts, incidents, content packs). Use filters first to narrow results, then paginate if needed.

Error handling and recovery

What you’ll see

• In-page errors: If a single section fails (e.g. a widget or panel), you may see a message like “Something went wrong” with a Retry button. The rest of the page stays usable.
• Full-page errors: If the whole page fails, you’ll see a clear message and usually a way to go back or reload.
• API errors: When an action fails (e.g. save, run), the UI shows a short error message; for support, a trace ID may be included.

Why it’s done this way

• You’re never left with a blank screen without guidance.
• Errors are contained so one failure doesn’t block the rest of the app.
• Trace IDs help support troubleshoot without exposing internal details.

When and what to do

• Retry: Use Retry for transient failures (e.g. network blip).
• Navigate away: If retry doesn’t help, go back or open another section and try again.
• Report: If the error persists, note the message and any trace ID and report to your admin or support.

Quick reference

See also

• What’s new — Recent UI and product enhancements
• First login to first value — Where things live after sign-in
• User Guide overview — Runbooks, scheduling, war room, policies, dashboards