---
title: "How do we model something our CRM has no object for — inspections, permits, assets, health checks?"
blueprint: 003
slug: where-should-this-data-live
category: Data model
revised: 2026-09-02
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://coevera.webplanet.sk/blueprints/where-should-this-data-live.html
publisher: Coevera
customer_data: none
---

# How do we model something our CRM has no object for — inspections, permits, assets, health checks?

**Short answer.** Don't start by modelling. Start by sorting every requirement into one of **six
verdicts**: already **live** in the space · a feature that ships but is **toggled** off ·
achievable by **config** · a genuine **build** · a hard platform **limit** to reframe · or **not a
product problem** at all. Only the fourth is a data-modelling exercise.

When it *is* a build, the choice is between a **custom entity** — its own API endpoint, forms,
sequence numbering and record functionalities — **extra fields on an existing standard entity**, or
a **related child record**. The test is whether the thing has its own lifecycle and gets listed
independently.

## 01 · The business problem

An organisation arrives with a list. Six departments interviewed separately produced around **44
distinct requests** for things the CRM should do: track site inspections, hold permits against
assets, record who was invited to an event versus who actually turned up, surface suggestions to
account managers, run onboarding quizzes, report by region.

Every request arrived phrased as a solution rather than a problem — "we need a tile on the
dashboard", "we need a new module for permits" — because that is how people describe what they
want. The instinct on both sides of the table is to take the list at face value and start
designing objects for it.

That instinct is expensive in a specific way: it converts an analysis exercise into a development
quote, before anyone has established which of the 44 things the platform already does.

## 02 · Why the obvious approach fails

### A large share of requests are not builds

> **Of roughly 44 requests, 11 mapped to features that were present and licensed in the customer's
> own space and simply switched off.** Nine mapped directly to something in the meeting notes. No
> development, no schema, no modelling — an admin session.
>
> Quoting development for a switch is worse than wasted effort. It burns budget that should have
> gone to the real gaps, and when the customer later discovers the feature was there all along, it
> costs credibility that is hard to recover.

A Coevera space exposes this directly. The `application` collection holds roughly **107 feature and
integration records**, each carrying an active flag. It is the per-space feature switchboard, and
reading it takes minutes.

The AI capabilities are individually switchable rows and are commonly off, while a different set is
often already on and undemonstrated. In the reference engagement, eleven AI-related apps were off
while another sixteen features — including several integrations and the automation and reporting
agents — were already active and had never been shown to the customer.

### Clusters of requests often share one root gap

Taken individually, three of the 44 requests looked like three separate builds: report on event
invitees, report on who was actually met, and surface a suggestion based on attendance. All three
failed on the *same* missing relation — the event entity had no direct link to contacts at all. The
only existing path ran through an expense record, meaning you could only tell who attended if
somebody had expensed them.

One relation, built once, turned three requests into reportable data. Estimating them separately
would have tripled the quote and still produced three partial answers.

### Some things cannot be built at any price

A handful of requests targeted platform objects that are fixed in shape — an extension point that
simply does not exist. Promising those is the worst outcome of all, because the failure surfaces at
delivery rather than at scoping.

## 03 · The decision framework

Every requirement gets exactly one verdict before anyone estimates anything. The verdict determines
who owns it, which is what makes this useful rather than academic.

| Verdict | Meaning | Owner |
|---|---|---|
| **Live** | Active in the space today. The gap is awareness, not capability. | Enablement / training |
| **Toggle** | Ships with the product; the app is inactive in this space. | Administrator |
| **Config** | Achievable with automation, custom fields, reports or step checklists. | Solution architect / admin |
| **Build** | Net-new schema, relation or integration. | Architect + engineering |
| **Limit** | Hard platform boundary. Reframe onto something that exists. | Product |
| **Non-product** | Policy, commercial, or internal tooling wearing a CRM costume. | Account team |

### When the verdict is Build — where does it go?

| Destination | Use when | Cost |
|---|---|---|
| **A field on an existing entity** | The data describes that record and has no independent existence — a tier, a territory, a flag. | Cheapest. But every field is another row on a form every user sees. |
| **A sub-type of an existing entity** | You need the same lifecycle and queue but a different field set per variant. | Low. Covered in depth in Blueprint 001. |
| **A related child record** | There are many per parent — line items, inspection visits, readings. | Moderate. A parent lookup, and an inline grid on the parent's form. |
| **A new custom entity** | It has its own lifecycle, needs its own reference numbering, and gets listed and reported on in its own right. | Highest. Its own forms, permissions, and an entry in the create menu. |

The deciding question is short: **does this thing get listed, filtered and reported on
independently, and does it have a life of its own?** An inspection does — it has a date, an
inspector, an outcome, and you will want a list of overdue ones. A distributor tier does not; it is
an attribute of an account.

> **What a custom entity actually gives you**, and therefore what you are paying for: its own REST
> endpoint, its own editable forms per sub-type, sequence-based reference numbering, and opt-in
> record functionalities — activities, documents, notes and global search. If you need none of
> those, you probably do not need the entity.

## 04 · Configuration mechanics

### Reading the switchboard

Dump the space's feature records and split them by active state before scoping anything. Then map
each customer request to a row, and only call something a build once no row covers it.

### Corroborate a toggle against usage

A toggle being off is a weak finding on its own. Pair it with evidence of non-use and it becomes
strong: for AI fields, scan every field-descriptor collection for a non-null AI options block.
**Zero configured fields plus the app switched off means the feature has never been used** — far
more defensible than the toggle alone, and it tells you the request is genuinely unmet rather than
badly explained.

The duplicate-checker settings repay the same treatment. They carry an enabled flag, a similarity
level and the matched field IDs per entity — so a request to "turn on duplicate checking" is
frequently really "the existing rule matches on too few fields."

### Lookup fields — the mechanics that catch people

- **A lookup field is a multi-value relation, exchanged as an array of references** — not a scalar
  foreign key. A read returns an array of reference objects; an empty array means nothing is linked.
- **Writing an array replaces the links rather than adding to them.** Send the full intended set
  every time; an empty array clears the relation. This is the single most common way an integration
  silently unlinks records it meant to leave alone.
- **Custom field names are used verbatim**, with no `_id` suffix, even though system foreign keys do
  carry one.
- **Creating a lookup field requires a complete filter block** even when filtering is switched off —
  omitting it fails with a generic, unhelpful error.

> **The trap when you do create a custom entity.** Creating one automatically creates a default
> sub-type beneath it with the same name and an empty form. Add your own sub-types and users see one
> more entry in the create menu than you intended, and the extra one is a dead end. Host one of your
> sub-types on the auto-created default instead — see Blueprint 001.

## 05 · Sequencing the response

Once every request has a verdict, the delivery order writes itself — and it deliberately
front-loads everything that costs nothing.

1. **Unblock** — anything where the customer is stuck today. Days, not weeks, and it buys goodwill
   for everything after.
2. **Show them what they already own** — every *Live* verdict, demonstrated. Zero build. In the
   reference engagement this covered sixteen active features that had never been shown.
3. **Toggle and configure** — the *Toggle* and *Config* verdicts. An admin session and some setup,
   subject to whatever internal sign-off the customer needs first.
4. **Build** — only what survived the first three phases, scoped and quoted separately, because by
   now it is a much shorter list.
5. **Non-product follow-ups** — handed to whoever actually owns them, rather than quietly absorbed
   into the CRM scope.

Phases 1 and 2 are what change the conversation. A requirements exercise that opens by delivering a
quarter of the list at no cost earns the right to a serious discussion about the rest.

## 06 · Limits & trade-offs

### The caveat that undermines the whole quick-win story if you miss it

> **An app's active flag does not distinguish "an administrator can switch this on today" from
> "this is gated behind licensing."** For some rows it reflects entitlement rather than a simple
> switch.
>
> Confirm with product which items are genuinely admin-flippable *before* presenting them as free
> quick wins. The entire value of the toggle finding rests on that distinction, and getting it wrong
> turns a credibility win into a credibility loss.

### Hard limits — reframe rather than build

| Limit | Consequence | Reframe onto |
|---|---|---|
| Some platform objects are fixed-shape and accept no additional fields | Custom content cannot be surfaced through that feature | Report or dashboard tiles, or automation-generated tasks |
| Certain filters operate only on owner and organisational unit | Filtering that feature by region is not configurable | Reports and saved filters over the native location fields |
| No learning-management or quiz capability exists in the platform | Onboarding assessment cannot be promised as product | A services-delivered guide, or a third-party LMS from the integrations hub |

One more worth knowing before you design around it: **approval processes cannot target a custom
entity**, and the approval record itself takes no custom fields. If your new entity needs sign-off,
that shapes the design — the workaround is in Blueprint 001.

### The standing cost of a custom entity

Worth stating plainly, because it is usually left out of the estimate: every custom entity is
another form to maintain, another permission surface to get right, another entry in the create menu,
and another thing to consider every time the space is reconfigured. Entities are cheap to create and
expensive to own.

### Where this analysis cannot help

Requests captured from meeting notes carry ambiguity that no amount of platform knowledge resolves —
an unexplained abbreviation, an unclear product name, a reference to a person nobody can identify.
In the reference engagement four items could not be scoped for exactly this reason. Flag them as
open questions rather than guessing; a request you have misunderstood is more dangerous than one you
have not yet answered.

## 07 · Verification

The output of this exercise is a set of claims about what a platform can do, made to a customer who
will hold you to them. Each one needs backing before it is said out loud.

- **Every verdict traced to evidence.** A *Toggle* verdict cites the app row and its state. A
  *Config* verdict cites the mechanism that achieves it. A *Limit* verdict cites the absence — the
  fixed object shape, or no matching operation anywhere in the schema.
- **Toggles corroborated against configured usage**, not asserted from the flag alone.
- **Licensing confirmed with product** for every item that will be presented as a free switch.
- **Corrections recorded, not silently absorbed.** Several initial readings were wrong and were
  revised during the analysis; keeping that trail is what lets a reviewer check the reasoning rather
  than take the conclusion on trust.
- **Unresolvable items listed as open questions** with the reason they cannot be answered offline.
- **For anything that reached Build:** the destination justified against the four options in §3, and
  the rejected alternatives written down. A custom entity nobody can explain the need for gets
  created anyway, six months later, by someone who does not know it was already considered and
  declined.

**What would signal the analysis went wrong:** a build being quoted for something that later turns
out to be a switch; three separate estimates that share one root gap; a delivered custom entity
whose list view nobody opens.

---

Published by Coevera. Abstracted to the reusable pattern — no customer names, no client data, no
personal data.