Object types
The kinds of real-world things Vavan models — accounts, contacts, products, orders, sites, drivers, routes, signals, and more.
An object type is a kind of real-world thing the platform knows about. Every object type is defined by four things: a name, a set of properties (its typed fields), a set of links to other object types, and the action types that are allowed to change it. Together those four make an object type a complete, self-describing model of one part of your business.
Instances vs. types
It is worth being precise about the distinction:
-
An object type is the definition — for example,
Account. It says what every account has (properties), how accounts connect to other things (links), and what can be done to them (actions). -
An object instance is a concrete record of that type — for
example, a specific customer. There are many instances of the
Accounttype, all sharing the same shape.
Most of the time the data you work with is instances; Vavan Core is the layer of types that gives those instances consistent structure and meaning.
Defined as configuration
Object types are not hardcoded per app. They are defined as configuration in Vavan Core, so the catalog of types — and the properties and links on each — can be extended without rewriting application code. An organization's production Core typically spans on the order of dozens of object types and hundreds of properties, and grows as more of the business is modeled.
Account is the same object whether you open it in the CRM, click
its site on Maps, or see it on a Dispatch route — there is one definition and
one record, not three copies.
Core object types
The table below lists representative object types found in most organizations. The exact catalog depends on which apps are in use and which systems are connected, but these are the common backbone.
| Object type | What it represents | Key links |
|---|---|---|
| Account (Entity) | A company you do business with — a customer, prospect, or partner. The canonical record for an organization. | Contacts, Orders, Sites, Signals, Tasks |
| Contact (Person) | A person at an account — a buyer, decision-maker, or operational contact. | Account, Tasks, Signals |
| Product | Something you sell or move — a SKU, grade, or service line in your catalog. | Line Items, Orders (via line items) |
| Order | A commitment to buy or supply — the header record for a transaction. | Account, Line Items, Shipment / Fulfillment Order |
| Line Item | A single priced row on an order, tying an order to a specific product and quantity. | Order, Product |
| Site / Location | A physical place tied to an account — a delivery address, yard, plant, or store. Carries geo coordinates. | Account, Stops |
| Driver | A person who operates a vehicle and executes routes. | Vehicle, Route |
| Vehicle | A truck or unit used to fulfill deliveries and service work. | Driver, Route |
| Route | An ordered plan of work for a driver across a shift — the container for stops. | Driver, Vehicle, Stops |
| Stop | A single visit on a route, pointing at the order to be served and the site to visit. | Route, Order, Site / Location |
| Shipment / Fulfillment Order | The fulfillment side of an order — what is being picked, moved, and delivered. | Order, Stop |
| Signal | A surfaced fact or condition worth acting on — a reorder window, churn risk, stalled deal, or disruption. | Account, Order, Task |
| Task | A unit of follow-up work, often the recommended next action created from a signal. | Account, Contact, Signal |
See Link types for the full set of relationships these object types share, and Properties for the typed fields on each.
Identity and deduplication
When data is normalized into Vavan Core from several systems, the same real company can arrive as several records — a Salesforce account, an ERP customer, a contact captured from email. Vavan resolves and merges these so that one real-world entity is represented by exactly one object.
Identity resolution matches incoming records against existing objects and
consolidates them, so links, signals, and history accumulate against a single
canonical record rather than fragmenting across duplicates. The practical
result: one company is one Account, no matter how many source
systems describe it.
What you can do with an object type
Object types are the nouns of the platform. To work with them:
- Read their properties — the typed fields, including derived and computed values.
- Traverse their link types to reach related objects.
- Change them only through governed action types, so every mutation is consistent and auditable.
For the bigger picture of how object types fit with the other building blocks, return to the Vavan Core overview.