Multi-View Rendering
If the data model is flexible — records plus typed field values — then nothing forces a Project to look like a table any more than it forces a Contact to look like a card. The same underlying records can be sliced, grouped, and rendered in whatever shape best suits the user looking at them. ClickUp and Monday proved the pattern; we apply it to a trades CRM.
The five view types
Every record type ships with at least one default view of each shape. Tenants and individual users save their own variants on top.
What a view actually is
A view is a row in the views table. It's nothing more than a saved configuration that the rendering layer reads to decide how to display the underlying records.
Mockup · Table view
The familiar spreadsheet, with sticky headers, click-to-edit cells, multi-select, and bulk operations. Best for bookkeepers paying invoices in batch or admins fixing a hundred records after an import.
Mockup · Kanban view
Same records, grouped by group_by = status. Each column is a status enum value; each card is one record. Dragging a card to a different column writes a set_field change for status. Best for dispatchers managing flow and sales pipelines.
Mockup · Gantt view
Time-blocked schedule, one row per resource (tech or crew), time on the X-axis. Bars are projects placed at their scheduled start through expected end. Dependencies (waiting on permit, waiting on materials) draw as arrows between bars.
Mockup · Card view
The most visual layout. Each record renders as a card with a hero image (job photo, signature, before/after) plus a few headline fields. Best for techs flipping through job sites in the field, or owners showing the work portfolio to a prospect.
Mockup · Knowledge view
The least obvious one, and possibly the most powerful. Records render as long-form documents with linked references to other records. Useful for tenant-defined SOPs, training material, customer-facing service playbooks, and after-action reports — turning the CRM into a wiki that's always tied to live data.
Every inspection starts with a chimney check. Walk the perimeter before climbing. Use the Standard Inspection Form to capture findings — its fields auto-populate into the customer's record. Reference the Material Identification Guide when in doubt about shingle type.
Records linked here are live. If the inspection form changes, this page reflects it without anyone editing the SOP. New techs onboard against this view; experienced techs reference it when they hit edge cases.
How saving and sharing works
Views are first-class records — they live in the same per-tenant D1 as everything else, they sync over the same protocol, and they obey the same RBAC rules. Three scopes determine who can see and edit each view:
Switching views is free
Because every view is just a different render of the same underlying records, switching from Table to Kanban to Gantt is instantaneous and stateless. There's no copy of data per view, no risk of one view being out of date relative to another, no separate permission model. The dispatcher's Kanban and the bookkeeper's Table are looking at the same database rows; they just see them through different lenses.
The same pattern applies to dashboards: an Owner who wants to see a kanban of overdue invoices grouped by aging bucket can do it. So can a bookkeeper who wants a gantt of upcoming AR commitments. The data model doesn't care; the rendering layer composes the right shape at request time.
This is the payoff of every earlier architecture decision. A flexible record model lets fields differ per tenant. Per-tenant D1s make queries fast. The sync protocol keeps everyone consistent. Teams + RBAC controls what each viewer is allowed to see. The view system is the last piece — the surface that turns it all into something a human actually looks at.
Industry-specific default views
Every industry template ships with views pre-configured. A roofer onboarding the system doesn't start from a blank canvas — they start with a working pipeline, a working schedule, and a working invoice board, and customize from there.
That's the architecture loop closed. A new tenant signs up, gets a per-tenant D1 with a pre-loaded schema and pre-loaded views, and is operational on day one. From there they customize — adding fields, building views, defining roles — without ever touching code, schema migrations, or vendor support.