The lens analogy
Imagine a large table of engineering data laid out on a desk. The table itself does not change — the same rows, the same relationships, the same values. Now imagine placing different colored filters over that table. One filter highlights requirement traceability columns and hides risk columns. Another reveals verification and validation test case columns while concealing design-level detail. A third shows everything. Each filter is a view — a named perspective that selects which columns to show and which to suppress.
The critical insight is that views are not separate sheets. They are overlays on a single sheet configuration. When you switch from one view to another, the data does not reload, the hierarchy does not change, and any unsaved edits remain intact. Only the column visibility toggles.
Each view points to the same underlying data. Switching views does not reload or requery — it toggles column visibility.
How views relate to the base configuration
Every sheet configuration has an implicit Base View. This is the column layout defined directly in the top-level columns section of the sheet configuration YAML. The Base View represents the full set of columns and their default visibility. If no views section exists, or if no named view has been selected by the user, the Base View is what the sheet displays. It is labeled “Default view” in the user interface unless you explicitly name it.
Named views, defined in the views section of the YAML, are extensions of the Base View, not replacements. A named view does not need to redeclare every column — it only overrides the properties it wants to change. In practice, this almost always means toggling visible to true or false for specific columns. The binding paths used in a view must match the binding paths defined in the Base View’s columns section; a view cannot introduce columns that do not exist in the base configuration.
A view only needs to declare the columns whose visibility (or other properties) differ from the Base View. Every column not mentioned in a view inherits its default state from the base columns definition.
Naming the Base View
You can give the Base View a display name by defining an empty view in the views section:
views:
Full Traceability: {}
View structure in YAML
Views are defined under the views key at the root level of the sheet configuration. Each view is a named object whose columns property lists the binding paths to override:
views:
Without V&V:
columns:
validationTestCases.validationTestCase:
visible: false
systemRequirements.systemRequirement.verificationTestCases.verificationTestCase:
visible: false
systemRequirements.systemRequirement.designRequirements.designRequirement.verificationTestCases.verificationTestCase:
visible: false
validationTestCases.validationTestCase, etc.) must exactly match those declared in the base columns section.
Setting a default view
Any view can be marked as the view that loads automatically when a user first opens the sheet:
views:
Requirements Only:
default: true
columns:
hazards.hazard:
visible: false
riskControls.riskControl:
visible: false
default is set to true, this view is applied during initialization instead of the Base View. If no view has default: true, the Base View is used. Only one view should be marked as default; if multiple views declare default: true, the behavior is determined by processing order.
View properties reference
Views support a focused subset of the properties available on base columns:
| Property | Type | Purpose |
|---|
default | boolean | When true, this view loads on initialization. Default: false |
columns | object | Subset of base column binding paths with overridden properties |
columns.<binding>.visible | boolean | Show or hide the column in this view |
columns within a view use the same binding path notation as the base columns section — dot-separated paths that follow navigation properties through the domain model hierarchy (e.g., systemRequirements.systemRequirement.title).
Views currently control column visibility. They share the same configuration options as base columns, but in practice visible is the primary property used in view overrides. Other column properties like width or title can theoretically be set per view, but visibility toggling is the intended and most common use case.
Why views matter: analysis perspectives
In a real-world project, a single traceability matrix may contain dozens of columns spanning entity types across the full requirements chain (UserNeed through SystemRequirement, DesignRequirement, Hazard, and RiskControl). Different roles need different subsets of this information:
- A requirements engineer working on allocation may want to see
UserNeed properties alongside SystemRequirement properties, but has no need for risk or test columns
- A safety engineer performing a risk assessment wants
Hazard and RiskControl columns in focus, with requirement columns collapsed or hidden
- A test engineer preparing verification plans needs the test case columns visible and requirement details reduced to identifiers only
- A project manager reviewing overall coverage wants a broad view showing key status fields across all entity types
Without views, each of these perspectives would require a separate sheet configuration pointing to the same domain model and the same data sources. That approach leads to configuration duplication, maintenance burden, and divergence risk. Views eliminate this problem by keeping a single source of truth for columns, sources, and data while allowing each audience to focus on what matters to them.
The mental model: one sheet, many lenses
The following table captures the key distinction between views and other approaches to displaying different subsets of data:
| Approach | Data sources | Column definitions | Maintenance cost |
|---|
| Separate sheet configurations | Duplicated per config | Duplicated per config | High — changes must propagate to all copies |
| Single config, no views | Shared | Single set, all visible | Low config, but cluttered for users |
| Single config with views | Shared | Single set, visibility toggled per view | Low — one base config, lightweight view overrides |
A common misconception is that views can show or hide specific rows or entity types. Views operate exclusively at the column level. If you need to filter which rows appear, use source query where clauses or client-side column filters (the filter property on individual columns). See Source Configuration for query-level filtering. Views and column groups
Views interact naturally with column groups (columnGroups). When a view hides all columns within a particular column group, the group header also disappears from the sheet. When a view reveals columns within a group, the group header reappears. This means you can use column groups to organize related columns under a common header, and then use views to show or hide entire groups at once by toggling the visibility of their member columns.
For example, if a column group named “Test Cases” contains three test-related columns, a view that sets all three to visible: false effectively hides the entire group. No special group-level visibility setting is needed — the group’s visibility follows its columns.
This interaction between views and column groups creates a powerful organizational pattern:
- Define column groups in the base configuration to cluster related columns (requirements, tests, risks)
- Define views that toggle visibility of entire groups by listing their member columns
- Users switch views to reveal or hide logical sections of the sheet
Practical patterns
The “progressive disclosure” pattern
Define views that progressively reveal more columns:
- Overview — shows only key identifiers and status fields across all entity types
- Detailed — adds description, priority, and assignment columns
- Full — shows every column, including metadata and audit fields
This pattern works well for onboarding new users who might be overwhelmed by a fully expanded sheet.
The “role-based” pattern
Define views named after the roles that use them:
- Requirements Engineer —
UserNeed and SystemRequirement columns prominent, test and risk columns hidden
- Safety Engineer —
Hazard and RiskControl columns visible, design columns hidden
- Reviewer — status, owner, and approval columns visible across all entity types
Role-based views make the sheet self-documenting. A user switching to their role’s view instantly sees a tailored workspace.
The “phase-based” pattern
In projects that follow lifecycle phases, views can align with project milestones:
- Requirements Phase — focuses on allocation and decomposition columns
- Design Phase — reveals design requirement and architecture columns
- Verification Phase — shows test case and test result columns
Each phase view keeps historical columns accessible (just hidden) while foregrounding the currently active work.
Common misconceptions
“Switching views reloads the data.” It does not. View switching is a client-side operation that toggles column visibility. The data remains loaded in memory. Unsaved changes, scroll position, and expanded rows are preserved.
“I need a separate sheet configuration for each team.” In most cases, a single sheet configuration with well-designed views achieves the same result with far less maintenance. Reserve separate configurations for cases where the data sources or expansion paths differ, not just the visible columns.
“Views can change the column order.” Views control visibility, not column ordering. The column order is determined by the sequence in which columns are declared in the base columns section. If you need a different column sequence, that requires a separate sheet configuration.
“A view can add columns that are not in the base configuration.” A view’s columns property must reference binding paths that already exist in the base columns section. A view cannot introduce new binding paths or new columns — it can only modify properties of existing ones.
Relationship to other concepts
Views are one layer in the Powersheet configuration stack. Understanding where they fit helps avoid over-engineering at the wrong layer:
- Domain model defines what data exists and how entity types connect — see Entity Types and Relationships
- Sheet configuration (base) defines all available columns, sources, and layout — see Data Model vs Sheet Configuration
- Views control which columns are visible for a given perspective (this page)
- Column groups organize columns into collapsible visual sections — see Core Components
- Source configuration controls which data is loaded and how the hierarchy expands — see Source Configuration
For practical guidance on creating and managing views in your sheet configuration, see the Sheet Configuration Guides. For the complete YAML reference of view properties, see the Sheet Configuration Reference.
