> For the complete documentation index, see [llms.txt](https://docs.sealights.io/knowledgebase/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealights.io/knowledgebase/coverage-and-quality-insights/coverage-analysis/creating-and-editing-a-view.md).
# Creating & Editing a View
Create New View Wizard
This guide covers everything involved in configuring and creating a Coverage Analysis view, from choosing your metrics to defining your scope and generating the result.
{% hint style="info" %}
**Permissions note:** Only users with Admin or DevOps roles can create and edit views. All other users can access, filter, and export any view that has been created for them.
{% endhint %}
***
### Starting the Wizard
Open **Coverage Analysis** from the main navigation. Click the **View** selector at the top of the page and select **+ Create new view** at the bottom of the dropdown. A three-step wizard guides you through the full configuration.
***
### Step 1: Choose Your Metrics
Select which metrics the view should include. At least one coverage metric (Overall or Change Coverage) is required before you can proceed.
**Overall Coverage** Measures the percentage of all methods in your defined scope that were executed by at least one test during the selected time period. This is your broadest coverage signal, useful for understanding overall test health across an application or a set of services.
**Change Coverage** Measures the percentage of *modified* methods that were executed by tests. Rather than evaluating the entire codebase, this focuses on code that actually changed, making it the most direct indicator of deployment risk. When Change Coverage is selected, an additional configuration option appears in Step 2 to define the baseline for what counts as "changed."
**Failed Tests** Shows the count of unique tests that are currently failing within your defined scope. This option becomes available once at least one coverage metric is selected. Including Failed Tests alongside coverage data gives you a more complete quality picture. A service with moderate coverage and many failing tests represents a different risk profile than one with the same coverage and no failures.
When both Overall and Change Coverage are selected, the resulting view displays them as switchable tabs so you can compare both perspectives without creating separate views.
***
### Step 2: Define Your Scope
#### Date Range
Three modes control how the time window is calculated:
**Last** (default) A rolling window that always reflects the most recent N days, weeks, or months. The window moves forward automatically as time passes - a view configured as "Last 7 days" always shows the last 7 calendar days whenever it's opened. Best for ongoing monitoring and team dashboards.
**Since** Captures all data from a specific start date up to the present moment. The window grows over time. Best for tracking an in-progress sprint or release from a defined kickoff point through to now.
**Fixed** A locked start and end date that never changes. The view always shows the same time period. While most commonly used to review a completed sprint or past release window, the end date can also be set in the future, making this mode useful for pre-defining a release window or a planned testing period before it concludes.
Common presets are available (Last 7 Days, Current Week, Current Month, Current Quarter, Previous Week), and custom date and time inputs are supported for precise control.
{% hint style="info" %}
**Time selection:** \
When using Fixed or Since date ranges, you can specify an exact time (not just a date), but only when the selected date falls within the last 48 hours or is a future date. For older dates, the time defaults to the start or end of the day.
{% endhint %}
***
#### Code Scope
Defines which services and codebases are included in the view. Two approaches are available:
**Pick a Lab** Select one or more deployed labs. SeaLights automatically includes all services that were live on the selected labs during the selected date range, no need to manually list every app and branch. This is the recommended approach for most teams, especially those who don't need to manage their scope at the individual service level. If your team's services are deployed together in a lab, selecting that lab gives you complete and accurate scope in seconds.
**Use Saved Scope** Apply an existing saved code scope, or create a new one with custom filter rules using any combination of App, Branch, Lab, and Code Label criteria. When defining scope based on app/branches, SeaLights captures coverage of these apps/branches across all labs, unless only specific labs were defined in that scope.\
Saved Scopes are reusable across multiple views - define once, apply to every sprint view, release view, and monitoring view for that team or product area.
{% hint style="info" %}
**Note:** A Saved Scope that is linked to one or more active views is protected from deletion. To remove it, you first need to delete or reconfigure any views that reference it. Deletion is done from the Coverage Dashboard.
{% endhint %}
***
#### Test Stages
By default, all test stages are included in the view, including any new stages added in the future. You can manually select specific stages when the view should only reflect a subset of your testing pipeline. For example, a release readiness view might include only the stages that are part of the formal release validation pipeline, while a sprint view includes all stages.
***
#### Code Changes
{% hint style="info" %}
Only visible when Change Coverage is selected.
{% endhint %}
Sets the reference point for determining what counts as "changed code." Two options are available:
**Since date range start date** (default) A method is considered changed if it was modified after the start of the selected date range. This links the change baseline directly to the same window as the test data, the simplest and most common choice.
**Since a specific reference date** Set an independent baseline for change detection. Useful when the start of change activity doesn't align with the start of your test window. For example, measuring test results over the last 14 days while counting changes relative to the previous release date or a sprint kickoff that predates the current window.
***
### Step 3: Name the View
Give the view a name that helps your team find it in the view selector. Names don't need to be unique. Teams can use naming conventions that work for their workflow, such as "Sprint 44 – Payments Team" or "Release 3.2 – Final".
***
### Generating the View
Click **Generate Coverage Analysis** to submit your configuration. SeaLights assembles the view by aggregating coverage data across all the apps, test stages, and time range you specified. Depending on the size of your scope, this may take a moment, you're free to navigate elsewhere in the platform while it completes. When the view is ready, it will be available in the view selector for your whole team.
***
### Editing a View
To edit an existing view, open it from the view selector and click the edit option. The wizard reopens with all your current settings pre-filled. Saving changes re-generates the view with the updated configuration.
{% hint style="info" %}
Only the view's creator and DevOps users can edit a view.
{% endhint %}
***
### Deleting a View
Views can be deleted permanently. To delete an existing view, open the view selector and press the Delete icon next to the view name. A confirmation step is required. Deleting a view removes it for all users. If others on your team use the view, coordinate before deleting.
{% hint style="info" %}
Only the view's creator and DevOps users can edit a view.
{% endhint %}
***
### Permissions Summary
Action
Who can do it
Create a new view
Admin, DevOps
Edit a view
View creator, DevOps
Delete a view
View creator, DevOps
View, filter, and export
All users
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.sealights.io/knowledgebase/coverage-and-quality-insights/coverage-analysis/creating-and-editing-a-view.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.