- An approved data definition and business owner for the field or tag
- Admin access for changing the shared CRM data model
- Known list, import, automation, and reporting uses of the value
- Representative records for testing the change
Choose a tag or custom field
| Need | Use | Example |
|---|---|---|
| A reusable label that may have several values | Tag | Event attendee, Partner lead |
| One governed value with a defined meaning | Custom field | Contract renewal date, Customer tier |
| A standard WRKZY concept | Built-in field | Owner, lifecycle, company, consent |
| A fixed audience membership decision | Manual list | July pilot cohort |
| A changing audience rule | Smart list | Prospects inactive for 30 days |
Do not create a custom field that duplicates owner, lifecycle, source, company, or channel consent. Do not use tags to encode temporary tasks or private notes.
Put each customer fact in the structure that can govern it
- 01HubCustomer record
The durable identity shared by every workflow.
- 02EvidenceTimeline and consent
What happened and which communication is allowed.
- 03SignalConversation
The current customer exchange and channel state.
- 04RevenueDeal or quote
Commercial intent, value, and buyer decision history.
- 05OutcomeOwned next action
The named person, due point, and expected outcome.
Define before creating
For every tag or field, write down its purpose, owner, allowed values, update trigger, and retirement rule. Prefer controlled options when inconsistent spelling would break segmentation. Names should describe the customer fact—not the campaign that happens to use it today.
Apply data consistently
- Open the contact record or use reviewed bulk actions from Contacts.
- Add only tags that match their documented definition.
- Enter custom-field values in the expected format; leave unknown values blank.
- Reopen the contact and confirm the value appears in Details.
- If the field drives a smart list or automation, test both a matching and non-matching record.
Use fields in imports
The contact import can map existing custom fields and can turn an ignored source column into a text field. Create a field during import only when its definition and ownership are already agreed. Mapping one source column to more than one destination is blocked because it creates ambiguous data.
Change and retire safely
Before renaming, deleting, or replacing a tag or field, inventory its smart lists, campaign audiences, imports, views, and automation conditions. Migrate dependent records, test the replacement, then retire the old structure. Deleting first can silently change who qualifies for work.
Verify a schema change
Apply the tag or field to a marked test contact, reopen the contact in Details, and confirm the value appears in Contacts search or filtering. Test one matching and one non-matching smart-list or automation case before applying the structure broadly.
Diagnose bad data
If the same concept appears under several spellings, stop adding new variants. Select a canonical value, update affected records in reviewed batches, and repair dependent smart lists. If an import caused the issue, inspect Import history and the undo window before doing manual cleanup.
- Purpose and owner documented
- Built-in field does not already exist
- Values and format are unambiguous
- Dependent lists and automations tested
- Retirement plan exists before deletion