> ## Documentation Index > Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt > Use this file to discover all available pages before exploring further. # Copilot ui # Doc Type: CoPilot UI Reference > **Tier**: Reference | **Reader phase**: Refining & Details\ > **Back to tier overview**: [reference/index.md](index.md) *** ## What it is A CoPilot UI Reference document describes **a specific page or panel in the Aviatrix CoPilot interface**: its purpose, the fields it contains, and the actions that can be performed on it. It covers both the meaning of fields and how to execute individual actions (Create, Edit, Delete, Enable, and similar). One document covers one UI page or logical panel grouping. Documents are organized to mirror the CoPilot navigation structure. These documents answer two questions: *What do these fields mean?* and *How do I execute this action?* UI Reference docs are the canonical home for individual actions. Configuration Guides include these steps directly — readers should not have to flip between documents to complete a task. To avoid maintaining duplicate source, action steps can be extracted into snippets that both the UI Reference accordion and the Configuration Guide import. *** ## Goal After reading a CoPilot UI Reference document, the reader understands the purpose and meaning of every field on this page and knows how to execute any action available on it. They can complete a single action or look up a field value without consulting another document. *** ## Primary personas | Persona | How they use it | | - | - | | **Operator** | Primary audience. Looks up field meanings during day-to-day use | | **Engineer** | References field descriptions when following a Configuration Guide | | **Technical Manager** | Occasionally reviews to understand what data is available in dashboards | *** ## When to create a new UI Reference document Create a new UI Reference document when: * A new page or significant panel is added to CoPilot * An existing page gains fields or controls significant enough to require documentation * A Configuration Guide references a UI panel that has no corresponding reference page One document per CoPilot page or logical panel group. Do not create a document per individual field. *** ## Required sections Each page follows the same three-section structure — Purpose, Elements, Actions — in that order. For tabbed pages, repeat all three sections inside each ``. 1. **Purpose** — 2–4 sentences describing what this page is for, what information it surfaces, and who uses it. The first sentence names the page (or, inside a ``, the tab) in bold, matching the page/tab title exactly, for example: "The **Specialty Gateways** page lets you view the list of configured Specialty Gateways and their details." Do not open with a bare pronoun ("This page...") or an unbolded page name. 2. **Elements** — An image of the page followed by a bullet list of every UI element with a brief description. Format: `- **Element Name**: Description.` Include all visible controls, fields, dropdowns, buttons, and data columns. An image is required. Each element is its own bullet, on its own line, starting with a list marker (`-` or `*`) at the start of the line. Never join two or more elements onto one line with an inline `-` or `—` separator (for example, `**Element A**: description. - **Element B**: description.`) — that renders as a single run-on paragraph with no bullets instead of a list. This most often happens when a long list survives a bulk edit (a find/replace pass, an automated style-normalization script, or manual conflict resolution during a merge/rebase) that reflows the text without preserving each line's leading marker. After any bulk edit that touches an Elements list — and especially after resolving a merge/rebase conflict in one of these files — re-render the page (or check the generated file under `docs/enterprise//...`) and visually confirm every element still appears as its own bullet, not merged into the previous one. Immediately before committing a change to any file under `snippets/enterprise/pages/reference/ui/`, run `npx prettier --write` (or `--check`) on that file if it is not listed in `.prettierignore`. A list that has collapsed into a run-on paragraph will not be "fixed" by Prettier — Prettier reformats lists, it does not reconstruct one from mangled prose — so this check only catches the corruption, it does not repair it. Reconstruct the bullets by hand (one element per line, matching what the live UI actually shows) whenever this pattern is found. 3. **Actions** — An `` containing one `` per action. Order the accordions **View, Create, Edit, Delete**, followed by any other actions (Enable, Disable, and similar) in the order their controls appear in Elements. Each accordion opens with a one-line intro sentence stating the goal of the action (for example, "To create a gateway:"), followed by numbered steps to execute the action, followed by a **Parameter Details** table (CoPilot Parameter Name | Description) covering the parameters involved. Actions are self-contained — the reader should not need another document to complete them. Configuration Guides reference individual actions here as steps in a larger workflow. A **Parameter Details** table must always be nested inside the `` for the one action that opens the dialog/form it describes. Never place a `### Parameter Details` heading as its own standalone section between **Elements** and **Actions** — that duplicates (and drifts from) the Elements bullets describing the same fields, and the table has no action for the reader to complete. If a table of fields belongs to the page itself rather than a specific action's dialog (for example, columns of a data table shown on load), describe those fields in **Elements** as bullets instead — do not give them a `### Parameter Details` heading outside an accordion. `scripts/lint_docs.py` enforces this as a hard CI error. For the "other actions" that follow View, Create, Edit, Delete, order them in the same top-to-bottom (and left-to-right, for side-by-side cards or panels) sequence the corresponding elements appear on the live UI — the same order used in **Elements**. Do not order those remaining accordions arbitrarily or by any scheme that diverges from the page layout; a reader scanning the page should be able to find the matching accordion at the same relative position among the non-CRUD actions. Whether to group top-level accordions under category-header ``s depends on the count of top-level accordions in that Actions section (or that single ``'s Actions section): * **Fewer than 5** — leave them as one flat list. Do not group. * **5–7** — group them only if there is a clear, natural way to split them into distinct groups (for example, the accordions already fall into obvious clusters by feature/card, matching a grouping already visible in **Elements**). If no such natural split exists, leave the list flat rather than forcing an artificial grouping. * **More than 7** — always group them under category-header ``s instead of leaving one long flat list. This cap is a hard limit on every accordion container, not just the top level: no single `` and no single group `` may directly contain more than 7 child accordions. If grouping a long flat list still leaves one group with more than 7 actions, split that group further into two or more sibling groups (each named for its own sub-cluster of actions) rather than exceeding 7 in any one container. This keeps nesting at two levels either way — it adds more sibling groups, not a third level of nesting. Name each group accordion after the feature/card it configures (for example, `Configure Transit Gateway`, `Manage Gateway Attachments`, `Actions on Transit Gateway`, `Configure Global BGP Communities Support`), matching the grouping already used in **Elements**. A single action that has no natural sibling can stay top-level and ungrouped rather than being forced into an artificial group of one. See the Transit Gateways, Spoke Gateways, and Settings tabs in `snippets/enterprise/pages/reference/ui/cloud-fabric/gateways-v101.mdx` for the canonical pattern. Nest no more than two levels deep: `` → group `` → action ``. Never add a third level — no group nested inside another group, and no `` nested inside an action ``. For example, never do this: ```markdown theme={null} ## Actions ... ``` `Attachments` here is a second group level nested inside `Configure Gateway` — flatten it instead: either fold `Attach a Gateway` (and its siblings) directly into `Configure Gateway`, or promote `Attachments` to its own top-level group accordion, whichever better matches the page layout. **Indentation must match nesting depth, and every sibling accordion must be indented identically.** MDX does not require this to render correctly, so drift will not fail the build — but it makes the file unreadable and hard to diff, and it is the most common way a stray third nesting level or an orphaned/duplicated `` gets introduced unnoticed (usually while copy-pasting an existing accordion to create a new sibling, or while wrapping a run of existing accordions in a new group accordion). Before committing any change to an Actions section: * A tag's own opening and closing lines (`` … ``) must use the *same* leading whitespace. * Every sibling accordion at the same level — inside the same `` or the same group `` — must use the *same* leading whitespace as the sibling immediately before and after it. Do not indent one sibling deeper "for clarity," and do not leave one shallower after a copy-paste. * When you wrap an existing run of top-level accordions in a new group `` (per the grouping rule above), re-indent that entire run to its new depth — do not leave the group's ``/`` at the old depth while its children stay unindented, and do not add indentation for indentation's sake if the file's existing convention keeps nested accordions flush with their parent (check neighboring tabs in the same file for the established convention before choosing one). * After the edit, verify tag balance and matching indentation by re-reading the diff: every `-` (removed) opening/closing tag should pair with exactly one `+` (added) tag at the same nesting position, and no `` should appear without a corresponding open at the same depth. *** ## Optional sections * **Related Tasks** — Links to Configuration Guides for the most common tasks performed on this page * **Permissions** — When specific CoPilot roles or permissions are required to view or interact with this page * **Notes and Limitations** — Known UI behaviors, data refresh rates, or display limitations worth documenting *** ## Tone & voice **Two modes — descriptive for elements, instructional for actions.** Elements: write descriptions as short noun phrases or sentences. "Dropdown to select time period." State what it does; no need to explain why. Keep it brief. Actions: use imperative mood ("Go to...", "Click...", "Set...") for steps within each accordion. Keep each action self-contained and minimal — only the steps to execute that one action. Do not explain why the action exists or when to use it; that belongs in a Configuration Guide or Component doc. *** ## Length guidance **50–200 lines** per page. Simple configuration pages run 50–80 lines. Complex dashboard pages or heavily tabbed pages run 150–200 lines. If a page's documentation exceeds 200 lines, consider whether it should be split by tab or panel into multiple documents. *** ## Frontmatter See [Frontmatter Standards](../frontmatter.md) for field definitions and formatting rules. The title must match the CoPilot page name exactly as it appears in the navigation. ```yaml theme={null} --- title: "[Page Name]" description: "Reference for the CoPilot [Page Name] page — [brief description of purpose and navigation path]." --- ``` *** ## Format examples **Purpose section:** ```markdown theme={null} ## Purpose The **Specialty Gateways** page lets you view the list of configured Specialty Gateways and their details. ``` **Elements section:** ```markdown theme={null} ## Elements Page Name: section description - **Gateway Name**: The unique identifier for this gateway within the Aviatrix platform. - **Gateway Size**: The cloud provider instance type assigned to this gateway. - **Enable**: Button to enable the selected gateway. ``` **Wrong — do not do this.** Elements merged onto shared lines with an inline dash instead of one bullet per element: ```markdown theme={null} - **Gateway Name**: The unique identifier for this gateway within the Aviatrix platform. - **Gateway Size**: The cloud provider instance type assigned to this gateway. - **Enable**: Button to enable the selected gateway. ``` This renders as a single paragraph with no bullets at all. If an Elements list looks like this (or you notice list items are missing their leading `-`/`*` after a bulk edit or merge), rebuild it as one bullet per element, matching the wrapping style shown in the correct example above. **Actions section:** ```markdown theme={null} ## Actions To view the list of configured gateways: 1. Go to **Cloud Fabric** > **Gateways**. 2. Review the gateway table for name, size, and status. ### Parameter Details | CoPilot Parameter Name | Description | | ---------------------- | ---------------------------------------------------------- | | Gateway Name | Unique name for the gateway within the Aviatrix platform. | | Gateway Size | Cloud provider instance type. Affects throughput capacity. | To create a gateway: 1. Go to **Cloud Fabric** > **Gateways**. 2. Click **+ Gateway**. 3. Complete the required fields and click **Save**. ### Parameter Details | CoPilot Parameter Name | Description | | ---------------------- | ---------------------------------------------------------- | | Gateway Name | Unique name for the gateway within the Aviatrix platform. | | Gateway Size | Cloud provider instance type. Affects throughput capacity. | ``` Accordion order in this example — View, then Create — illustrates the required **View, Create, Edit, Delete** ordering; add Edit and Delete accordions the same way when the page supports them. **Grouping many actions:** When a tab's Actions section has more than 7 top-level accordions (or 5–7 with a clear natural split), group the related ones under a category-header `` instead of one flat list: ```markdown theme={null} ## Actions ... ... ... ... ... ... ... ``` `Configure Gateway` and `Manage Gateway Attachments` are category-header accordions, each wrapping its own set of action accordions. `Enable or Disable Rollback on Gateway Creation Error` has no sibling action, so it stays top-level and ungrouped. *** ## Mintlify components See [Style Guide](../style-guide.md) for component definitions and usage rules. Use `` for tabbed UI pages (mirror the UI structure), `` for individual actions in the Actions section, `` for annotated screenshots, and `` for unexpected UI behaviors. `` may be used within an action accordion if the action involves more than three sequential steps; otherwise use a numbered list. *** ## Linking * **Link in from**: Configuration Guides that use this page, Component docs for the feature this page manages * **Link out to**: No fixed outbound relationship *** ## Dos and don'ts | Do | Don't | | - | - | | Match the H1 title exactly to the CoPilot page name | Use informal or abbreviated page names | | Open the Purpose section's first sentence with the bold page/tab name | Start Purpose with "This page..." or an unbolded page name | | Document every visible field, even if the description is brief | Skip fields because they seem self-explanatory | | Document every action as its own accordion in the Actions section | Embed action steps inline in field descriptions | | Order accordions **View, Create, Edit, Delete**, then other actions | Order actions arbitrarily or in the order they were written | | Open every action accordion with a one-line "To \*\*\_:" intro sentence before the steps | Jump straight into numbered steps with no intro sentence | | Put every Parameter Details table inside the `` for the action that opens it | Add a `### Parameter Details` table as a standalone section outside any `` | | Group related actions under a category-header `` once a tab's Actions section has more than 7 top-level accordions (or 5–7 with a clear natural split) | Leave a long flat list of 8+ unrelated action accordions in one ``, or force an artificial group split at 5–7 with no natural grouping | | Split a group further into sibling groups if it would otherwise directly contain more than 7 child accordions | Let any single `` or group `` directly contain more than 7 child accordions | | Nest at most two levels — `` → group `` → action `` | Nest a group `` inside another group, or any `` inside an action `` | | Give every sibling `` the same indentation, and match each tag's own opening/closing indentation | Let one accordion drift a few spaces deeper/shallower than its siblings after a copy-paste or a new grouping wrap | | Give every Elements bullet its own line with a leading `-`/`*` marker; re-check rendered output after any bulk edit or merge/rebase touching the file | Let two or more elements merge onto one line joined by an inline `-` separator, collapsing the list into a run-on paragraph | | Keep each action accordion self-contained | Require the reader to consult another document to complete the action | | Note field dependencies ("Only visible when X is enabled") | Leave conditional fields undocumented | | Keep the structure parallel to the CoPilot navigation hierarchy | Reorganize or regroup fields in a way that doesn't match the UI | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.