The ability to represent an entity as a CRM object does not establish that the CRM should run its operational lifecycle. Evaluate event history, transaction frequency, workflow rules, ownership, resilience and cross-system dependencies.
Model identity, state and events separately
A CRM partner encounters a supplier that sells equipment and maintains it after installation. The client wants to see the equipment owned or used by each customer, its current status and previous service visits. A custom "Equipment" object may appear obvious. But an object is only a record structure. The business also needs to decide who can change equipment status, what happens when a work order is opened, how replacement parts are reserved and whether technicians can work offline.
The analysis should separate three levels: identity (what is this asset?), state (what is true about it now?) and events (what happened, when and by whom?). Customer visibility may need all three, but the appropriate system of record for each may differ.
Six tests for choosing the authoritative system
| Test | Question | Why it changes the architecture |
|---|---|---|
| Lifecycle | Does the entity have states, transitions, exceptions and approvals? | A static linked record is different from a controlled operational workflow. |
| Event grain | Are histories tracked per visit, component, meter reading or line item? | CRM summary data may be enough for account management but not field execution. |
| Transaction intensity | How often do records change, and how many users update them? | Operational workloads create performance and governance requirements. |
| Decision rights | Who owns changes to status, scheduling or service entitlement? | System design must reflect real operational authority. |
| Integration | Which data must cross into finance, inventory or customer reporting? | The need may be a well-defined interface rather than a duplicate master record. |
| Failure mode | What must still work if one system or connection is unavailable? | Critical operations may need resilience beyond account-facing CRM access. |
Three possible system arrangements
CRM object: when the record mainly supports account-facing decisions and its workflow complexity is compatible with the CRM environment. A customer-specific installed-base record with a limited state model may fit this case, subject to the platform's actual capabilities and licence.
Operational system: when the record participates in scheduling, asset maintenance, inventory, job execution, compliance or other controlled transactions. CRM can receive a summary or key events without owning the operational lifecycle.
Hybrid: an operational system is authoritative for the work order or asset state, while CRM holds the customer relationship and relevant events. This requires explicit IDs, sync direction, data freshness rules and ownership of exceptions; otherwise two systems may appear to disagree about the same asset.
Validate operational requirements before platform features
HubSpot documents custom objects as a configurable data-model capability. Licence availability and limits must be checked for the client’s account at design time. Field-service software documents a different operational scope: assets, work orders, scheduling and execution. Neither type of system is assumed to be necessary from the scenario alone.
Prior to design, test how the client currently answers: “Which asset requires work next, who is authorised to schedule it, and where is that decision recorded?” The answer may expose an adequate system, a weak integration, a missing event capture process or a genuine application gap.
Stop condition: if a functioning operational system already handles the lifecycle and CRM users receive the information they need, there may be no justified development work.
Related: system coverage vs business-model coverage and an illustrative asset-service intervention candidate.
Product references: HubSpot: Create and edit custom objects; Microsoft Dynamics 365 Field Service documentation. Product availability and licensing can change; verify before making a client recommendation.
About these notes. ProperBizFix uses business-model and system-coverage analysis to identify questions worth testing with an existing client. Examples are illustrative unless expressly described otherwise. How the research works.