Grouping your tables

Once you keep more than a handful of tables, they start to belong together: clients, policies, and carriers are all "the insurance side of the business." A domain is that grouping. You put related collections under one name, and from then on they're organized — and you can build a single table that reaches across all of them.

What you can build

• One view across your whole book — clients, their policies, and the carrier behind each, as one table instead of three.
• A renewals table that reaches — from a policy out to its client, and from that client to the account owner, all on the same row.
• A spreadsheet you can hand over — that same view exported as a file for someone outside the system.

Grouping, not containing

A domain organizes; it doesn't absorb. Your records stay exactly where they are, in the collection they've always been in. Grouping a table under a domain, moving it to another one, or removing it from the domain entirely never touches a single row. Deleting the domain doesn't delete anything either — the tables simply go back to being ungrouped.

Each table belongs to at most one domain, so there's never a question of where something lives. Anything you haven't grouped yet sits in an "Ungrouped" area, ready to be filed when you're ready.

Views that span your tables

The reason to group tables is what you can build on top of them: a view that follows the links between your collections and assembles one table out of several.

You start by choosing which collection the rows come from — one row per record in it. Then you add columns by walking outward through the links you've already set up between tables: from a policy to its client, from that client to their account owner, several steps out if that's what the question needs. The walk stays inside the domain, which is exactly what the grouping is for.

From there it behaves like any other table you'd expect:

• Filter the rows you're looking at — renewals before year end, one carrier, open items only. On screen the filter applies to the rows currently loaded; a spreadsheet export applies it to every row in the view.
• Sort by a field on the collection you started from.
• Hide and reorder columns until it reads the way you want.

Save it and it becomes a view anyone who can see the domain can open.

How you build one

Building a domain view is a working draft — the rest of the app saves as you go, and this is the deliberate exception. Nothing is stored until you say so.

You get two panes. On the left you pick the starting collection and tick the columns you want, following the relationships outward. On the right, the result fills in as you go — real rows from your real data, re-drawn on every change, so you can see whether the table you're describing is the table you meant. Half-built shapes are only ever visible to you.

When it looks right, Save. If it doesn't, Discard and you're back where you started. A view you haven't saved yet doesn't exist for anyone else.

Export a view as a spreadsheet

Any saved view exports to CSV, ready to open in Excel or Google Sheets. It's a snapshot: the view's filters, its columns, in its column order, as of the moment you asked. Nothing is scheduled and no file is kept in sync — ask again tomorrow and you get tomorrow's numbers. The file matches the saved view rather than your unsaved edits, so if you're mid-edit when you export you're asked which you meant. Anything you don't have access to comes out marked "No access" rather than as a value, the same way it appears on screen. Very large views won't export at all: past about ten thousand records the export stops and tells you instead of producing a partial file. That limit is measured against the total number of records in the collection you started from — filters don't lower it — so to export a book that big, start the view from a smaller collection, or split the collection first.

The download itself is the Export button on the view in the web app. Your assistant can tell you how big the export would be; the file comes from there.

Who sees what

Sharing a domain shares the way of looking — the grouping and its views. It does not share what's inside the member collections. Each collection's access is its own separate decision, made on that collection.

So a teammate you share a domain with sees the domain and can open its views, and within those views they see only the data they were already allowed to see. Everything else reads as "No access" — the row is there, the value isn't. The collection count on a domain works the same way: it counts the tables that person can actually see, not the ones you can.

Anyone who can see a domain can also make full use of its views — open them, build new ones, adjust them. Saving a way of looking at data you're already allowed to read isn't a privileged act, and a view changes nothing in the underlying tables.

Try it

Group our Clients, Policies, and Carriers tables into a domain called Insurance.

Then build the cross-table view:

In the Insurance domain, build a view starting from Policies with the client name and the carrier alongside each policy, filtered to the ones renewing before the end of the year.

Related

Domains group structured data, and who sees what — the domain and each collection separately — is controlled by sharing.