Skip to main content

​
Overview

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

​
Custom Field Schema

Your agency maintains two separate schemas:

Contacts Schema

Custom fields that can be added to contact records

Companies Schema

Custom fields that can be added to company records

​
Standard Fields (Read-Only)

Each schema includes a set of built-in standard fields that cannot be removed: Contacts:
  • email — primary identifier
  • linkedin_url — used as a fallback identifier when email is unavailable
  • phone
  • first_name
  • last_name
  • company_id
  • origin — which platform the contact came from
  • contact_status
  • job_title
Companies:
  • domain — primary identifier
  • name
  • company_status
  • do_not_contact
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. These appear on every contact or company record across all client workspaces subject to the enforcement mode (see below).

​
Enforcement Mode

Schema Settings supports two enforcement modes that control how custom fields are handled when data arrives from integrations:

Flexible Mode

Default. Any custom field can be created, even if it isn’t in the master schema. Fields that don’t match the master schema are accepted as-is and remain client-specific — they aren’t automatically flagged or added to the schema. You can promote them into the master schema later from the Schema Settings page.

Strict Mode

Only fields that exist in the master schema are accepted. Any field not in the schema is rejected at ingestion time. Use this when you need tight data governance across all clients.

​
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 normalise fields before locking the schema down

​
Managing Non-Conforming Fields (Flexible Mode)

In flexible mode, when an integration sends a custom field that isn’t in the master schema, RevyOps doesn’t flag it or queue it for review — the field is accepted immediately and stays client-specific. There is no per-field triage workflow. Instead, the Schema Settings page gives you two ways to bring these fields into the master schema: Fields you don’t add to the master schema simply remain client-specific — there’s no separate action needed to “keep” them that way. To remove a field you’ve already added to the master schema, use the delete icon next to it in the custom fields table.

​
Real-Time Sync

Schema settings are stored in Firestore, and the Schema Settings page itself updates in real time — no deployment or restart required to see a change reflected in the UI. The backend that enforces Strict Mode on incoming data (integrations, webhooks, and API ingestion) reads schema settings through a cache with up to a 5-minute TTL. If you switch a client from Flexible to Strict, non-conforming fields sent by integrations can continue to be accepted for up to 5 minutes after you save the change.