Decision Matrix

Status

  • document type: decision guide
  • use code and /platform/current-architecture to verify whether an entity already exists
  • rows marked future describe target architecture, not current runtime implementation
This page answers the practical question: “A new requirement appeared. What should we use first in onelink?”

Default Decision Order

Use this order every time:
  1. check whether an existing native entity already fits
  2. check whether notes, labels, custom attributes, settings, or Captain configuration are enough
  3. check whether a domain service, policy, workflow, or UI extension is enough
  4. add a new shared entity only if the lifecycle is stable across domains
  5. add a new domain-only entity only if the shared model is no longer semantically correct

Decision Table

RequirementUse firstLayerAvoid
Need a workspace / tenant boundaryAccountShared platformCreating a second internal workspace model
Need a person recordContactShared platform / shared CRM primitiveCreating separate patient/buyer/person core models too early
Need an organization or client companyCompanyShared platform / shared CRM primitiveCreating separate clinic/developer/customer company models too early
Need communication with a customerConversation + InboxShared platformCreating domain-specific messaging threads
Need internal notes about a personNoteShared platformCreating a second note/comment system first
Need lightweight classification or segmentationLabelShared platformUsing labels as the only canonical workflow state
Need flexible additional fields on contactsCustomAttributeDefinition + custom_attributes on ContactShared variability layerAdding many nullable columns immediately
Need flexible additional fields on conversationsCustomAttributeDefinition + custom_attributes on ConversationShared variability layerEncoding all variance in labels
Need assignment or grouped ownershipTeam and existing assignee/inbox modelShared platformInventing a new ownership model too early
Need reusable operator shortcutsMacroShared platformRebuilding the same flow in a separate custom module
Need event-driven automationAutomationRuleShared platformHand-coding tenant-specific callbacks everywhere
Need a connected external appIntegrations::App + Integrations::HookShared integration layerBuilding a domain-only integration framework first
Need an AI-callable external actionCaptain::CustomToolShared AI action layerTreating every AI tool as a full integration lifecycle
Need domain-aware AI knowledgeCaptain::Assistant + Captain::Document + scenarios/toolsShared AI layer with domain configBuilding separate AI systems per domain
Need shared pipeline-oriented sales/work entityfuture DealFuture shared CRMCreating separate deal/project/case clones immediately
Need actionable follow-up workfuture TaskFuture shared CRMFolding tasks into a generic overloaded record

Domain Decision Rules

Generic

Prefer:
  • shared primitives with broad tenant configuration
  • custom attributes
  • labels
  • Captain docs/tools for general business use

Healthcare

Prefer:
  • Account as workspace
  • Company for clinic/insurer/employer/partner
  • Contact for patient or person-level actor
  • custom attributes for healthcare fields
  • labels and notes for intake and operational state
  • Captain documents/scenarios/tools for medical guidance and workflows
Avoid:
  • creating Patient as a separate core entity before Contact is exhausted
  • creating Clinic as a separate core organization before Company is exhausted

Construction

Prefer:
  • Account as workspace
  • Company for developer/contractor/supplier/client org
  • Contact for buyer/manager/stakeholder
  • custom attributes for construction fields
  • labels and notes for qualification and project coordination
  • Captain documents/scenarios/tools for estimate/project support
Avoid:
  • creating BuyerContact or ProjectContact as separate core entities too early
  • creating parallel organization models before Company is exhausted

When To Add A New Shared Entity

Add a new shared platform entity only when all of the following are true:
  • the lifecycle is stable
  • the concept is needed in 2 or more domain profiles
  • it has meaningful relationships, ownership, reporting, or permissions
  • labels/custom attributes/notes are no longer sufficient
Examples:
  • Deal
  • Task
  • later Activity

When To Add A Domain-Only Entity

Add a domain-only entity only when all of the following are true:
  • the semantics are truly domain-specific
  • the lifecycle is not correctly represented by current shared entities
  • the domain behavior would otherwise distort the shared platform model
Examples that may become valid later:
  • healthcare appointment or treatment plan
  • construction estimate or project object

Hard Stops

Do not do these by default:
  • do not add a second workspace model
  • do not add a second person model before exhausting Contact
  • do not add a second organization model before exhausting Company
  • do not store critical workflow state only in labels
  • do not force custom attributes to replace core relationships
  • do not build a separate integration architecture for each domain
  • do not build a separate AI architecture for each domain