> For the complete documentation index, see [llms.txt](https://docs.groundcover.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.groundcover.com/investigate/saved-views.md).

# Saved Views

Save the view of any groundcover page exactly the way you like it, then jump back in a click.

A Saved View captures your current page layout: filters, columns, toggles, etc.. so you and your team can reopen the page with the same context every time. Each groundcover page maintains its own catalogue of views, and every user can pick their personal **Favorites**.

***

### Where to find them

On the pages: Traces, Logs, Events, API Catalog, Monitor List, Monitor Issues, Notification Routes, and the Dashboards list.

Individual dashboards also support views. A dashboard's views are scoped to that dashboard rather than to a page, and capture its variable selections and time range — see [Saved views](/investigate/dashboards-and-alerts/create-a-dashboard.md#saved-views) in the dashboards guide.

Look for the Views selector next to the time‑picker. Click it to open the list, create a new view, or switch between existing ones.

***

### Saving a view

1. Configure the page until it looks exactly right—filters, columns, panels, etc.
2. Click **➕Save View**.
3. Give the view a clear **Name**.
4. Hit **Save**. The view is now listed and available to everyone in the project.

> **Scope** – Saved Views are **per‑page**. A Logs view appears only in Logs; a Traces view only in Traces.

***

### What a view stores

#### Common to all pages

| Category                            | Details                                                    |
| ----------------------------------- | ---------------------------------------------------------- |
| **Filters & facets**                | All query filters plus facet open/closed state             |
| **Columns**                         | Chosen columns, and their order, sort, width               |
| **Filter** **Panel & Added Facets** | <p>Filter panel open/closed</p><p>Facets added/removed</p> |

#### Page‑specific additions

| Page            | Extra properties saved                                                                                                                                                               |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Logs**        | <ul><li><code>logs</code> / <code>patterns</code></li><li><code>textWrap</code></li><li><code>Insight</code> show / hide</li></ul>                                                   |
| **Traces**      | <ul><li><code>traces</code> / <code>span</code></li><li><code>table</code> / <code>drilldown</code></li><li><code>textWrap</code></li><li><code>Insight</code> show / hide</li></ul> |
| **API Catalog** | <ul><li><code>protocol</code></li><li>Kafka role: <code>Fetcher</code> / <code>Producer</code></li></ul>                                                                             |
| **Events**      | <ul><li><code>textWrap</code></li></ul>                                                                                                                                              |

**Dashboards**

A dashboard view stores the dashboard's **variable selections** and its **time range**, rather than the columns-and-filters set above.

### Default views

One view per page — or per dashboard — can be marked as your **default**. Opening that page then applies the default automatically, so you land on your own working setup rather than the page's built-in one.

A default is personal: marking one doesn't change what anyone else sees.

A URL that already carries its own state wins over the default. That means a link a colleague sends you opens on what *they* were looking at, not on your default view.

***

### Updating a view

The **Update View** button appears only when **you are the creator** of the view. Click it to overwrite the view with your latest changes.

Underneath every View you can see which user created it.

***

### Managing views (row operations)

| Action            | Who can do it?          |
| ----------------- | ----------------------- |
| **Edit / Rename** | Creator                 |
| **Delete**        | Creator                 |
| **Star / Unstar** | Any user for themselves |

***

### Searching, Sorting, and Filtering the list

Searching the Views will look up based on View names and the creators.

The default sorting pins the favorites views at the top, and the rest of the views below. Each group of views is sorted from A→Z.

In addition, 3 filtering options are available:

1. **All Views** - The entire workspace's views for a specific page
2. **My Favorites** – The favorite views of the user for a specific page
3. **Created By Me** - The views created by the user


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.groundcover.com/investigate/saved-views.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.