Types - ActiveProspect Developer Documentation

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:

Data Chaos: Lead data arrives in countless formats
Validation Confusion: What makes data “valid” varies by context
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

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

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

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

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

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:

Parsing continues: The system doesn’t stop
valid is set to false: Marking the data quality issue
raw preserves input: Original data is never lost
Components may be empty: But the structure remains
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:

During Processing: LeadConduit can use the full, unmasked field value and all components while the lead is being processed
After Processing: Values are written to the database as * characters only
No Components Preserved: Unlike other types, maskable types do NOT preserve any components - everything is masked
Permanent: The unmasked values and components exist only in memory during processing - they are gone forever after that
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:

Each field can be assigned a type
Types are applied during lead processing
Parsed data replaces raw input
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

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

​Overview

​How Types Work

​The Problems Types Solve

​How Types Solve These Problems

​Quick Reference

​Complete Type Catalog

​Contact Types

​Phone Type

​Email Type

​Personal Data Types

​First Name Type

​Last Name Type

​DOB Type (Date of Birth)

​Gender Type

​SSN Type (Social Security Number)

​Location Types

​Street Type

​City Type

​State Type

​Postal Code Type

​Data Types

​Boolean Type

​City Type

​Credential Type

​Date Type

​DOB Type (Date of Birth)

​Email Type

​First Name Type

​Gender Type

​IP Type

​Last Name Type

​Number Type

​Phone Type

​Postal Code Type

​Range Type

​SSN Type (Social Security Number)

​State Type

​Street Type

​String Type

​Time Type

​TrustedForm URL Type

​URL Type

​How Types Work in Practice

​Automatic Normalization - No Manual Work Needed

​Standardization in Action

​Validation Without Rejection

​Component Usage Best Practices

​Special Type Behaviors

​Maskable Types

​Types with Special Validation

​Always-Valid Types

​Type Selection Guide

​When to Use Each Type

​Common Patterns

​Multi-Format Input Handling

​Progressive Enhancement

​Business Logic Enablement

​Integration with LeadConduit

​Field Type Assignment

​Rule Evaluation

​Data Flow

Overview

How Types Work

The Problems Types Solve

How Types Solve These Problems

Quick Reference

Complete Type Catalog

Contact Types

Phone Type

Email Type

Personal Data Types

First Name Type

Last Name Type

DOB Type (Date of Birth)

Gender Type

SSN Type (Social Security Number)

Location Types

Street Type

City Type

State Type

Postal Code Type

Data Types

Boolean Type

City Type

Credential Type

Date Type

DOB Type (Date of Birth)

Email Type

First Name Type

Gender Type

IP Type

Last Name Type

Number Type

Phone Type

Postal Code Type

Range Type

SSN Type (Social Security Number)

State Type

Street Type

String Type

Time Type

TrustedForm URL Type

URL Type

How Types Work in Practice

Automatic Normalization - No Manual Work Needed

Standardization in Action

Validation Without Rejection

Component Usage Best Practices

Special Type Behaviors

Maskable Types

Types with Special Validation

Always-Valid Types

Type Selection Guide

When to Use Each Type

Common Patterns

Multi-Format Input Handling

Progressive Enhancement

Business Logic Enablement

Integration with LeadConduit

Field Type Assignment

Rule Evaluation

Data Flow