Schema Settings

​

Overview

Schema Settings let you manage a master custom field schema at the agency level, defining which custom fields are allowed on contacts, companies and opportunities across all workspaces under your agency. Schema Settings is the central place to standardize the data structure across workspaces, ensuring every workspace uses consistent field names, types, and conventions.

---

​

Custom Field Schema

Your agency maintains three separate schemas:

​

Standard Fields (Read-Only)

Each schema includes a set of built-in standard fields that cannot be removed: Contacts:

• email, linkedin_url and phone: each contact holds exactly one of the three
• first_name
• last_name
• job_title
• company_id
• origin: which platform the contact came from
• contact_status
• email_status: Valid, Invalid, Risky, Catchall, Unknown, Bounced or Unsubscribed

Companies:

• domain: primary identifier
• name
• company_status
• do_not_contact
• linkedin_url

Standard fields are shown in the schema view but cannot be edited or deleted.

​

Custom Fields

Below the standard fields, you can define any number of custom fields, which appear on every contact or company record across all workspaces subject to the enforcement mode (see below). Some fields only work as a set, such as the Fit fields. Deleting one of them shows a warning that names the others, because the rest stop working without it. Deleting a custom field from the master schema removes it from every active workspace in the agency, including its values on each workspace’s records, its field type, and any workspace’s own copy of the field. A delete can’t be undone. The confirmation says how many records have a value in the field and across how many workspaces. A field that a saved view still uses can’t be deleted until it is removed from that view; the dialog names the view. Fields that only the selected workspace has are listed below the master fields, with Workspace and the workspace’s name as their source. Their Delete field action removes the field from that workspace only.

​

Opportunity Fields

The Opportunities tab holds custom fields for deals. They work like contact and company fields: the master schema applies to every workspace, and a workspace can add fields of its own.

---

​

Enforcement Mode

Schema Settings supports two enforcement modes. They control what happens when a CSV import, an API call or an MCP tool sends a custom field that isn’t in the schema yet:

​

When to Use Strict Mode

Use strict mode when:

• You have a fixed data model and don’t want ad-hoc fields polluting records
• You’re feeding data downstream into a CRM or data warehouse with a defined schema
• Multiple team members are configuring integrations and you need guardrails

Use flexible mode when:

• You’re onboarding new clients and still discovering what fields they need
• You want to review and standardize fields before locking the schema down

---

​

Fields Created in Flexible Mode

In flexible mode, a field that isn’t defined yet, in the master schema or for that workspace, is created as a workspace-only field for the workspace that sent it, with no type, so any value is accepted. Nothing flags a misspelling. An API call that writes Persona when the master field is persona creates a new workspace-only field Persona, and persona keeps its old value on that record. Workspace-only fields appear in that workspace’s field list with their source, and stay workspace-specific until you promote them. See Promoting a Workspace Field to the Master Schema below.

---

​

Workspace Field Types

Custom fields, whether defined in the master schema or added directly by a workspace, can each have a type: Text, Number, Date, Dropdown (single select), or Dropdown (multi select). Dropdown types carry a list of available options. A field with no type set is treated as Text. A dropdown created by a Close sync adds new options as the sync brings them in. A dropdown you create in Schema Settings keeps the options you set. Workspace-level field types set by a Workspace admin are layered on top of the agency’s master schema types when the agency views that workspace’s data, so Agency admins see the workspace’s own typing without it overwriting the master schema.

---

​

Promoting a Workspace Field to the Master Schema

A workspace can end up with a custom field that isn’t in your agency’s master schema, added by its Workspace admin, or arriving through a CSV import, the API, or MCP. When you view that workspace from Schema Settings as an Agency admin, these workspace-only fields appear listed alongside the master schema, marked with their source (for example “Workspace · [workspace name]”). For each workspace-only field you can:

• Click Add to master schema on its row to promote it, adding the field to your agency’s master schema so every workspace can use it.

An Agency admin who signed Claude in with Agency custom fields can do the same through the MCP, and also change a master field’s type and dropdown options. See Agency custom fields tools. Workspace-only fields can’t be reordered by drag, and they aren’t included when you copy the schema as JSON, since they don’t belong to the master schema yet.

---

​

When Changes Take Effect

Schema changes show in every workspace as soon as you save, with nothing to redeploy or restart. API and MCP writes can take a few minutes to follow a change. In the first few minutes after you switch to Strict, an API call can still create a new field.