Multi-Person Forms

Test forms with multiple email fields, referrals, recipients, and identity prioritization

SDK Field Priority System

The SDK uses a 5-tier priority system to determine which email represents the form filler:

When multiple emails exist, confidence is reduced to 50 (position-based) even for the winning email.

P1 Primary patterns (95 confidence)
P2 Account patterns (75 confidence)
P3 Work patterns (65 confidence)
P4 Ambiguous (40-50 confidence)
P5 Hard filtered (EXCLUDED)

1. Refer-a-Friend (Classic)

Capture: your email Exclude: friend_email

Classic referral form. SDK should capture the referrer, not the friend.

Green = Should capture | Red = Should exclude
Expected: Capture referrer@acmecorp.io | Exclude friend@otherdomain.com

2. Gift Purchase

Capture: buyer email Exclude: recipient_email

Purchasing a gift for someone else. Capture buyer, not recipient.

Green = Should capture | Red = Should exclude
Expected: Capture buyer@acmecorp.io | Exclude recipient@family.com

3. Billing vs Account Email

Capture: account_email Exclude: billing_email

Separate billing contact. Account email is the user.

Green = Should capture | Red = Should exclude
Expected: Capture user@acmecorp.io (P2) | Exclude billing (hard filter)

4. CC & Notification Emails

Capture: primary Exclude: cc_email, notify_email

Form with CC and notification copies. Only capture primary.

Green = Should capture | Red = Should exclude
Expected: Capture primary@ | Exclude cc@ and notify@

5. Emergency Contact Form

Capture: applicant Exclude: emergency_contact

Job application with emergency contact. Capture applicant only.

Green = Should capture | Red = Should exclude
Expected: Capture applicant@ | Exclude emergency contact

6. Employee with Manager

Capture: employee Exclude: manager_email

Time-off request form. Capture employee, not manager.

Green = Should capture | Red = Should exclude
Expected: Capture employee@ | Exclude manager@ and supervisor@

7. Shipping to Different Person

Capture: customer Exclude: shipping_email

Shipping to someone else (not a gift). Capture orderer.

Green = Should capture | Red = Should exclude
Expected: Capture orderer@ | Exclude shipping contact

8. Multiple Same-Priority Emails

Both P1 Confidence: 50 (reduced)

Two P1 priority fields. SDK uses position, reduces confidence.

Both fields are Priority 1 - first one wins, confidence reduced to 50
Expected: Capture first@ (position wins) | Confidence: 50 (multi-email penalty)

9. Priority Waterfall Test

P1 beats P2 beats P3

Three emails at different priorities. Highest priority wins.

P1 > P2 > P3 - highest priority email is captured
Expected: Capture primary@ (P1) even though work@ appears first in DOM

10. Only Referral Emails (No Primary)

All hard-filtered

Form with ONLY excluded field names. Should capture nothing.

All fields are hard-filtered - no capture expected
Expected: NO pp event - all emails are hard-filtered

11. Primary + Alternate Email

Capture: primary Exclude: alternate_email

User's primary and backup emails. Only capture primary.

Green = Should capture | Red = Should exclude
Expected: Capture primary@ | Exclude alternate@ and secondary@

12. Joint Application (Spouse)

Capture: applicant Spouse: ambiguous (P4)

Joint application with spouse. Primary applicant captured.

spouse_email is not hard-filtered but is P4 (ambiguous). Primary email (P1) wins.
Expected: Capture applicant@ (P1 beats P4) | Confidence: 50 (multi-email)

13. Unconventional Field Names

Test: e_mail, emailaddress, mail Edge case naming

Non-standard field names. SDK should still detect email fields.

Tests: e_mail, e-mail, emailaddress, mail - should SDK recognize these?
Expected: SDK should recognize email variants. First field wins with multi-email penalty.

14. Case & Separator Variations

emailAddress vs email_address vs email-address

Same semantic meaning, different coding conventions.

CamelCase, snake_case, kebab-case - SDK normalization test
Expected: SDK should normalize case/separators. Check which one wins priority.

15. Platform-Specific Field Prefixes

hbspt_, mkto_, sf_, wp_ CRM prefixes

Platform-specific field naming (HubSpot, Marketo, Salesforce, WordPress).

Common CRM platform prefixes - SDK should strip or ignore prefix
Expected: SDK should recognize email after stripping common platform prefixes.

16. Company Contact Form

Personal email vs company_email Which represents the person?

Personal contact submitting company info. Capture person, not company.

Green = Person's email | Company fields may be ambiguous
Expected: Capture john.smith@ (P1) | company_email should NOT be captured (it's the company, not the person)

17. B2B Lead Form (Multiple Contacts)

lead_email vs decision_maker_email vs champion_email

B2B sales form with multiple stakeholder emails.

CRM-style multi-stakeholder form - which email is the form filler?
Expected: Capture lead_email (form filler) | Others are third-party contacts

18. Real Estate Transaction

buyer vs seller vs agent Industry-specific

Real estate form with buyer, seller, and agent. Who is filling the form?

All parties may be legitimate identities - context matters
Expected: Context-dependent. If agent fills form, capture agent_email. buyer/seller may be filtered.

19. Healthcare Appointment

patient_email guardian_email, physician_email

Medical appointment form with patient, guardian, and physician.

Patient is form filler | Guardian/physician are contacts
Expected: Capture patient_email | guardian/physician are third parties

20. Legal Document Signing

signer_email vs witness_email vs notary_email

Legal document with multiple required parties.

Signer is the primary, witnesses/notary are third parties
Expected: Capture signer_email | witnesses and notary are third parties

21. Corporate Account Setup

admin_email hr_email, finance_email, legal_email

Enterprise setup with department contacts.

Admin is form filler | Department emails are distribution lists
Expected: Capture admin_email | Department emails are distribution lists, not people

22. Executive Team Registration

registrant vs ceo vs cto vs cfo C-suite ambiguity

Event registration listing executive contacts.

Registrant is form filler. C-suite emails are for event logistics.
Expected: Capture registrant_email (form filler) | C-suite emails are attendees

23. Partner & Vendor Registration

contact_email partner_email, vendor_email, supplier_email

B2B form registering external business relationships.

Contact is internal | Partners/vendors are external entities
Expected: Capture contact_email (P1) | partner/vendor/supplier are external entities

24. Insurance Claim

claimant_email beneficiary_email, insured_email

Insurance claim with policyholder, beneficiary, and claimant.

Claimant files the form. Insured/beneficiary may be different people.
Expected: Capture claimant_email (form filler) | insured/beneficiary are policy subjects

25. Student Enrollment

student vs parent vs teacher vs counselor

School enrollment with multiple stakeholders.

Who is filling the form? Student (if adult) or parent (if minor)?
Expected: Context-dependent. student_email if adult, parent_email if minor fills form.

26. Abbreviated Field Names

em, eml, addr, usr Minimized names

Extremely abbreviated field names. Can SDK recognize these?

Legacy systems often use short field names to save bytes
Expected: SDK may not recognize ultra-abbreviated names. Fall back to type="email" detection.

27. International Field Names

correo, courriel, e-posta, email Non-English

Non-English field names for email. SDK language support test.

International websites may use localized field names
Expected: SDK may not recognize non-English names. Fall back to type="email" detection.

28. Numeric Suffixes

email1, email2, email_1, email_2 Position ambiguity

Numbered email fields. Which number is primary?

email1/email_1 usually means primary, but not always
Expected: SDK should prefer email1/email_1 (lower number = primary). Heavy multi-email penalty.

29. Role-Based Confusion

owner vs user vs member vs subscriber Who is filling?

Similar roles that could all mean "form filler".

All these might be the same person - how does SDK decide?
Expected: user_email is P2. Others are P4 (ambiguous). user_email should win.

30. From/To/Reply Email Pattern

from_email vs to_email vs reply_to Sender/recipient ambiguity

Email-sending form fields. Who is the person?

from_email is the sender (form filler). to/reply_to are recipients.
Expected: Capture from_email (sender) | to_email should be filtered

31. Detailed Company Profile

submitter_email Multiple dept emails

Full company profile with many department contacts.

Submitter is the person | All others are distribution lists
Expected: Capture submitter_email | info@, sales@, support@, press@ are all distribution lists

32. Type="email" Override Test

type="email" on non-email named fields

Fields with type="email" but unusual names. Does type override name?

HTML5 type="email" provides browser validation - SDK uses this too
Expected: type="email" fields should be captured. text_value should NOT be captured despite containing @.

33. Array Notation (contacts[])

name="contacts[0][email]" Framework notation

PHP/Rails style array notation for multiple contacts.

Common in backend frameworks - SDK must parse bracket notation
Expected: SDK should recognize [email] in bracket notation. contacts[0] wins as first.

34. Dot Notation (user.email)

name="user.email" vs "profile.email" Object-style naming

JavaScript/JSON style dot notation for nested fields.

Some forms use dot notation for complex data structures
Expected: Capture user.email | billing.email should be filtered

35. All P4 Ambiguous Fields

No priority patterns match Confidence ~40-50

Multiple emails with no recognizable priority patterns.

When nothing matches P1-P3, SDK uses position + required attribute
Expected: Capture alpha_addr (first + required) | Confidence: ~40 (ambiguous)

36. Webhook/API-Style Names

payload.data.email, attributes.email

Field names that look like API/webhook payloads.

Some forms serialize to match backend API structure
Expected: SDK should parse nested notation and extract "email" keyword.

37. Comprehensive Hard Filter Test

All hard-filtered patterns

Every hard-filter pattern in one form. Only "email" should be captured.

Only email is capturable | All others MUST be excluded
Expected: ONLY capture me@acmecorp.io | All 10 other fields MUST be excluded
[Ready] Multi-Person Form Tests Loaded