omverse-ui for Enterprise

Overview

Filtering records keeps focus on what matters now while preserving a full audit trail of active criteria.

A strong filtering pattern reduces cognitive load by making query intent explicit and reversible.

Filter operational work

Live preview

Try searching, combining filters, restoring a saved view, sorting the table, and recovering from an empty result.

Filtered work items
			Updated
Incident follow-upWK-1044	Security	In review	Yesterday
Platform migration checklistWK-1046	Platform	Open	1 hr ago
Quarterly access reviewWK-1048	Security	Open	8 min ago
Renewal approvalWK-1045	Finance	Closed	2 hrs ago
Vendor risk assessmentWK-1047	Finance	In review	24 min ago
Workspace provisioningWK-1043	Platform	Closed	Yesterday

Try changing status and team filters. Every criterion stays visible and reversible.

Anatomy

Use each piece in this order to keep interpretation and automation consistent.

Status: OpenTeam: Platform

24 recordsUpdated just now

12345

1
Filter source
Defines searchable fields, available operators, and domain rules.
2
Condition builder
Collects field, operator, and value as one explicit clause.
3
Active chip stack
Displays current constraints with one-click clear actions.
4
Result summary
Shows matching count and explains why an empty result occurred.
5
Reset command
Returns users to a known base state and removes uncertainty.

The ordering here is not visual-only; it reflects interaction priority and expected user cognition. Keep this order unless policy demands a specific domain exception.

When to use

Use this pattern when the user needs guided consistency, state, and reuse at scale.

When not to use

Avoid forcing this pattern where simpler, direct interactions are sufficient.

Avoid

Very small collections
Use a plain list or card stack when count is always tiny.
Purely navigational sorting
Use tabs or segmented controls for fixed views.
One-off toggles
Avoid full filtering pattern for single boolean controls.

Variants

A small number of variants helps teams choose correctly without adding complexity.

Inline bar

Compact controls next to the collection header for fast query edits.

Side panel

Deep filter configuration without crowding a data-dense workspace.

Smart panel

Progressive filters with recency-based shortcuts and presets.

States

States communicate readiness, risk, and expected user behavior.

State	Trigger	Visual response	Interaction
Default	No criteria selected	Empty active stack and neutral count	Users can add the first condition.
Filtering	Typing or changing criteria	Live result counter or in-progress indicator	Input updates are reflected with debounce safeguards.
No results	All records filtered out	Zero-result UI with alternate actions	People can reset and receive guidance.
Saved query	User saves a configuration	Named query indicator and quick re-open button	Future sessions can restore view quickly.

Behavior

Behavior should remain predictable across devices, permissions, and async edges.

Incremental querying

Debounce expensive remote calls while preserving immediate local feedback.

Deterministic reset

Clear applies defaults defined by role and permissions.

Permission-aware fields

Render only criteria available to the current access profile.

Accessibility

Keep interaction clarity high and ensure assistive technologies get the same meaning.

Key	Action
`AltF`	Move focus to the first filter control.
`Tab`	Progress through all filter controls in a consistent sequence.
`Esc`	Close advanced filter overlays without applying changes.

Announce active criteria counts when filters change.
Ensure each filter input has a visible label and error messaging.
Avoid color-only communication in status chips.

Content guidelines

Consistency is achieved by language standards, not by design only.

Field names

Use the same terms as your domain model.

ExampleWorkspace status

Operator clarity

Prefer natural language operators and visible scope.

ExampleStatus is Active

Reset affordance

Place one clear global clear action near filters.

ExampleClear all filters

Examples

Reference implementation style, payloads, and practical behavior.

Compose the pattern

Keep query state in the application so the URL, saved views, and data request can share it.
Let FilterBar announce the result count and DataTable preserve semantic table behavior.
Use the same reset function for active chips, empty-state recovery, and saved-view changes.

WorkItemsView.tsx

tsx

1import { DataTable, FilterBar, Select } from 'omverse-ui'
2 
3export function WorkItemsView() {
const [query, setQuery] = useState('')
const [status, setStatus] = useState('')
const results = filterWorkItems(workItems, { query, status })
7 
return (
  <>
    <FilterBar
      searchValue={query}
      onSearchChange={setQuery}
      searchLabel="Search work items"
      filters={[{
        id: 'status',
        label: 'Status',
        activeLabel: status || undefined,
        onClear: () => setStatus(''),
        control: <Select value={status} options={statusOptions} onChange={setStatus} />,
      }]}
      resultCount={results.length}
      onReset={() => { setQuery(''); setStatus('') }}
    />
    <DataTable columns={columns} data={results} getRowId={(row) => row.id}
      caption="Filtered work items" emptyState="No work items match these filters." />
  </>
)
28}

Persist a query contract

Store readable field, operator, and value clauses rather than component-specific state.
Validate restored fields against the current user’s permissions before applying them.
Version persisted query contracts when operators or domain fields change.

saved-view.json

json

1{
"filters": [
  { "field": "status", "operator": "equals", "value": "open" },
  { "field": "ownerTeam", "operator": "in", "value": ["sales", "customer-success"] }
],
"pageSize": 25,
"sort": { "field": "updatedAt", "order": "desc" }
8}

Open linked component reference for implementation patterns

Props / API

Use these API entries as a baseline contract and validate them against your domain layer.

These names are implementation-oriented and should map to your local contracts.

Props

PropTypeDefaultDescription

initialFilterFilterState() => undefinedHydrates initial query model.

querySchemaFilterSchemarequiredControlled definition of fields and operators.

onChange(next: FilterState) => voidundefinedCalled on each accepted filter mutation.

persistKeystringundefinedStorage key for restoring user preference.

Overview

Filtering records keeps focus on what matters now while preserving a full audit trail of active criteria.

A strong filtering pattern reduces cognitive load by making query intent explicit and reversible.

Filter operational work

Live preview

Try searching, combining filters, restoring a saved view, sorting the table, and recovering from an empty result.

Filtered work items
			Updated
Incident follow-upWK-1044	Security	In review	Yesterday
Platform migration checklistWK-1046	Platform	Open	1 hr ago
Quarterly access reviewWK-1048	Security	Open	8 min ago
Renewal approvalWK-1045	Finance	Closed	2 hrs ago
Vendor risk assessmentWK-1047	Finance	In review	24 min ago
Workspace provisioningWK-1043	Platform	Closed	Yesterday

Try changing status and team filters. Every criterion stays visible and reversible.

Anatomy

Use each piece in this order to keep interpretation and automation consistent.

Status: OpenTeam: Platform

24 recordsUpdated just now

12345

1
Filter source
Defines searchable fields, available operators, and domain rules.
2
Condition builder
Collects field, operator, and value as one explicit clause.
3
Active chip stack
Displays current constraints with one-click clear actions.
4
Result summary
Shows matching count and explains why an empty result occurred.
5
Reset command
Returns users to a known base state and removes uncertainty.

The ordering here is not visual-only; it reflects interaction priority and expected user cognition. Keep this order unless policy demands a specific domain exception.

When to use

Use this pattern when the user needs guided consistency, state, and reuse at scale.

When not to use

Avoid forcing this pattern where simpler, direct interactions are sufficient.

Avoid

Very small collections
Use a plain list or card stack when count is always tiny.
Purely navigational sorting
Use tabs or segmented controls for fixed views.
One-off toggles
Avoid full filtering pattern for single boolean controls.

Variants

A small number of variants helps teams choose correctly without adding complexity.

Inline bar

Compact controls next to the collection header for fast query edits.

Side panel

Deep filter configuration without crowding a data-dense workspace.

Smart panel

Progressive filters with recency-based shortcuts and presets.

States

States communicate readiness, risk, and expected user behavior.

State	Trigger	Visual response	Interaction
Default	No criteria selected	Empty active stack and neutral count	Users can add the first condition.
Filtering	Typing or changing criteria	Live result counter or in-progress indicator	Input updates are reflected with debounce safeguards.
No results	All records filtered out	Zero-result UI with alternate actions	People can reset and receive guidance.
Saved query	User saves a configuration	Named query indicator and quick re-open button	Future sessions can restore view quickly.

Behavior

Behavior should remain predictable across devices, permissions, and async edges.

Incremental querying

Debounce expensive remote calls while preserving immediate local feedback.

Deterministic reset

Clear applies defaults defined by role and permissions.

Permission-aware fields

Render only criteria available to the current access profile.

Accessibility

Keep interaction clarity high and ensure assistive technologies get the same meaning.

Key	Action
`AltF`	Move focus to the first filter control.
`Tab`	Progress through all filter controls in a consistent sequence.
`Esc`	Close advanced filter overlays without applying changes.

Announce active criteria counts when filters change.
Ensure each filter input has a visible label and error messaging.
Avoid color-only communication in status chips.

Content guidelines

Consistency is achieved by language standards, not by design only.

Field names

Use the same terms as your domain model.

ExampleWorkspace status

Operator clarity

Prefer natural language operators and visible scope.

ExampleStatus is Active

Reset affordance

Place one clear global clear action near filters.

ExampleClear all filters

Examples

Reference implementation style, payloads, and practical behavior.

Compose the pattern

Keep query state in the application so the URL, saved views, and data request can share it.
Let FilterBar announce the result count and DataTable preserve semantic table behavior.
Use the same reset function for active chips, empty-state recovery, and saved-view changes.

WorkItemsView.tsx

tsx

1import { DataTable, FilterBar, Select } from 'omverse-ui'
2 
3export function WorkItemsView() {
const [query, setQuery] = useState('')
const [status, setStatus] = useState('')
const results = filterWorkItems(workItems, { query, status })
7 
return (
  <>
    <FilterBar
      searchValue={query}
      onSearchChange={setQuery}
      searchLabel="Search work items"
      filters={[{
        id: 'status',
        label: 'Status',
        activeLabel: status || undefined,
        onClear: () => setStatus(''),
        control: <Select value={status} options={statusOptions} onChange={setStatus} />,
      }]}
      resultCount={results.length}
      onReset={() => { setQuery(''); setStatus('') }}
    />
    <DataTable columns={columns} data={results} getRowId={(row) => row.id}
      caption="Filtered work items" emptyState="No work items match these filters." />
  </>
)
28}

Persist a query contract

Store readable field, operator, and value clauses rather than component-specific state.
Validate restored fields against the current user’s permissions before applying them.
Version persisted query contracts when operators or domain fields change.

saved-view.json

json

1{
"filters": [
  { "field": "status", "operator": "equals", "value": "open" },
  { "field": "ownerTeam", "operator": "in", "value": ["sales", "customer-success"] }
],
"pageSize": 25,
"sort": { "field": "updatedAt", "order": "desc" }
8}

Open linked component reference for implementation patterns

Props / API

Use these API entries as a baseline contract and validate them against your domain layer.

These names are implementation-oriented and should map to your local contracts.

Props

PropTypeDefaultDescription

initialFilterFilterState() => undefinedHydrates initial query model.

querySchemaFilterSchemarequiredControlled definition of fields and operators.

onChange(next: FilterState) => voidundefinedCalled on each accepted filter mutation.

persistKeystringundefinedStorage key for restoring user preference.

Overview

Filtering records keeps focus on what matters now while preserving a full audit trail of active criteria.

A strong filtering pattern reduces cognitive load by making query intent explicit and reversible.

Filter operational work

Live preview

Try searching, combining filters, restoring a saved view, sorting the table, and recovering from an empty result.

Filtered work items
			Updated
Incident follow-upWK-1044	Security	In review	Yesterday
Platform migration checklistWK-1046	Platform	Open	1 hr ago
Quarterly access reviewWK-1048	Security	Open	8 min ago
Renewal approvalWK-1045	Finance	Closed	2 hrs ago
Vendor risk assessmentWK-1047	Finance	In review	24 min ago
Workspace provisioningWK-1043	Platform	Closed	Yesterday

Try changing status and team filters. Every criterion stays visible and reversible.

Anatomy

Use each piece in this order to keep interpretation and automation consistent.

Status: OpenTeam: Platform

24 recordsUpdated just now

12345

1
Filter source
Defines searchable fields, available operators, and domain rules.
2
Condition builder
Collects field, operator, and value as one explicit clause.
3
Active chip stack
Displays current constraints with one-click clear actions.
4
Result summary
Shows matching count and explains why an empty result occurred.
5
Reset command
Returns users to a known base state and removes uncertainty.

The ordering here is not visual-only; it reflects interaction priority and expected user cognition. Keep this order unless policy demands a specific domain exception.

When to use

Use this pattern when the user needs guided consistency, state, and reuse at scale.

When not to use

Avoid forcing this pattern where simpler, direct interactions are sufficient.

Avoid

Very small collections
Use a plain list or card stack when count is always tiny.
Purely navigational sorting
Use tabs or segmented controls for fixed views.
One-off toggles
Avoid full filtering pattern for single boolean controls.

Variants

A small number of variants helps teams choose correctly without adding complexity.

Inline bar

Compact controls next to the collection header for fast query edits.

Side panel

Deep filter configuration without crowding a data-dense workspace.

Smart panel

Progressive filters with recency-based shortcuts and presets.

States

States communicate readiness, risk, and expected user behavior.

State	Trigger	Visual response	Interaction
Default	No criteria selected	Empty active stack and neutral count	Users can add the first condition.
Filtering	Typing or changing criteria	Live result counter or in-progress indicator	Input updates are reflected with debounce safeguards.
No results	All records filtered out	Zero-result UI with alternate actions	People can reset and receive guidance.
Saved query	User saves a configuration	Named query indicator and quick re-open button	Future sessions can restore view quickly.

Behavior

Behavior should remain predictable across devices, permissions, and async edges.

Incremental querying

Debounce expensive remote calls while preserving immediate local feedback.

Deterministic reset

Clear applies defaults defined by role and permissions.

Permission-aware fields

Render only criteria available to the current access profile.

Accessibility

Keep interaction clarity high and ensure assistive technologies get the same meaning.

Key	Action
`AltF`	Move focus to the first filter control.
`Tab`	Progress through all filter controls in a consistent sequence.
`Esc`	Close advanced filter overlays without applying changes.

Announce active criteria counts when filters change.
Ensure each filter input has a visible label and error messaging.
Avoid color-only communication in status chips.

Content guidelines

Consistency is achieved by language standards, not by design only.

Field names

Use the same terms as your domain model.

ExampleWorkspace status

Operator clarity

Prefer natural language operators and visible scope.

ExampleStatus is Active

Reset affordance

Place one clear global clear action near filters.

ExampleClear all filters

Examples

Reference implementation style, payloads, and practical behavior.

Compose the pattern

Keep query state in the application so the URL, saved views, and data request can share it.
Let FilterBar announce the result count and DataTable preserve semantic table behavior.
Use the same reset function for active chips, empty-state recovery, and saved-view changes.

WorkItemsView.tsx

tsx

1import { DataTable, FilterBar, Select } from 'omverse-ui'
2 
3export function WorkItemsView() {
const [query, setQuery] = useState('')
const [status, setStatus] = useState('')
const results = filterWorkItems(workItems, { query, status })
7 
return (
  <>
    <FilterBar
      searchValue={query}
      onSearchChange={setQuery}
      searchLabel="Search work items"
      filters={[{
        id: 'status',
        label: 'Status',
        activeLabel: status || undefined,
        onClear: () => setStatus(''),
        control: <Select value={status} options={statusOptions} onChange={setStatus} />,
      }]}
      resultCount={results.length}
      onReset={() => { setQuery(''); setStatus('') }}
    />
    <DataTable columns={columns} data={results} getRowId={(row) => row.id}
      caption="Filtered work items" emptyState="No work items match these filters." />
  </>
)
28}

Persist a query contract

Store readable field, operator, and value clauses rather than component-specific state.
Validate restored fields against the current user’s permissions before applying them.
Version persisted query contracts when operators or domain fields change.

saved-view.json

json

1{
"filters": [
  { "field": "status", "operator": "equals", "value": "open" },
  { "field": "ownerTeam", "operator": "in", "value": ["sales", "customer-success"] }
],
"pageSize": 25,
"sort": { "field": "updatedAt", "order": "desc" }
8}

Open linked component reference for implementation patterns

Props / API

Use these API entries as a baseline contract and validate them against your domain layer.

These names are implementation-oriented and should map to your local contracts.

Props

PropTypeDefaultDescription

initialFilterFilterState() => undefinedHydrates initial query model.

querySchemaFilterSchemarequiredControlled definition of fields and operators.

onChange(next: FilterState) => voidundefinedCalled on each accepted filter mutation.

persistKeystringundefinedStorage key for restoring user preference.

Filtering records

Work items

Recommended

Avoid

Inline bar

Side panel

Smart panel

Incremental querying

Deterministic reset

Permission-aware fields

Field names

Operator clarity

Reset affordance

Compose the pattern

Persist a query contract

Filtering records

Work items

Recommended

Avoid

Inline bar

Side panel

Smart panel

Incremental querying

Deterministic reset

Permission-aware fields

Field names

Operator clarity

Reset affordance

Compose the pattern

Persist a query contract

Filtering records

Work items

Recommended

Avoid

Inline bar

Side panel

Smart panel

Incremental querying

Deterministic reset

Permission-aware fields

Field names

Operator clarity

Reset affordance

Compose the pattern

Persist a query contract