Start from the CRM, or build something else entirely
The tables that come with the product are a starting point, not the product. Rename them, put them away, take them out, or define something entirely different beside them: assets, inspections, tenancies, shipments, memberships, whatever your business has.
A table that did not exist a sentence ago.
Make a table for machines with a serial number, a client and a service date: the change is proposed line by line before anything happens. Then a column on contacts, the same way. Then the new table, empty and ready for its first row.
Four things you can do to any table
A veterinary practice handed Opportunities it never asked for and cannot remove is being told what business it is in. So the product’s own tables behave exactly like the ones you define.
The only exceptions are the tables the product itself runs on: users, teams, business units, security roles. Those are marked administrative and left alone.
- Rename it: the new name follows into screens, search, the prompt and the error messages
- Put it away: it disappears from everywhere and every row stays exactly where it is
- Take it out: refused while it holds rows or while another table points at it
- Put it back: nothing was destroyed; the designer lists what you removed, with a button
Columns that do more than hold a value
- The ordinary ones
- Text, long text, number, currency, date, date and time, yes/no, email, phone, URL, each validated for what it claims to be.
- Choice
- An option set with its own values and colours. A board groups by one; a chart counts by one.
- Lookup
- A pointer at a row in another table. Deleting the target is refused while anything points at it.
- Autonumber
- A sequence with your own prefix and padding, issued on save and never reused.
- Formula
- Worked out from the other columns of the same row: margin from price and cost, days open from a date. Recomputed on read, never stale.
- Rollup
- Counts, sums, minimums and maximums over the rows pointing at this one. Open value on an account, machines on a site.
Say which column plays which part
A board needs to know which column is the stage, a chart which one it adds up, a calendar which one places the row in time, and an assignment which one holds the person.
Those are a table’s roles. Until you say, they are guessed from the column types: right for the first table you make, wrong the moment there are two choice columns. So you can name them, and "None" is a real answer that stops the guess rather than re-running it.
- A column that cannot play the part is refused with the reason
- A role can name a column you added to a table the product shipped
- The prompt can set it: "the owner of a job is the engineer"
- A probability role weighs a value against how likely it is
The structural things a real business app needs
Shape
- Tables you define, with your own names and columns
- One-to-many relationships, with the child rows on the parent record
- Many-to-many, where both ends hold many of the other
- Cascade rules that refuse a delete rather than quietly orphaning rows
- Unique constraints, and duplicate detection before a save
- A recycle bin that holds a deletion for thirty days
Behaviour
- A process a record moves through, with rules at each step
- A step that owes a value cannot be left until it has one
- Validation rules written in plain language: "a discount over 20% needs sign-off"
- Required, read-only and conditional columns
- Defaults, including ones worked out from another column
- Everything applies to the API too, because it is the same code
Governance
- Security roles with create, read, write, delete, assign and share
- Four depths: own, business unit, parent and child, the whole workspace
- Field security profiles that hide a column from a role
- Sharing one record with one person, without changing anybody’s role
- An audit trail of who changed what, and when
- Every schema change is proposed and confirmed, never silent
What building it sounds like
Each of these comes back as a proposal, written in your own table names, that you read before anything happens.
| A table, three columns and a relationship | |
| A rename that follows into every screen and message | |
| A formula column, recomputed on read | |
| A rollup on Accounts, counting Jobs | |
| A validation rule with the message people will see | |
| A table hidden everywhere, its rows untouched |
Try it against your own shape of business
The trial gives you seven days and five seats. Rename the tables, add your own, import a spreadsheet, and see whether the sentences you would type give you the screens you need.