Contacts, Smart Lists and Segments

The contact record is the single row that everything else in the platform points at. Conversations attach to it, appointments attach to it, opportunities attach to it, workflow runs happen to it, and payments and form submissions land on it. Get the contact model right and the rest of the build is straightforward; get it wrong and every workflow, segment and report inherits the mess.

Around that record sit three tools for organizing contacts. Custom fields hold facts: a service interest, a location, a renewal date, a referral source. Tags hold states and markers: a lead source, a campaign membership, a flag that something happened. Smart lists and segments are saved queries over those fields and tags, re-evaluated whenever you look at them, which is what you point campaigns and bulk actions at.

The distinction between fields and tags is the one that decides whether a build stays maintainable. A field answers a question with one current value, and overwrites cleanly. A tag is a sticky label that accumulates and is never removed unless something removes it. Operators who use tags for everything end up with contacts carrying forty tags, no idea which are current, and segments nobody trusts. Use a field when you want to know the current answer; use a tag when you want to know that something happened.

The record

• Standard fields: name, email, phone, address, timezone, owner, source, date added
• Communication status per channel: email subscribed, SMS opted in, do-not-contact flags
• Activity history: conversations, appointments, opportunities, tasks, notes, workflow runs, payments

Custom fields

• Field types including text, number, date, dropdown, multi-select, checkbox and URL
• Grouping fields into folders or sections so the record stays readable
• Which fields are shown on the record, which are filled by forms, and which are written by workflows or AI steps
• Required and default values where supported

Tags

• A controlled vocabulary with a naming convention, ideally prefixed by purpose such as source, status or campaign
• Which workflows add tags and, critically, which remove them

Smart lists and segments

• Conditions across fields, tags, dates, owner, pipeline position, appointment history and engagement
• Combining conditions with and, or and negation
• Saved views per team or per user, with the columns each role needs
• Using a saved segment as a campaign audience or a bulk-action target

Data hygiene

• Duplicate detection and merge behavior, and which field wins on merge
• Import mapping, including how existing contacts are matched and updated
• Bulk edit, bulk tag, bulk workflow enrollment and bulk delete
• Export and the permissions controlling who can do it

1. Before creating a single field, list the questions the client's team and the client's automation actually need answered about a contact. Build for those, not for everything that might one day be interesting.
2. Decide field versus tag for each item on that list using the current-answer test, and write the decision down so the next operator follows it.
3. Create the custom fields with the correct types. A date stored as text cannot be used for date-based triggers, and this is expensive to discover later.
4. Define the tag naming convention before anyone creates a tag, with a prefix per purpose, and treat it as the standard for the account.
5. Decide which workflow owns each field and each tag. Two workflows writing the same field in different ways is a bug you will not notice for months.
6. Set the source field or source tag strategy so every contact's origin is identifiable, and make every form, widget and import populate it.
7. Clean the data before importing it: deduplicate, normalize phone number format, fix obvious bad email addresses, and drop anything you have no basis to contact.
8. Run the import on a small sample first with the real field mapping, inspect the resulting records one by one, and only then import the rest.
9. Set consent and subscription status explicitly on import. Do not let an import silently opt a list into SMS.
10. Build the segments the team will use daily, name them for the job they do rather than the filter they contain, and share them with the right users.
11. Build the segments your automation needs separately, and keep them stable, because campaigns and workflows pointing at a segment will follow any change you make to it.
12. Test each segment by inspecting a handful of members and confirming each one belongs there. Segment conditions are easy to get subtly wrong.
13. Set up duplicate handling and agree the merge rules with the client, including which record's field values survive.
14. Document the field and tag dictionary for the client, and agree who is allowed to create new ones. Uncontrolled field and tag creation is how a clean account degrades.
15. Schedule a periodic hygiene review covering duplicates, stale fields, unused tags and segments nobody opens.

Contacts are the foundation layer. Forms and the AI agents write to it, Workflows read and write it, Campaigns target segments of it, Pipelines and Opportunities hang off it, and Reporting is only as good as the fields that feed it.

Source attribution end to end

Every form, widget and import writes a source value to the same field. Workflows branch on it, segments group by it, and reporting shows which channels produce booked appointments. None of that works unless the field is populated consistently at every entry point, which is a contact-model decision made before any campaign exists.

Service-line routing

A multi-service client stores the service interest in a dropdown field, written either by the form or by an AI classification step. Segments per service feed separate nurture campaigns, and workflows assign to the team that handles that service. One field replaces several parallel tag schemes.

Reactivation on a defensible audience

A dormant segment is defined as: no appointment in a defined period, still subscribed, not already in an active campaign, and not flagged do-not-contact. That definition is the difference between a reactivation campaign that performs and one that generates complaints. The segment is the product here, not the message.

• Tag sprawl is the characteristic disease of these builds. Dozens of overlapping, never-removed tags make every segment unreliable and nobody wants to be the one to delete them. Prevent it with a convention and a gatekeeper.
• Tags do not remove themselves. A tag applied to mark a state stays after the state ends unless a workflow removes it. This is why fields are better for anything with a current value.
• Wrong field types block automation. Dates as text, numbers as text and free text where a dropdown belonged all prevent triggers, comparisons and reliable segmentation.
• Duplicates fracture the history. Two records for one person split the conversation, the appointments and the opportunity, and both will receive your campaign. Handle matching on import, not afterwards.
• Phone and email normalization matters. Inconsistent country codes and formatting break both deduplication and delivery.
• Segments are live. Editing a segment changes who every campaign and bulk action pointed at it will reach. Treat automation segments as stable infrastructure and build throwaway segments separately.
• Negative conditions are easy to get wrong. A contact with no value in a field often does not match a not-equals condition the way you expect. Test with real records, not logic.
• Bulk actions are hard to undo. A bulk tag, bulk workflow enrollment or bulk delete at the wrong moment on the wrong segment is one of the few genuinely irreversible mistakes available. Check the count before you confirm.
• Imports can opt people in silently. Set subscription status deliberately on every import, and keep the evidence of consent somewhere you can produce it.
• Consent and privacy obligations attach to this record. Deletion requests, access requests and data minimization apply to contacts and custom fields. Collecting fields you have no use for is a liability, not an asset, particularly in regulated industries.
• Merges lose data. Field values from the losing record can be discarded. Know the merge rules before you merge at scale.
• Nobody maintains a field dictionary unless it is someone's job. Without one, a year later no operator knows what three similarly named fields mean or which workflows depend on them.