Before the workflow, agree what the field means.

Start with a disputed field

An automation can move quickly in the wrong direction when two colleagues give the same field different meanings. Consider an illustrative sponsorship pipeline: one person uses qualified to mean a relevant organisation, while another uses it to mean a confirmed budget and decision-maker. A rule triggered by that field will inherit the ambiguity. Before designing more workflow steps, select a few consequential fields and agree what they mean. This article proposes a field dictionary for business discussion. It does not describe a configured NUMU pipeline or claim that any CRM writes have been activated.

Write the definition in ordinary language

For each field, record a plain-language definition, the object it belongs to, a good example, a misleading example and the business decision it supports. Distinguish a company characteristic from a contact preference or a deal-specific fact. HubSpot describes properties as fields that store information on records, with default and custom properties serving different needs. Use that basic model to ask whether the information is attached to the correct record. A company's sector should not change simply because a particular deal concerns a different campaign theme; store that deal context separately when needed.

Choose values that preserve meaning

Choose the permitted values deliberately. An open text field allows nuance, but a workflow cannot safely assume that interested, warm and promising mean the same thing. A controlled list can improve consistency when its definitions are understood, yet it can also hide uncertainty if every record must fit a premature category. Include an honest unknown state where the process needs one. Keep unknown separate from no: a missing budget conversation is not evidence that the prospect has no budget. Add examples that show how a colleague should classify a borderline record without inventing information.

Name the owner of each change

Name who may create, update and resolve conflicts for each important field. Record which system supplies the value and whether a person can override an imported value. Where two systems can write to the same field, agree which source takes precedence and how exceptions will be reviewed. In HubSpot, the property's internal name is distinct from its visible label and cannot be edited after creation. Plan integration-facing names carefully before creating custom properties. Do not rename concepts casually just to make a dashboard look cleaner; preserve the connection between business meaning and the technical reference.

Test the dictionary against awkward records

Test the dictionary with awkward but synthetic records before connecting it to consequential actions. Include a company with several contacts, a contact linked to more than one opportunity, an unanswered question and an old value imported from a spreadsheet. Ask two colleagues to classify the same examples independently, then discuss where they disagree. Those disagreements reveal definitions requiring improvement. Test whether missing values stop the workflow, create a review task or follow an explicitly agreed branch. The exercise should help the team discover ambiguity before a real prospect receives an unsuitable response.

Treat a definition change as a change to the system

Keep the dictionary versioned and accessible to the people doing the work. A changed definition can affect reports, segmentation, integrations and earlier records, so assess those dependencies before adopting it. Record the change date, the reason and whether historical data needs a reviewed migration. Avoid silently rewriting history to fit a new dashboard. Review a small sample of records after implementation and collect staff questions. The value of a CRM dictionary is practical: the team can explain why a record holds a value, what action it permits and who must resolve uncertainty.