Saved Views

Saved views let you bookmark frequently used filter, sort, and column configurations so you can return to them with one click instead of rebuilding complex queries each time.

What Gets SavedCopy Anchor Link

A saved view captures the complete state of a list page:

Creating a Saved ViewCopy Anchor Link

1. Set up the CI list or change history page with your desired filters, columns, and sort order
2. Click the Saved Views dropdown in the toolbar
3. Click Save Current View
4. Enter a name and optional description
5. Choose whether to Share with everyone (off by default)
6. Click Save

Private and Shared ViewsCopy Anchor Link

A saved view is private to you unless you share it.

Turn Share with everyone on when you save a view, and it appears in the dropdown for every user in your tenant, marked with a group icon. Sharing grants read access only -- nobody else can rename, re-filter or delete a view you shared.

You can also change your mind later: each view you own carries a share button in the dropdown -- a share icon on a private view, a padlock on a shared one. Unsharing takes the view straight back out of everyone else's list.

A superadmin can take a shared view down as well -- unshare it, or delete it. That is the whole of their authority over a view somebody else made: they cannot rename it, change its filters, or share a view you kept private. It is there so a view shared by someone who has since left the tenant does not sit in everyone's dropdown with nobody able to remove it. Once a shared view is unshared it is private to its owner again, and only its owner can share it a second time.

Using Saved ViewsCopy Anchor Link

1. Click the Saved Views dropdown
2. Select a saved view from the list
3. The page immediately applies that view's filters, columns, and sort order

Managing Saved ViewsCopy Anchor Link

• Rename - Edit the name or description of a view you own
• Delete - Remove a saved view you no longer need
• Share / unshare - Change who can load a view you own
• Views are stored in the database and persist across browser sessions
• Views shared with you by someone else are read-only, so they carry no edit or delete controls -- a superadmin sees unshare and delete on them, and nothing more

Per-Page ViewsCopy Anchor Link

Saved views are scoped to their page context:

• Views saved on the Configuration Items page only appear on that page
• Views saved on the Change History page only appear on that page
• This prevents clutter and keeps views contextually relevant

Using a View in a Tagging RuleCopy Anchor Link

A tagging rule can take its scope from a saved view: in Create Tagging Rule, choose Saved View under Scope and pick a view from the CI list. The rule copies the view's filters, and Parascope checks them when you save the rule. It refuses the save, and names the filter at fault, when:

• A field is unknown. Field names are case-sensitive.
• A field belongs to a related record. A filter on a CI's tags, changes or relationships is not supported in tagging rules. Filter on a CI field (name, type, source, namespace, status, IP addresses, hostnames, FQDNs, timestamps), a type-specific attribute, or a raw data path such as spec.priority (saving one needs the raw_data:read permission), or write the rule as a ParaQL condition.
• A type-specific attribute has no CI type. A filter on an attribute of one CI type (for example a Proxmox VM's vmid) needs a Type filter for exactly that type, as the CI list does. The CI list adds one when you pick a field only one CI type has. The rule then matches what the view showed: only CIs of that type, including for filters joined by OR.
• An operator is unknown.
• An "in" or "not in" filter has no values. Give it a list, or values separated by commas.
• Filters are joined by something other than AND or OR.

Some filters exist only in the CI list, so a view that uses them cannot become a rule: tag filters (a tag value, or a tag being present or absent), free-text search, and the CI key filter. Remove those filters from the view, or write the rule as a ParaQL condition.

When you start from Create Tagging Rule and build the scope in the CI list, the field picker offers only fields a tagging rule accepts.

Before these checks, a rule built from such a view could tag CIs that the view did not show. A rule saved earlier with a field or operator these checks refuse, or with an empty "in" or "not in" filter, now fails each run, and Parascope turns it off after three failed runs in a row. Turning the rule off this way keeps the tags it already applied, including any it applied to CIs the view did not show. To clean them up, either edit the rule's condition, turn the rule back on and use Run now (a run removes the rule's tags from CIs that no longer match), or delete the rule and choose Remove all tags from this rule.

TipsCopy Anchor Link

• Save views for common workflows: "Production Kubernetes pods", "Recent Ceph changes", "Inactive CIs"
• Share the views your whole team reaches for; keep works-in-progress private
• Combine with URL sharing -- the URL also captures filter state for one-time sharing
• Use saved views instead of bookmarking URLs, since saved views update if column defaults change

Related DocumentationCopy Anchor Link

• Searching and Filtering CIs - Building the queries that saved views capture
• Change History - Saving views on the change history page