Documentation
The CRM model
The object set is fixed. That is the constraint the whole product rests on: an agent writing into a fixed, well-named model produces something another agent can read, and a human can inspect. A schema an agent can invent produces a database only that agent understands.
The objects
| Company | An organization. Matched on a normalized domain, never on name similarity. |
| Contact | A person. Matched on a normalized email, never on name similarity. |
| Opportunity | A deal in a pipeline stage. Status is derived from the stage. |
| Interaction | A summary of something that happened, with its actor and assertion kind. |
| Task | A follow-up, optionally due and linked to records. |
| Pipeline and stage | Ordered stages with a kind: open, won, or lost. |
| Source | Where an assertion came from, when there is one. |
| Actor | Who or what made a change. One per credential. |
| Mutation and field change | The append-only record of every write and its diff. |
What you can configure
- Pipeline names and their ordered stages
- Stage labels, kind, and optional probability
- Fields of your own on company, contact, opportunity, and task
- Tags
- Relationship roles on known associations
- Lifecycle labels mapped to a canonical category
- Workspace display timezone and default currency
- Custom object types, with typed fields and declared relationships
- The month your financial year starts, so a quarter means your quarter
- Exchange rates, each with an effective date and where the figure came from
- Computed fields in two declared forms: arithmetic over two fields, or a rollup over a relationship you declared
What you cannot
These are deliberate limits, not missing features. Naming them saves you looking.
One more that is not on the list because it is behaviour rather than a setting. A company matches on its normalised domain and a person on their normalised email. A type you defined yourself matches on nothing until you DECLARE what sameness means for it: name one of its fields and how to normalise the value, and it then matches on exactly that. What no type does, canonical or your own, is match on a similar name.
- The canonical object set: a company is a company in every workspace
- Replacing core identifiers or timestamps
- Code fields or a formula language: an expression you supply is not something we will run
- A workflow engine
- Arbitrary graph edges between unknown objects
- Storage schemas of your own, or queries you write yourself
Standard fields are real columns
Not an attribute table, not a JSON blob. A company's name is a column called
name, which is why search, sorting, and constraints behave the way you expect
rather than the way a generic schema forces.