
An organization in the app — the Law Firm type adds a Law Firm Info card, and the People field lists its linked people.
Working in the app? See the Directory and contacts feature reference for people, organizations, and the Contacts tab.
How its data works
An organization is a set of fields configured per company. Every organization has a name, and every organization has a type. Types are configured per company, and you can create any number of them. Out of the box the directory ships with organization types like law firm and brokerage, but your company defines its own list. As with people, an organization has a baseline set of fields and the type adds type-specific fields on top — a law firm surfaces law-firm details, a brokerage brokerage details. Because an organization always has a type, it always shows that type’s specific fields.An organization’s type is required — every organization must have one, in the
app and in the data model alike. People are subtler: the app also makes you pick a
type (with Other as the catch-all), but the data model leaves it optional — a
typeless person can exist via the API. See Person.
What it connects to
Files, Notes & Contacts
In the app, an organization has a Notes tab only (no Files or Contacts tabs). The API is broader than the in-app tabs — see the overview.Technical reference
Technical reference
Where it lives. Organizations are top-level entities surfaced through the
Directory UI at
/directory/organization. Through the API they’re the
organization entity on the unified CRUD surface — see the Entities API
overview.Framework-required fields.Types and type-driven fields. Organization types are values in the per-company
“Organization Type” option set (part of the company’s configuration).
Type-specific fields are implemented as embedded objects revealed by display
conditions on the type (e.g. law-firm details shown when
type == "lawFirm").Type permissions. Person and Organization reuse the
company.fmv1_custom_object:* permission family.