Cases and Structured Workflows

The old “Collections” story needs an update.

In the current product, everyday structured workflow work is usually exposed through Cases and related folder-backed records, not through a simple standalone /collections tab model.

What users actually work with

• Cases inside Explorer for active case queues and operator work
• folder-backed records with workflow state and structured metadata
• structured entity views such as Companies and Contacts
• advanced metadata and workflow builders on legacy or specialist routes such as /collections/$view

There is still a /collections route family in the app, but it is not the right mental model for ordinary user onboarding.

When this surface is the right tool

Use case and structured workflow views when you need:

• consistent fields across many records
• workflow stages, ownership, and operational status
• filtered review lists instead of raw folders alone
• process transparency over a large volume of similar work

Practical rule

If the user is doing everyday workflow execution, teach the Cases view and the owning folder context first.

If the user is designing metadata, subtype, or workflow definitions, then the older collections-style builder surfaces matter.

Guardrails

• do not teach /collections as the main entry point for all structured work
• do not forget that cases are folder-backed records with normal repository permissions
• keep schema and workflow changes owned by trained operators or admins