# Page-header actions

Page headers establish the title and the actions that operate on the entire page or resource. Their hierarchy must reflect intent, not simply the number of available actions.

## Page frame

Breadcrumbs, header copy, header actions, and the first page-content region share the constrained `--content-max-width` container. Use 24px horizontal gutters below the desktop breakpoint and 32px gutters at desktop widths. Do not let a registry panel become wider than its breadcrumb and header frame.

## Variants

| Variant | Use in a page header | Examples |
| --- | --- | --- |
| Primary | The single, clear forward action for the page | Add user, Create integration, Invite member |
| Secondary | Contextual operations on the current collection or resource | Edit, Sync connector, Export, Duplicate |
| Quiet | Lower-priority management or navigation that should remain available | View history, Manage groups |
| Danger | An immediate destructive action, only when it cannot reasonably live in an overflow menu | Delete, Revoke access |

## Rules

1. A page may have no primary action. Do not promote a secondary operation merely to fill the hierarchy.
2. Use no more than one primary action in a page header.
3. Place the primary action at the far right in left-to-right interfaces. Secondary and quiet actions precede it.
4. Use the neutral primary style across products. Accent and status colors do not determine action hierarchy.
5. Use concise, specific, sentence-case labels. Prefer a verb and object when the object is not already obvious.
6. Add a leading plus icon only to additive actions. Icons clarify meaning; they do not change a button's hierarchy.
7. Use the standard 40px control height. The 36px compact height belongs to dense toolbars, not page headers.
8. Keep destructive actions out of the page header when an overflow menu or dedicated settings region provides a safer home. Confirm destructive actions before execution.
9. Name the resource or task directly. Do not repeat the current product or application name when the sidebar or breadcrumb already establishes that context.

## Common page types

### Collection or list

Use a primary button when the user can add the resource represented by the page. For example, a Users page uses **Add user** as its single primary action.

### Resource detail

Use secondary actions for operations such as **Sync connector** and **Edit** when neither represents the page's obvious forward path. A detail page does not need a primary action.

### Workflow step

Use a primary action only when the page has a clear progression, such as **Submit review** or **Approve request**. Put reversible supporting operations before it.

## Responsive behavior

On narrow screens, move the action group below the title and metadata. Preserve action priority and reading order. Allow actions to wrap; use full-width buttons only when the available width would otherwise make labels unclear or targets too small.

When space is limited, move low-priority actions into an accessible overflow menu before hiding or shortening the primary action.