Overview

Types are the data standardization engine of LeadConduit. They transform the messy, inconsistent data that arrives from various sources into clean, structured, and predictable formats that systems can reliably process. Think of types as intelligent parsers that not only validate data but also extract meaningful components and metadata.

At their core, types solve three fundamental problems:

  1. Data Chaos: Lead data arrives in countless formats
  2. Validation Confusion: What makes data "valid" varies by context
  3. Component Extraction: Valuable data is often buried within strings

How Types Work

The Problems Types Solve

Format Chaos: Lead data comes from everywhere with different formats - phone numbers as "(512) 789-1111" vs "512-789-1111" vs "5127891111", states as "TX" vs "Texas" vs "tx". This creates chaos both inbound (accepting leads) and outbound (delivering to external systems).

Validation Dilemma: Traditional systems reject misformatted data, but in lead distribution you can't control input formats, rejecting leads means lost revenue, and different buyers have different requirements.

Hidden Value: Valuable data is embedded within strings (area codes, domains, ZIP codes, age from DOB) requiring complex string manipulation to extract.

How Types Solve These Problems

Parse-Normalize-Use Pattern: Every type follows three steps: Parse (accept various formats), Normalize (convert to consistent format), Use (access standardized data and components in flows).

Example: "(512) 789-1111" → { raw: "(512) 789-1111", normal: "5127891111", area: "512", exchange: "789", line: "1111", valid: true }

Normalization Benefits:

  • Simplified Rules: Write one rule for State equals "TX" instead of separate rules for "tx", "texas", "Texas", etc.
  • Effortless Outbound Delivery: Send normalized data to external systems often without format conversion
  • Consistent Storage: All data stored in predictable formats

Component Extraction: Types automatically extract valuable components without string manipulation:

  • Phone: Area code, exchange, line, extension, type, toll-free status
  • Email: User, domain, host, TLD, free/disposable detection
  • Postal Code: ZIP, country, regional components

Graceful Validation: The valid component marks data quality without stopping processing. Invalid data doesn't break flows - it's marked for you to handle as needed. Use Phone 1 > Valid is true in rules to filter based on data quality.

Raw Value Preservation: Every type preserves the original input as raw for audit trails, troubleshooting, and integration flexibility.

Privacy-Focused Analytics: Types support aggregation for reporting while excluding sensitive information (usernames from emails, line numbers from phones).

Quick Reference

Type Primary Use Key Components Common Field Examples
Phone Contact numbers area, exchange, line, type, is_tollfree Phone 1, Mobile Phone, Work Phone
Email Contact emails domain, user, host, is_free, is_disposable Email, Work Email, Co-Borrower Email
String General text none Comments, Description, Custom fields
Number Numeric data none Loan Amount, Income, Credit Score
Boolean Yes/no values none Opt In, Has Insurance, Accept Terms
Date Date values none Application Date, Move Date
DOB Birth dates (masked) age, year (processing only) DOB, Co-Borrower DOB
State US states/provinces name State, Property State
Postal Code ZIP/postal codes zip, country_code, fsa, outcode Postal Code, Property Postal Code
SSN Social Security (masked) first_three, middle_two, last_four (processing only) Social Security Number
First Name Given names none First Name, Co-Borrower First Name
Last Name Family names none Last Name, Co-Borrower Last Name
City City names none City, Property City
Street Street addresses number, name Address 1, Property Address
Gender Gender values abbr Gender, Applicant Gender
Range Numeric ranges min, max, mid, average Age Range, Income Range
Time Date/time values none Submission Time, Appointment Time
URL Web addresses protocol, host, path, query Landing Page URL, Referrer URL
Credential Passwords/keys (masked) none API Secret, Password
IP IP addresses is_ipv4, ipv6_format IP Address, Source IP
TrustedForm URL TrustedForm certificates certificate_id, type, is_web TrustedForm Certificate URL

Complete Type Catalog

Contact Types

Phone Type

Comprehensive phone number parsing and validation for US/Canada numbers with real-world verification.

Geographic Limitation: Currently only supports US and Canadian phone numbers. International numbers from other countries will be marked as invalid (valid: false) and will not parse correctly, even if they have a valid format in their home country.

Advanced Validation: The valid property indicates more than just format correctness - it verifies:

  • The area code is a real, assigned area code
  • The exchange is a real exchange within that area code
  • The area code and exchange legitimately belong together
  • The number follows valid North American Numbering Plan rules

This means a phone number like "(999) 555-1234" would be invalid even though the format is correct, because 999 is not a real area code.

What It Does NOT Verify: The validation does NOT check if:

  • The complete 10-digit number is actually connected/in service
  • The line (last 4 digits) is valid for that area code and exchange
  • The number can receive calls or texts

A number can pass type validation but still be disconnected or undeliverable.

Components:

  • Raw: Unmodified value
  • Area: Area code
  • Exchange: Exchange code
  • Line: Line number
  • Number: Full normalized number
  • Extension: Extension if present
  • Country Code: Two-letter country code
  • Country Calling Code: Numeric country calling code
  • Type: Number type (home/work/mobile)
  • Is Tollfree: Boolean for toll-free numbers

Type Hints: Append h (home), w (work), m (mobile), or c (cell) to set type

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in

Examples:

Valid US Numbers (real area codes and exchanges):
"(512) 789-1111" → area: "512", exchange: "789", line: "1111"
"512-789-1111" → "5127891111"
"512.789.1111" → "5127891111"

Invalid Despite Good Format (fake area code):
"(999) 555-1234" → valid: false (999 not a real area code)
"(123) 456-7890" → valid: false (123 not a real area code)

With Extensions:
"5127891111x123" → extension: "123"
"5127891111 x 43" → extension: "43"

Toll-Free:
"8775551212" → is_tollfree: true
"1-800-555-1212" → is_tollfree: true

With Type Hints:
"5127891111m" → type: "mobile"
"5127891111h" → type: "home"

Masked Numbers:
"1-(512) *** ****" → valid: true (masked)
"**********" → valid: true (fully masked)

International (will NOT parse correctly):
"+49 30 22610" → valid: false (not US/Canadian format)
"+44 1484 519892" → valid: false (not US/Canadian format)
Note: International numbers are not supported unless they coincidentally match US/Canadian patterns

Invalid inputs (valid=false):

  • "donkey kong" (not a number)
  • "964523331" (too short)
  • "(999) 555-1234" (invalid area code)
  • "(512) 999-1111" (invalid exchange for 512 area code)

Field Examples: Phone 1, Phone 2, Mobile Phone, Work Phone

Common Component Usage:

  • Check for specific area codes: Phone 1 > Area equals "512"
  • Identify toll-free numbers: Phone 1 > Is Tollfree is true
  • Format for display: {{Phone 1 > Area}}-{{Phone 1 > Exchange}}-{{Phone 1 > Line}}
  • Check validity: Phone 1 > Valid is true

Important Limitation: The valid property only confirms the area code and exchange are legitimate - it does NOT verify the full number is connected or deliverable. The "line" portion (last 4 digits) could still be invalid or disconnected. For true deliverability verification, use third-party Add-On services like Trestle, Telesign, or BriteVerify in a flow step to collect carrier-level metadata, then evaluate the appended data in a subsequent filter step to block disconnected numbers.

Email Type

Comprehensive email parsing with domain analysis and validation.

Components:

  • Raw: Unmodified value
  • User: Username (before @)
  • Domain: Full domain (after @)
  • Host: Domain without TLD
  • TLD: Top-level domain
  • Is Free: Boolean for free email providers
  • Is Disposable: Boolean for temporary emails

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in
  • matches pattern / does not match pattern

Examples:

Standard:
"user@domain.com" → user: "user", domain: "domain.com"
"John.Doe@Gmail.com" → "john.doe@gmail.com" (auto-lowercased)

Plus Addressing:
"user+tag@domain.com" → user: "user+tag"
"test+hola@domain.com" → valid: true

With Spaces:
"  user@domain.com  " → "user@domain.com" (trimmed)
"p. j. butter@gmail.com" → valid: true

Free Email Detection:
"user@gmail.com" → is_free: true
"user@yahoo.com" → is_free: true
"user@company.com" → is_free: false

Disposable Detection:
"user@mailinator.com" → is_disposable: true
"user@10minutemail.com" → is_disposable: true

Invalid inputs (valid=false): "Asdf" (no @), "hello@//gmail.xn--om.3ia"

Field Examples: Email, Work Email, Co-Borrower Email

Common Component Usage:

  • Check if email is from a specific domain: Email > Domain equals "company.com"
  • Identify free email providers: Email > Is Free is true
  • Extract username for display: {{Email > User}}

Personal Data Types

First Name Type

Simple string type for given names with basic validation.

Components:

  • Raw: Unmodified value

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • format is valid / format is invalid
  • matches pattern / does not match pattern

Examples:

"John" → "John"
"Mary-Jane" → "Mary-Jane"
"José" → "José"
"  Alice  " → "Alice"  // Whitespace trimmed

Field Examples: First Name, Co-Borrower First Name

Last Name Type

Simple string type for family names with basic validation.

Components:

  • Raw: Unmodified value

Operators: Same as First Name type

Examples:

"Smith" → "Smith"
"O'Brien" → "O'Brien"
"García-López" → "García-López"

Field Examples: Last Name, Co-Borrower Last Name

DOB Type (Date of Birth)

Special date type that adds age calculation and is maskable for privacy.

Components:

  • Raw: The full date (only accessible during processing)
  • Age: The age as of today (only accessible during processing)
  • Year: The year from the DOB (only accessible during processing)

Maskable: Yes

Operators: Same as Date type

Examples:

During processing:
"1990-01-15" → {
  raw: "1990-01-15",
  age: 34.9,
  year: 1990,
  valid: true
}

After processing (stored as): "****-**-**"
No components accessible - all values masked

Field Examples: DOB, Mortgage Co-Borrower DOB, Spouse DOB

Gender Type

Parses gender values with abbreviation support.

Valid Inputs:

  • Male: m, male, M, Male, MALE (case insensitive)
  • Female: f, female, F, Female, FEMALE (case insensitive)
  • Other: o, other, O, Other, OTHER (case insensitive)
  • With whitespace: " m " → male

Components:

  • Raw: Unmodified value
  • Abbreviation: Abbreviated form (M, F, O)

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • format is valid / format is invalid

Examples:

"male" → {               "f" → {
  normal: "male",           normal: "female",
  raw: "male",              raw: "f",
  abbr: "M",                abbr: "F",
  valid: true               valid: true
}                         }

"MALE" → "male"         "other" → abbr: "O"
"  m  " → "male"        "O" → "other"

Invalid inputs (valid=false): "50", "asdf", 5, true

Field Examples: Gender, Applicant Gender

SSN Type (Social Security Number)

US Social Security Number parsing with masking for privacy.

Components:

  • Raw: Unmodified value (only accessible during processing)
  • First Three: First three digits (only accessible during processing)
  • Middle Two: Middle two digits (only accessible during processing)
  • Last Four: Last four digits (only accessible during processing)

Maskable: Yes

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in

Examples:

During processing:
"123456789" → first_three: "123", middle_two: "45", last_four: "6789"
"123-45-6789" → "123456789" (dashes removed)
"123 45 6789" → "123456789" (spaces removed)
"123.45.6789" → "123456789" (dots removed)
"  123-45-6789  " → "123456789" (trimmed)
"donkey 123456789" → "123456789" (text ignored)

After processing (stored as): "*********"
No components accessible - all values masked

Invalid inputs (valid=false): "abcd", "", " "

Field Examples: Social Security Number

Common Component Usage (During Processing Only):

  • Check last four digits: Social Security Number > Last Four equals "1234"
  • Send to integration: {{Social Security Number > Last Four}}
  • Check if provided: Social Security Number > Valid is true

Note: After processing completes, these components are NOT available

Location Types

Street Type

Street address parsing with number and name extraction.

Components:

  • Raw: Unmodified value
  • Number: Street number
  • Name: Street name

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in
  • matches pattern / does not match pattern

Examples:

"123 Main Street" → number: "123", name: "Main Street"
"4203 Guadalupe St" → number: "4203", name: "Guadalupe St"
"  123 Main St  " → "123 Main St" (trimmed)

Invalid inputs (valid=false): "Main Street" (no number), "Asdf"

Field Examples: Address 1, Property Address

City Type

Simple string type for city names with no format validation.

Components:

  • Raw: Unmodified value

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in
  • matches pattern / does not match pattern

Examples:

"Austin" → "Austin"
"Dallas" → "Dallas"
"San Francisco" → "San Francisco"
"  Chicago  " → "Chicago"  // Whitespace trimmed

Field Examples: City, Property City, Employer City

State Type

US states and Canadian provinces with abbreviation normalization.

Components:

  • Raw: Unmodified value
  • Name: Full state/province name

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • includes / does not include
  • is included in / is not included in

Examples:

US States:
"TX" → name: "Texas"
"tx" → "TX" (auto-uppercased)
"Texas" → "TX"
"texas" → "TX"

Canadian Provinces:
"ON" → name: "Ontario"
"Quebec" → "QC", name: "Quebec"

Unknown Values (still valid=true):
"DX" → "DX" (unknown but preserved)
"Dexus" → "Dexus"
"DEXUS NEXUS" → "DEXUS NEXUS"

Field Examples: State, Property State, License State

Postal Code Type

Multi-country postal code parsing supporting US, Canada, and UK formats.

Components:

  • Raw: Unmodified value
  • Country Code: Country abbreviation
  • US Components:
    • ZIP: First 5 digits
    • Four: Last 4 digits (ZIP+4)
  • Canadian Components:
    • FSA: Forward sortation area
    • LDU: Local delivery unit
  • UK Components:
    • Outcode: Outward code
    • Incode: Inward code

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in
  • matches pattern / does not match pattern

Examples:

US Formats:
"78704" → zip: "78704"
"78704-1234" → zip: "78704", four: "1234"
"78704 1234" → "78704-1234"
"787041234" → "78704-1234" (9 digits)
"78704-" → "78704" (trailing dash removed)
"78704   - 1234" → "78704-1234" (extra spaces)

Canadian Formats:
"Q2E 4U7" → fsa: "Q2E", ldu: "4U7"
"q2e4u7" → "Q2E 4U7" (auto-formatted)
"q2e      4u7" → "Q2E 4U7" (extra spaces)

UK Formats (5 patterns):
"A1 1AA" → outcode: "A1", incode: "1AA"
"A11AA" → "A1 1AA" (space added)
"AA11 1AA" → valid UK format
"AA11A 1AA" → valid UK format

Invalid inputs (valid=false): "garbage", non-postal code strings

Field Examples: Postal Code, Property Postal Code

Common Component Usage:

  • Check ZIP code: Postal Code > ZIP equals "78751"
  • Identify country: Postal Code > Country Code equals "US"
  • Use only 5-digit ZIP for matching: {{Postal Code > ZIP}}

Data Types

Boolean Type

Parses boolean values from various string and numeric representations.

Valid Inputs:

  • True: y, yes, true, t, 1 (case insensitive)
  • False: n, no, false, f, 0 (case insensitive)
  • Numeric: 1 → true, 0 → false
  • With whitespace: " true " → true

Components: None

Operators:

  • is true / is not true
  • is false / is not false
  • is blank / is not blank
  • format is valid / format is invalid

Examples:

"yes" → true        "no" → false
"Y" → true          "N" → false  
"TRUE" → true       "FALSE" → false
"t" → true          "f" → false
1 → true             0 → false
"1" → true          "0" → false

Invalid inputs (return false with valid=false): "50", "asdf", {foo: 42}

Field Examples: Opt In, Accept Prepayment Penalty, Has Insurance

City Type

Simple string type for city names with no format validation.

Components:

  • Raw: Unmodified value

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in
  • matches pattern / does not match pattern

Examples:

"Austin" → "Austin"
"Dallas" → "Dallas"
"San Francisco" → "San Francisco"
"  Chicago  " → "Chicago"  // Whitespace trimmed

Field Examples: City, Property City, Employer City

Credential Type

Handles sensitive credential strings like passwords and API keys. Always masked by default.

Components: None

Maskable: Yes (sensitive data replaced with asterisks)

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • includes / does not include
  • is included in / is not included in

Examples:

During processing: "sekret-pazzward" → available for integrations
After processing (stored as): "****************"

During processing: "befa4e7379d81173dfe8d1a53deaf591" → available for integrations  
After processing (stored as): "********************************"

Field Examples: API Secret, Password, Authentication Token

Date Type

Parses dates in multiple formats and normalizes to ISO format (YYYY-MM-DD).

Supported Formats:

  • US: M/D/YYYY (6/2/2014), M/D/YY (6/2/14), MM-DD-YYYY (06-02-2014)
  • ISO: YYYY-MM-DD (2014-06-02)
  • European: D/M/YYYY (18/7/2014), D-M-YYYY (18-7-2014)
  • Compact: MMDDYYYY (06022014), YYYYMMDD (20140602)
  • Natural: Mon Jun 02 2014, Jun 02 2014, Fri 18 July 2014

Components:

  • Raw: Unmodified value

Operators:

  • is equal to / is not equal to
  • is less than / is less than or equal to
  • is greater than / is greater than or equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • is between / is not between

Examples:

"6/2/2014" → "2014-06-02"      "06/02/2014" → "2014-06-02"
"6/2/14" → "2014-06-02"        "June 2, 2014" → "2014-06-02"
"2014-06-02" → "2014-06-02"    "Mon Jun 02 2014" → "2014-06-02"
"06-02-2014" → "2014-06-02"    "06022014" → "2014-06-02"
"20140602" → "2014-06-02"      "18/07/2014" → "2014-07-18" (European)

Field Examples: Application Date, Move Date, Purchase Date

DOB Type (Date of Birth)

Special date type that adds age calculation and is maskable for privacy.

Components:

  • Raw: The full date (only accessible during processing)
  • Age: The age as of today (only accessible during processing)
  • Year: The year from the DOB (only accessible during processing)

Maskable: Yes

Operators: Same as Date type

Examples:

During processing:
"1990-01-15" → {
  raw: "1990-01-15",
  age: 34.9,
  year: 1990,
  valid: true
}

After processing (stored as): "****-**-**"
No components accessible - all values masked

Field Examples: DOB, Mortgage Co-Borrower DOB, Spouse DOB

Email Type

Comprehensive email parsing with domain analysis and validation.

Components:

  • Raw: Unmodified value
  • User: Username (before @)
  • Domain: Full domain (after @)
  • Host: Domain without TLD
  • TLD: Top-level domain
  • Is Free: Boolean for free email providers
  • Is Disposable: Boolean for temporary emails

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in
  • matches pattern / does not match pattern

Examples:

Standard:
"user@domain.com" → user: "user", domain: "domain.com"
"John.Doe@Gmail.com" → "john.doe@gmail.com" (auto-lowercased)

Plus Addressing:
"user+tag@domain.com" → user: "user+tag"
"test+hola@domain.com" → valid: true

With Spaces:
"  user@domain.com  " → "user@domain.com" (trimmed)
"p. j. butter@gmail.com" → valid: true

Free Email Detection:
"user@gmail.com" → is_free: true
"user@yahoo.com" → is_free: true
"user@company.com" → is_free: false

Disposable Detection:
"user@mailinator.com" → is_disposable: true
"user@10minutemail.com" → is_disposable: true

Invalid inputs (valid=false): "Asdf" (no @), "hello@//gmail.xn--om.3ia"

Field Examples: Email, Work Email, Co-Borrower Email

Common Component Usage:

  • Check if email is from a specific domain: Email > Domain equals "company.com"
  • Identify free email providers: Email > Is Free is true
  • Extract username for display: {{Email > User}}

First Name Type

Simple string type for given names with basic validation.

Components:

  • Raw: Unmodified value

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • format is valid / format is invalid
  • matches pattern / does not match pattern

Examples:

"John" → "John"
"Mary-Jane" → "Mary-Jane"
"José" → "José"
"  Alice  " → "Alice"  // Whitespace trimmed

Field Examples: First Name, Co-Borrower First Name

Gender Type

Parses gender values with abbreviation support.

Valid Inputs:

  • Male: m, male, M, Male, MALE (case insensitive)
  • Female: f, female, F, Female, FEMALE (case insensitive)
  • Other: o, other, O, Other, OTHER (case insensitive)
  • With whitespace: " m " → male

Components:

  • Raw: Unmodified value
  • Abbreviation: Abbreviated form (M, F, O)

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • format is valid / format is invalid

Examples:

"male" → {               "f" → {
  normal: "male",           normal: "female",
  raw: "male",              raw: "f",
  abbr: "M",                abbr: "F",
  valid: true               valid: true
}                         }

"MALE" → "male"         "other" → abbr: "O"
"  m  " → "male"        "O" → "other"

Invalid inputs (valid=false): "50", "asdf", 5, true

Field Examples: Gender, Applicant Gender

IP Type

Handles both IPv4 and IPv6 addresses with format detection.

Components:

  • Raw: Unmodified value
  • Is IPv4: Boolean indicating IPv4 format
  • IPv6 Format: IP converted to IPv6 format

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in

Examples:

IPv4:
"198.51.90.161" → is_ipv4: true, ipv6_format: "::ffff:198.51.90.161"
"198.51.90.161/32" → CIDR notation supported
"http://198.51.90.161:32" → extracted from URL
"    198. 51. 90. 161     " → "198.51.90.161" (spaces removed)

IPv6:
"8faa:230d:52ab:98f3:a2ea:7735:a7b8:72e9" → is_ipv4: false
"[8faa:230d:52ab:98f3:a2ea:7735:a7b8:72e9]" → brackets removed
"8faa:230d:52ab:98f3:a2ea:7735:a7b8:72e9/64" → CIDR notation
"[0000:0000:0000:0000:0000:0000:0000:0001]" → "::1" (compressed)
"[ffff::186.25.192.233]" → "ffff::ba19:c0e9" (IPv4 tail)

Invalid inputs (valid=false): "256.4.5.6", "fe80:2030:31:24" (incomplete IPv6)

Field Examples: IP Address, Source IP

Last Name Type

Simple string type for family names with basic validation.

Components:

  • Raw: Unmodified value

Operators: Same as First Name type

Examples:

"Smith" → "Smith"
"O'Brien" → "O'Brien"
"García-López" → "García-López"

Field Examples: Last Name, Co-Borrower Last Name

Number Type

Parses numeric values from strings, handling currency symbols and thousands separators.

Components: None

Operators:

  • is equal to / is not equal to
  • is less than / is less than or equal to
  • is greater than / is greater than or equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in
  • is between / is not between

Examples:

"100" → 100               "$1,000.99" → 1000.99
100 → 100                  "1,234,567" → 1234567
"1.111" → 1.111           "-11" → -11
"$1100 per month" → 1100  "-$1,100" → -1100
"  1100  " → 1100         "1,100" → 1100

Invalid inputs (valid=false): true, [1], {foo: 'bar'}, "derp", NaN

Field Examples: Loan Amount, Monthly Income, Credit Score

Phone Type

Comprehensive phone number parsing and validation for US/Canada numbers with real-world verification.

Geographic Limitation: Currently only supports US and Canadian phone numbers. International numbers from other countries will be marked as invalid (valid: false) and will not parse correctly, even if they have a valid format in their home country.

Advanced Validation: The valid property indicates more than just format correctness - it verifies:

  • The area code is a real, assigned area code
  • The exchange is a real exchange within that area code
  • The area code and exchange legitimately belong together
  • The number follows valid North American Numbering Plan rules

This means a phone number like "(999) 555-1234" would be invalid even though the format is correct, because 999 is not a real area code.

What It Does NOT Verify: The validation does NOT check if:

  • The complete 10-digit number is actually connected/in service
  • The line (last 4 digits) is valid for that area code and exchange
  • The number can receive calls or texts

A number can pass type validation but still be disconnected or undeliverable.

Components:

  • Raw: Unmodified value
  • Area: Area code
  • Exchange: Exchange code
  • Line: Line number
  • Number: Full normalized number
  • Extension: Extension if present
  • Country Code: Two-letter country code
  • Country Calling Code: Numeric country calling code
  • Type: Number type (home/work/mobile)
  • Is Tollfree: Boolean for toll-free numbers

Type Hints: Append h (home), w (work), m (mobile), or c (cell) to set type

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in

Examples:

Valid US Numbers (real area codes and exchanges):
"(512) 789-1111" → area: "512", exchange: "789", line: "1111"
"512-789-1111" → "5127891111"
"512.789.1111" → "5127891111"

Invalid Despite Good Format (fake area code):
"(999) 555-1234" → valid: false (999 not a real area code)
"(123) 456-7890" → valid: false (123 not a real area code)

With Extensions:
"5127891111x123" → extension: "123"
"5127891111 x 43" → extension: "43"

Toll-Free:
"8775551212" → is_tollfree: true
"1-800-555-1212" → is_tollfree: true

With Type Hints:
"5127891111m" → type: "mobile"
"5127891111h" → type: "home"

Masked Numbers:
"1-(512) *** ****" → valid: true (masked)
"**********" → valid: true (fully masked)

International (will NOT parse correctly):
"+49 30 22610" → valid: false (not US/Canadian format)
"+44 1484 519892" → valid: false (not US/Canadian format)
Note: International numbers are not supported unless they coincidentally match US/Canadian patterns

Invalid inputs (valid=false):

  • "donkey kong" (not a number)
  • "964523331" (too short)
  • "(999) 555-1234" (invalid area code)
  • "(512) 999-1111" (invalid exchange for 512 area code)

Field Examples: Phone 1, Phone 2, Mobile Phone, Work Phone

Common Component Usage:

  • Check for specific area codes: Phone 1 > Area equals "512"
  • Identify toll-free numbers: Phone 1 > Is Tollfree is true
  • Format for display: {{Phone 1 > Area}}-{{Phone 1 > Exchange}}-{{Phone 1 > Line}}
  • Check validity: Phone 1 > Valid is true

Important Limitation: The valid property only confirms the area code and exchange are legitimate - it does NOT verify the full number is connected or deliverable. The "line" portion (last 4 digits) could still be invalid or disconnected. For true deliverability verification, use third-party Add-On services like Trestle, Telesign, or BriteVerify in a flow step to collect carrier-level metadata, then evaluate the appended data in a subsequent filter step to block disconnected numbers.

Postal Code Type

Multi-country postal code parsing supporting US, Canada, and UK formats.

Components:

  • Raw: Unmodified value
  • Country Code: Country abbreviation
  • US Components:
    • ZIP: First 5 digits
    • Four: Last 4 digits (ZIP+4)
  • Canadian Components:
    • FSA: Forward sortation area
    • LDU: Local delivery unit
  • UK Components:
    • Outcode: Outward code
    • Incode: Inward code

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in
  • matches pattern / does not match pattern

Examples:

US Formats:
"78704" → zip: "78704"
"78704-1234" → zip: "78704", four: "1234"
"78704 1234" → "78704-1234"
"787041234" → "78704-1234" (9 digits)
"78704-" → "78704" (trailing dash removed)
"78704   - 1234" → "78704-1234" (extra spaces)

Canadian Formats:
"Q2E 4U7" → fsa: "Q2E", ldu: "4U7"
"q2e4u7" → "Q2E 4U7" (auto-formatted)
"q2e      4u7" → "Q2E 4U7" (extra spaces)

UK Formats (5 patterns):
"A1 1AA" → outcode: "A1", incode: "1AA"
"A11AA" → "A1 1AA" (space added)
"AA11 1AA" → valid UK format
"AA11A 1AA" → valid UK format

Invalid inputs (valid=false): "garbage", non-postal code strings

Field Examples: Postal Code, Property Postal Code

Common Component Usage:

  • Check ZIP code: Postal Code > ZIP equals "78751"
  • Identify country: Postal Code > Country Code equals "US"
  • Use only 5-digit ZIP for matching: {{Postal Code > ZIP}}

Range Type

Parses numeric ranges and single numbers, calculating statistical values.

Components:

  • Raw: Unmodified value
  • Min: Lowest number in range
  • Max: Highest number in range
  • Mid: Average rounded down to nearest whole number
  • Average: Average of min and max

Operators:

  • is equal to / is not equal to
  • is less than / is less than or equal to
  • is greater than / is greater than or equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in

Examples:

Range Formats:
"100 to 200" → min: 100, max: 200, mid: 150
"100 - 200" → min: 100, max: 200, mid: 150
"100 200" → min: 100, max: 200  (space only)

Greater Than:
"50+" → min: 50, max: Infinity
"10+" → min: 10, max: null

Single Values:
"100" → min: 100, max: 100, mid: 100
100 → min: 100, max: 100

Decimals:
"5.5" → min: 5.5, max: 5.5
"999.95 to 10000.95" → min: 999.95, max: 10000.95

Currency:
"$1 to $10" → min: 1, max: 10
"$1,000 to $10,000" → min: 1000, max: 10000

Special Cases:
"787041234" → "78704-1234" (9 digits treated as ZIP+4)
"-10" → min: -10, max: -10
"-10+" → min: -10, max: null
"  1 to 10  " → min: 1, max: 10 (whitespace trimmed)

Date/Time Ranges:
"2015-07-01 - 2015-07-25" → date range
"2015-07-01T01:59:32.022Z - 2015-07-25T01:59:32:021Z" → time range

Invalid inputs (valid=false): "asdf", non-numeric strings

Field Examples: Age, Income Range, Years at Residence

SSN Type (Social Security Number)

US Social Security Number parsing with masking for privacy.

Components:

  • Raw: Unmodified value (only accessible during processing)
  • First Three: First three digits (only accessible during processing)
  • Middle Two: Middle two digits (only accessible during processing)
  • Last Four: Last four digits (only accessible during processing)

Maskable: Yes

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in

Examples:

During processing:
"123456789" → first_three: "123", middle_two: "45", last_four: "6789"
"123-45-6789" → "123456789" (dashes removed)
"123 45 6789" → "123456789" (spaces removed)
"123.45.6789" → "123456789" (dots removed)
"  123-45-6789  " → "123456789" (trimmed)
"donkey 123456789" → "123456789" (text ignored)

After processing (stored as): "*********"
No components accessible - all values masked

Invalid inputs (valid=false): "abcd", "", " "

Field Examples: Social Security Number

Common Component Usage (During Processing Only):

  • Check last four digits: Social Security Number > Last Four equals "1234"
  • Send to integration: {{Social Security Number > Last Four}}
  • Check if provided: Social Security Number > Valid is true

Note: After processing completes, these components are NOT available

State Type

US states and Canadian provinces with abbreviation normalization.

Components:

  • Raw: Unmodified value
  • Name: Full state/province name

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • includes / does not include
  • is included in / is not included in

Examples:

US States:
"TX" → name: "Texas"
"tx" → "TX" (auto-uppercased)
"Texas" → "TX"
"texas" → "TX"

Canadian Provinces:
"ON" → name: "Ontario"
"Quebec" → "QC", name: "Quebec"

Unknown Values (still valid=true):
"DX" → "DX" (unknown but preserved)
"Dexus" → "Dexus"
"DEXUS NEXUS" → "DEXUS NEXUS"

Field Examples: State, Property State, License State

Street Type

Street address parsing with number and name extraction.

Components:

  • Raw: Unmodified value
  • Number: Street number
  • Name: Street name

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in
  • matches pattern / does not match pattern

Examples:

"123 Main Street" → number: "123", name: "Main Street"
"4203 Guadalupe St" → number: "4203", name: "Guadalupe St"
"  123 Main St  " → "123 Main St" (trimmed)

Invalid inputs (valid=false): "Main Street" (no number), "Asdf"

Field Examples: Address 1, Property Address

String Type

Universal text type with no format requirements.

Components: None

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • includes / does not include
  • is included in / is not included in
  • matches pattern / does not match pattern

Examples: Any text value

Field Examples: Comments, Description, Custom Field 1

Time Type

Natural language datetime parsing with flexible format support.

Components:

  • Raw: Unmodified value

Operators:

  • is equal to / is not equal to
  • is less than / is less than or equal to
  • is greater than / is greater than or equal to
  • is blank / is not blank
  • format is valid / format is invalid
  • is between / is not between

Examples:

Natural Language:
"June 14, 2015 6:27 PM" → "2015-06-14T18:27:00.000Z"
"Sat Jun 14 2014 13:27:33 GMT-0500 (CDT)" → ISO datetime
"yesterday at 3pm" → (calculated datetime)

ISO Formats:
"2015-06-14T18:27:33Z" → "2015-06-14T18:27:33.000Z"
"2015-06-14T18:27:33.123Z" → with milliseconds
"2015-06-14T18:27:33.12345Z" → with microseconds

Other Formats:
"06/14/2014 6:27:33 PM" → ISO datetime
JavaScript Date objects → ISO datetime

Invalid inputs (valid=false): "garbage", {foo: 42}

Field Examples: Submission Time, Appointment Time

TrustedForm URL Type

Specialized type for TrustedForm certificate URLs with validation.

Components:

  • Raw: Unmodified certificate URL
  • Certificate ID: Certificate identifier
  • Type: Certificate type (web/facebook/mobile/masked)
  • Is Masked: Boolean for masked certificates
  • Is Web: Boolean for web certificates
  • Is Mobile: Boolean for mobile certificates
  • Is Facebook: Boolean for Facebook Lead Ads certificates

Special Validation:

  • Must be HTTPS
  • Must be from valid TrustedForm domain
  • Certificate expires after 90 days
  • Environment must match (production/staging)

Operators:

  • is blank / is not blank
  • format is valid / format is invalid

Examples:

Web Certificates:
"https://cert.trustedform.com/eb9fc4dd9bed9ad451a5648946cf4bf09b5bb947"
  → type: "web", is_web: true

Facebook Certificates:
"https://cert.trustedform.com/0.GUr7[...very long...]" (with dots)
  → type: "facebook", is_facebook: true

Mobile Certificates:
"https://cert.trustedform.com/[64-character-id]"
  → type: "mobile", is_mobile: true

Staging/Dev URLs:
Allowed in non-production environments

Invalid inputs (valid=false):

  • Non-HTTPS URLs
  • Wrong domain
  • Malformed certificate IDs
  • Expired certificates (>90 days)

Field Examples: TrustedForm Certificate URL

URL Type

General URL parsing with component extraction.

Components:

  • Raw: Unmodified value
  • Protocol: Protocol (http/https)
  • Host: Host name
  • Port: Port number if present
  • Path: URL path
  • Query: Query string
  • Hash: Fragment/hash if present

Operators:

  • is equal to / is not equal to
  • is blank / is not blank
  • is obscene / is not obscene
  • format is valid / format is invalid
  • includes / does not include
  • is included in / is not included in

Examples:

Full URLs:
"https://google.com/search?q=hi#results"
  → protocol: "https", host: "google.com", path: "/search", query: "q=hi", hash: "results"

Partial URLs:
"centennialbulb.org" → host: "centennialbulb.org" (no protocol)
"172.0.0.1" → valid IP as URL
"http" → protocol only
"whatever" → treated as domain

Invalid inputs (valid=false): "", " ", "https://", "donkey://google.com"

Field Examples: Landing Page URL, Referrer URL

How Types Work in Practice

Automatic Normalization - No Manual Work Needed

Types automatically normalize data - you don't need to:

  • Email: Automatically lowercased (never use {{lowercase email}})
  • Phone: Automatically normalized to 10 digits
  • State: Automatically converted to 2-letter abbreviation
  • Postal Code: Automatically formatted
  • Names: Automatically trimmed of whitespace

The type system handles ALL normalization - just pass the raw data!

Standardization in Action

Types accept chaotic input and produce consistent output:

Phone Number Standardization:

"(512) 789-1111" → "5127891111"
"512-789-1111"   → "5127891111"  
"512.789.1111"   → "5127891111"
"5127891111"     → "5127891111"
"+1 512 789 1111" → "5127891111"

All produce the same normalized format with identical components.

Date Standardization:

"6/2/2014"      → "2014-06-02"
"June 2, 2014"  → "2014-06-02"
"2014-06-02"    → "2014-06-02"
"06-02-2014"    → "2014-06-02"
"20140602"      → "2014-06-02"

All produce ISO format dates.

Validation Without Rejection

When types encounter invalid data:

  1. Parsing continues: The system doesn't stop
  2. valid is set to false: Marking the data quality issue
  3. raw preserves input: Original data is never lost
  4. Components may be empty: But the structure remains
  5. Flows continue: You decide how to handle invalid data

Example:

// Invalid phone number
Input: "not a phone"
Result: {
  normal: "notaphone",  // Non-digits removed
  raw: "not a phone",   // Original preserved
  valid: false,         // Marked as invalid
  // No components extracted
}
// Lead continues processing!

Component Usage Best Practices

Always prefer components over string manipulation:

✅ Good - Using Components:

// Check area code
Phone 1 > Area equals "512"

// Check email domain
Email > Domain equals "gmail.com"

// Check ZIP code
Postal Code > ZIP equals "78701"

❌ Bad - String Manipulation:

// Don't do this!
substring(Phone 1, 0, 3) equals "512"
split(Email, "@")[1] equals "gmail.com"
substring(Postal Code, 0, 5) equals "78701"

Components are:

  • Already parsed and validated
  • More efficient (no runtime parsing)
  • More reliable (handle edge cases)
  • Clearer in intent

Special Type Behaviors

Maskable Types

Some types contain sensitive data that are automatically masked for security:

  • SSN: Social Security Numbers - all components masked
  • DOB: Dates of birth - all components masked (including age and year)
  • Credential: Passwords and API keys - entire value masked

How Masking Works:

  1. During Processing: LeadConduit can use the full, unmasked field value and all components while the lead is being processed
  2. After Processing: Values are written to the database as * characters only
  3. No Components Preserved: Unlike other types, maskable types do NOT preserve any components - everything is masked
  4. Permanent: The unmasked values and components exist only in memory during processing - they are gone forever after that
  5. What You See:
    • UI displays: Masked values only, no components
    • API responses: Masked values only, no components
    • Event exports: Masked values only, no components
    • Reports: No data available for these fields

Example of SSN Masking:

During processing: "123-45-6789" → Available for rules and integrations
In database/UI/API: "*********" → Only masked version stored
Components: NOT preserved - no SSN data accessible after processing

Example of DOB Masking:

During processing: "1990-01-15" → Age: 34.9, Year: 1990 available
In database/UI/API: "****-**-**" → Only masked version stored
Components: NOT preserved - no DOB data accessible after processing

Example of Credential Masking:

During processing: "mypassword123" → Available for integrations
In database/UI/API: "*************" → Only masked version stored

This ensures sensitive data can be used for processing (validation, delivery to buyers) while maintaining security and compliance by never storing the actual values or any components.

Types with Special Validation

TrustedForm URL:

  • Must be HTTPS
  • Must be from valid TrustedForm domain
  • Certificate must not be older than 90 days
  • Environment must match (production/staging)

Email:

  • Detects free providers (Gmail, Yahoo, etc.)
  • Identifies disposable/temporary emails
  • Normalizes to lowercase

Phone:

  • Validates actual area codes and exchanges (not just format)
  • Verifies area code/exchange combinations are real
  • Only supports US/Canadian numbers currently
  • Supports type hints (h=home, w=work, m=mobile)
  • Detects toll-free numbers
  • Handles extensions
  • Recognizes masked numbers

Always-Valid Types

Some types never return valid: false:

  • String: Any text is valid
  • City: Any city name is valid
  • State: Any locality is valid
  • First/Last Name: Any name is valid
  • Credential: Any credential is valid

These types accept any string input because there's no universal format to validate against.

Type Selection Guide

When to Use Each Type

String: Default for text without specific format requirements

  • Custom fields
  • Comments
  • Descriptions
  • Generic text data

Number: Numeric data for calculations or comparisons

  • Prices
  • Quantities
  • Scores
  • IDs

Boolean: Yes/no decisions

  • Opt-ins
  • Preferences
  • Flags
  • Consent

Email: Contact emails requiring validation

  • Primary contact
  • Marketing emails
  • Account emails

Phone: Phone numbers needing standardization

  • Contact numbers
  • SMS numbers
  • Call tracking

Date/Time: Temporal data

  • Submission dates
  • Appointment times
  • Deadlines

DOB: Special handling for birth dates

  • Age verification
  • Age-based decisions
  • Demographics

Postal Code: Location-based decisions

  • Geographic targeting
  • Shipping addresses
  • Tax determination

SSN: Highly sensitive identification

  • Credit checks
  • Identity verification
  • Compliance requirements

Common Patterns

Multi-Format Input Handling

Types gracefully handle various input formats:

Boolean: "yes", "y", "1", "true" → true
State: "TX", "Texas", "tx", "texas" → "TX"
Phone: Multiple formats → Single standard

Progressive Enhancement

Types extract as much value as possible:

Valid email → All components extracted
Invalid email → Still preserves raw, domain might be partial
Valid phone → All components available
Invalid phone → Raw preserved, some components may exist

Business Logic Enablement

Types enable sophisticated rules without complexity:

IF Email > Is Free is true THEN apply different pricing
IF Phone 1 > Is Tollfree is true THEN flag for review
IF DOB > Age is less than 18 THEN require guardian consent
IF Postal Code > Country Code equals "US" THEN use US validation

Integration with LeadConduit

Field Type Assignment

In flow configuration:

  1. Each field can be assigned a type
  2. Types are applied during lead processing
  3. Parsed data replaces raw input
  4. Components become available immediately

Rule Evaluation

Types integrate with the rules engine:

  • Use valid property in conditions
  • Access components directly
  • Compare normalized values
  • Apply type-specific operators

Data Flow

  1. Input arrives in various formats
  2. Types parse based on field configuration
  3. Normalization prepares for storage
  4. Components available in rules/mappings
  5. Storage uses normalized format
  6. Delivery can use any component