The 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.
01The business problem
An organisation arrives with a list. Six departments had been interviewed separately, and between them they 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. And 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, and it does so before anyone has established which of the 44 things the platform already does.
02Why 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 of those 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.
03The 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?
Four destinations, in ascending order of cost:
| 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 that 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.
04Configuration 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 — which is a far more defensible statement 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
_idsuffix, 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.
05Sequencing the response
Once every request has a verdict, the delivery order writes itself — and it deliberately front-loads everything that costs nothing.
- UnblockAnything where the customer is stuck today. Days, not weeks, and it buys goodwill for everything after.
- Show them what they already ownEvery Live verdict, demonstrated. Zero build. In the reference engagement this covered sixteen active features that had never been shown.
- Toggle and configureThe Toggle and Config verdicts. An admin session and some setup, subject to whatever internal sign-off the customer needs first.
- BuildOnly what survived the first three phases — scoped and quoted separately, because by now it is a much shorter list.
- Non-product follow-upsHanded 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.
06Limits & 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
Three categories showed up in the reference engagement, and each has an honest alternative:
| 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 that has to be considered 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.
07Verification
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.