Summary
Custom models let you define your own data models in Planhat, alongside the built-in ones (Company, End User, Conversation, et.c.).
They behave as first-class data: they have their own fields, associations to other models, permissions, previews and profiles, and they work with the rest of Planhat.
That includes Salesforce sync, joined tables, formula fields, and dashboards.
Use them to model the parts of your business the system models don't cover, such as regions, partners, tenants, and the relationships between them.
This is the starting point. Each part of custom models has its own article; this one explains how the pieces fit and links out to the detail.
Who is this article for?
Planhat builders and admins evaluating or setting up custom models for their team (for example, CS Ops).
Series
This article is part of a series on Custom Models:
Custom Models overview ⬅️ *You are here*
Creating and managing custom models · create a model, add fields, set permissions, previews, and profiles
Custom associations · associate records across models, *primary* associations, and many-to-many (junction models)
Salesforce integration for custom models · mirror a Salesforce object into a model
Joined tables · show an associated model's field as a column
Custom Models FAQ · common questions
Article Contents
Click below to jump to the relevant section:
What are custom models?
The building blocks
Benefits
Use cases
Status and limitations (beta)
Further reading
What are Custom Models?
Planhat includes a number of system models (Company, End User, Conversation, et.c.) that fit most customer-success data. However, many companies have processes or structures that are unique to them. Custom models let you mirror your internal logic and structure, instead of forcing everything into a one-size-fits-all schema.
A custom model behaves as first-class data. It has its own fields, associations to other models, role-based permissions, and previews and profiles, and it works with the rest of Planhat: Salesforce sync, joined table columns, formula fields, and dashboards.
Once a model exists, you work with its records the way you work with any system model: in tables, on profiles, in filters, and in reporting.
The Building Blocks
A custom model is made up of a few parts. Each has a dedicated article with the detail.
Building block | What it does | Learn more |
Models and fields | Define a model (label, slug, icon) and give it custom fields | |
Custom associations | Associate a record with a record on another model; primary associations join the path back to Company for permissions and orphan prevention | |
Junction models | Two association fields on one model: the pattern for many-to-many relationships, with per-relationship metadata | |
Custom keyables | Name your own unique key (like |
|
Salesforce sync | Mirror a Salesforce object into a custom model, mapping its keyable and associations | |
Joined tables | Show an associated ("parent") model's field as a column, or group by it | |
Formula fields | Aggregate and derive values across associations (for example, sum or count related records) |
|
API | Full CRUD over model definitions, custom fields, and records |
|
Benefits
Custom models let you shape Planhat around your data rather than the other way around. This means you:
Model the business as it actually is - represent regions, contracts, products, cases, and stakeholders, and the real (often many-to-many) relationships between them, instead of forcing them into fields on Company or End User.
Remove denormalised fields and sync automations - associations and joined columns replace fields copied across models, so there is less data drift and less to maintain.
Bring in Salesforce data directly - mirror a Salesforce object into a custom model, instead of routing it through a warehouse and a data team.
Report across relationships - joined columns and cross-model formulas give relational views and KPI roll-ups that system models alone couldn't express.
Use Cases
Some typical ways teams use custom models:
Mirror a Salesforce object - bring a specific Salesforce object into Planhat as a custom model, mapped by its keyable and associations.
Roll KPIs up a hierarchy - parent models that aggregate metrics from the records associated to them, for segment or management reporting, using formula fields.
Success plans - model Goals, Outcomes, and plans as associated models rather than free-text fields.
Nested cases and work items - typed, nested work-items with pooled dashboards across records.
Contract- or asset-centric modelling - organise around a Contract, Asset, or product line rather than the Account.
Many-to-many relationships - partners, deal contacts, stakeholder mapping, and workspace membership, modelled with junction models.
Clean data for AI and agents - well-structured, associated data for agents and MCP to work over.
Further Reading
To go deeper, start with one of these:
[Creating and managing custom models] - the core setup: models, fields, permissions, previews, and profiles.
[Custom associations] and [Junction models] - how to associate records, including many-to-many relationships.
[Salesforce integration for custom models] - mirror a Salesforce object into a model.