Fields

Fields define your lead data model in LeadConduit. They specify what information you collect, how it's structured, and what types of data are valid. Think of fields as the columns in your lead database - each field represents a specific piece of information about a lead, from basic contact details to complex business-specific data.

Without a consistent data model, lead processing becomes chaos. Every vendor sends different field names, every system expects different formats, and data quality suffers. Fields solve this by:

• Standardizing Data - Common fields work the same way everywhere
• Enforcing Types - Each field knows what kind of data it holds
• Enabling Validation - Invalid data is caught and flagged
• Supporting Intelligence - Typed fields provide parsed components

LeadConduit provides two categories of fields:

Standard Fields

Pre-defined fields for common lead data:

A built-in standard field catalog provides consistent field names and normalized values across all flows and accounts dramatically reducing the operational cost of maintaining data integrations between parties.

We strongly encourage you to use a standard field instead of create a custom field.

Custom Fields

Fields created to address needs unique needs:

• Common lead information not availalbe as a standard field (let us know so we can add it to our catalog!)
• Proprietary or internal tracking information
• Lead seller specific tracking information

Custom fields are just as powerful as standard fields - they support all the same types and validation. Nevertheless, try to avoid using custom fields if you can. It will make technical setup and maintenance much easier.

Field Suffixes

Field suffixes are a namespacing mechanism that prevents data collision across accounts. When multiple accounts create custom fields, suffixes ensure uniqueness in naming.

Example scenario:

• Account A adds a field called "score"
• Account B also wants a field called "score"
• Their account suffixes are: accta and acctb
• The field IDs are score_accta and score_acctb
• If Account A wants to deliver a lead to Account B, a manual mapping must be added: score_accta -> score_acctb
• Account A must ensure that Account B's score field has the same meaning. Account A's score field might represent credit score, while Account B's score field might represent lead score.
• The suffix prevents automatic field mapping from making mistakes.

Suffix Naming Rules:

• 3-5 alphanumeric characters
• Lowercase only
• Must be unique across all entities
• Optional but recommended for entities with custom fieldsEvery custom is uniquely named across the platform.

The real power of fields comes from their types. Each field has a type that determines how data is parsed, validated, and enriched:

Example: Phone Field

Raw Input: "(555) 123-4567 ext 890"

Parsed Result:
- phone_1: "5551234567"
- phone_1.area: "555"
- phone_1.exchange: "123"
- phone_1.line: "4567"
- phone_1.extension: "890"
- phone_1.valid: true
- phone_1.mobile: false

Fields interact with several flow components:

1. Source Configuration

When configuring a source, you map vendor fields to your standard fields:

2. Validation Rules

Fields work with rules for validation:

• "lead.email is valid"
• "lead.phone_1 is not blank"
• "lead.loan_amount is between 5000 and 100000"

4. Recipient Mapping

When configuring an outboudn integration, fields map to downstram system requirements:

Fields exist in different namespaces depending on context. It's important to know that data collected during a lead flow does sits outside the lead.* namespace, which is reserved for data that's submitted by the source into the flow.

Appended data does not require a field in the flow. Instead, appended data is dynamic and "shaped" as it comes back from recipient step processing.

Choosing Fields

Do:

• Use standard fields when they fit your needs
• Create custom fields only when necessary
• Use descriptive names for custom fields
• Include units in field names when relevant (e.g., loan_amount_usd)

Don't:

• Duplicate standard fields with custom versions

• Use generic names like field1, custom1

• Store multiple values in one field

• Ignore field types - use the right type for your data

• Types - How fields parse and validate data

• Mappings - How fields transform between systems

• Rules - How fields are used in business logic

• Templates - How to access field values dynamically