Skip to content
  • There are no suggestions because the search field is empty.

Statuses, tags, and custom fields

Configure statuses, tags, and custom fields in the Model Match CRM: default vs. list statuses, list tag vocabularies, field types, and object vs. list scope.

In this article:

  1. The three kinds of attributes
  2. Statuses
  3. Tags
  4. Custom fields
  5. Object scope vs. list scope
  6. Where attributes show up
  7. Frequently asked questions

The three kinds of attributes

Attributes are the information stored on your records — the column headers of your CRM. Beyond the built-in fields (name, company, location, contact info), there are three kinds you can shape yourself:

  • Statuses: where a record stands in your pipeline.
  • Tags: flexible colored labels.
  • Custom fields: typed fields for anything else you track.

Each behaves a little differently, and the differences are worth understanding before you build out a list.

Statuses

Every record has a status. Out of the box, the defaults are:

New → Contacted → Engaged → Won → Lost (plus an unset "—").

Statuses are edited inline: click the status badge in any table row or on the record profile and pick from the list.

The defaults work everywhere, but a list can define its own status picklist, with its own stages and colors. A "LO Recruiting" list might run New → Left VM → Meeting Set → Offer → Joined, while a "Branch Targets" list runs a completely different pipeline.

🛑 Status vocabulary follows list context. When you view a record inside a list with custom statuses, you see and set that list's statuses. Viewing the same record outside a list (or in a different list), you see that context's vocabulary instead. This is what lets one record move through different pipelines on different lists without conflict.

Tags

Tags are colored chips for the categorization that doesn't fit a pipeline: "Met at conference," "Referred by Dave," "High priority."

  • Tags are scoped per list — each list maintains its own tag vocabulary. Tags you create in one list won't appear as options in another.
  • Anyone with manage rights on the list can create tags inline from a record: open the tag picker and add the new tag on the spot.

There are no workspace-wide tags. If you need a label that applies across all People or all Companies everywhere, that's a job for a custom field (a multi-select works well).

Custom fields

Custom fields store anything the built-in fields don't. Each field has a type, and the editor, table column, and filter for the field all match its type:

  • Text — free-form notes-in-a-field
  • Number — team size targets, years in the industry
  • Currency — comp expectations, signing bonus budget
  • Date — license renewal, contract end date
  • Select — one choice from a picklist
  • Multi-select — several choices from a picklist
  • URL — portfolio or review links
  • Rating — quick 1-to-5 style scoring
  • Checkbox — yes/no flags
  • Status — an additional pipeline-style field
  • Tags — an additional tag-style field

Object scope vs. list scope

Every custom field lives at one of two scopes, chosen when you create it:

  • Object-scoped: applies to all People (or all Companies) across the workspace. Use this for information that's true of the record everywhere — "Years in industry," "Comp expectation."
  • List-scoped: applies only to members of one list. Use this for campaign-specific working data — "Outreach wave," "Fit score for this branch."

👍 A good rule of thumb: if the value would still matter after the record leaves the list, make it object-scoped. If it only makes sense inside this recruiting effort, keep it list-scoped and your other lists stay uncluttered.

Where attributes show up

Attributes aren't just profile rows — they're woven through the whole CRM:

  • Table columns: custom fields can be shown as columns in the People and Companies tables, resizable and reorderable like any other column.
  • Filters: every custom field automatically becomes a filter facet, with a control matching its type.
  • The record profile: statuses and tags sit in the details rail header; custom fields appear as editable rows, with the full set under "View all values."

This is what makes attributes worth setting up carefully: a well-chosen custom field is simultaneously a data point, a column, and a filter.

Frequently asked questions

Can I change the default statuses for the whole workspace?
Custom status picklists are defined per list. To run a custom pipeline, create it on the list where you work those records. Outside of lists, records use the default set.

A record shows different statuses in two lists. Is that a bug?
No — that's list context. Each list with custom statuses tracks the record through its own pipeline. Outside any list, you'll see the default vocabulary.

Can I use the same tag across two lists?
Tags are per-list, so you'd create the same tag name in each list. If you find yourself doing this often, consider an object-scoped custom field (multi-select) instead, or save the tag set as an attribute template for reuse on new lists.

Who can create tags and custom fields?
Creating tags inline requires manage rights on the list. List-scoped attributes are part of list management, handled by the list's Editors, owner, or a workspace admin.

Can I change a custom field's type after creating it?
Choose the type carefully at creation — the type drives the editor, column, and filter everywhere the field appears. If a field's type no longer fits, create a new field of the right type.