How Web to Lead Forms Actually Work: Technical Functionality
IN THE CRM
This article explains the actual mechanics and working processes of how Web to Lead Forms function in the CRM system. Understanding the technical workflow will help you use forms more effectively.
Form Creation and Storage Process
When You Create a Form:
1. Form Definition Storage
- Your form configuration is stored in the CRM database with a unique ID
- Each form gets a unique identifier (UUID or numeric ID)
- The form definition includes:
a) Field structure and order
b) Field validation rules
c) Configuration settings (source, status, assignee)
d) Branding options (colors, button text)
e) Submission behavior rules
2. Unique Form URL Generation
- When you save a form, the system automatically generates a unique URL
- Format: https://crm.podcator.com/forms/wtl/[unique-form-id]
- This URL is created in the form's database record
- The same form will always have the same URL
3. Public Accessibility
- Your form URL becomes publicly accessible on the internet
- No authentication required to view or submit the form
- The form remains live until you delete it
- Search engines may index the form URL over time
How Form Data is Collected
When Someone Submits Your Form:
1. Data Capture Process
- Visitor enters information into form fields
- Browser performs client-side validation (if enabled)
- Visitor clicks Submit button
- Form data is packaged into an HTTP POST request
- Data includes field values and form metadata
2. Data Transmission
- The form sends data securely to: https://crm.podcator.com/forms/api/submit
- Uses HTTPS encryption (secure connection)
- Data is transmitted over the internet to the CRM server
- The unique form ID is included in the request
- Form configuration is matched using the form ID
3. Server-Side Processing
- The CRM server receives the submission
- Server looks up the form configuration using the form ID
- Performs server-side validation on all fields
- Checks for duplicate submissions (if enabled)
- Maps form fields to CRM lead fields
How Form Data Becomes a Lead
Lead Creation Workflow:
1. Data Mapping
- Form field values are mapped to CRM lead field definitions
- Example: Form "Email" field → Lead "Email Address" field
- Custom form fields map to custom lead fields
- Unmapped fields are ignored or stored as notes
2. Lead Record Creation
- The system creates a new Lead record in the database
- Automatically assigned:
a) Source: From your form's "Source" setting
b) Status: From your form's "Status" setting
c) Lead Title: Prefix + visitor name from form
d) Responsible Person: From form's assignee setting
3. Field Population
- Lead record fields are populated with visitor data
- First Name, Last Name, Email, Phone, etc. are filled
- Dates are formatted to database standards
- Empty required fields may trigger validation errors
- The entire submission is atomic (all or nothing)
How the Lead Title Prefix Works
Technical Process:
1. Prefix Configuration
- You set a prefix (example: "reg") in form settings
- This prefix is stored in the form configuration
- System retrieves this prefix on each submission
2. Concatenation on Submission
- When form is submitted with name "John Smith"
- System performs string concatenation: "reg" + " " + "John Smith"
- Result stored in Lead Name field: "reg John Smith"
- This happens server-side before database insertion
- Prefix is applied to every submission from this form
3. Database Storage
- The concatenated name is what's saved in the database
- Lead record contains the complete prefixed name
- Searching for leads returns them with the prefix
- Useful for batch operations and reporting
Notification System Mechanics
How Notifications Are Generated and Sent:
1. Notification Trigger
- After successful lead creation, notification system activates
- Only if "Notify when lead imported" is checked
- Checks recipient configuration in form settings
2. Recipient Determination
- System determines who receives notification based on:
a) Specific Staff Members mode: Uses selected staff list
b) Staff with Roles mode: Queries all staff with selected roles
c) Responsible Person mode: Uses the assigned person
- Staff email addresses are retrieved from CRM database
- System filters out deactivated users
3. Email Generation
- Creates notification email from template
- Includes: Lead name, source, contact info, submission time
- Email is queued in the CRM mail system
- Sent asynchronously (not blocking form submission)
- Retry mechanism if initial send fails
4. Delivery Process
- Email is sent via configured SMTP server
- May take seconds to minutes to appear in inbox
- Follows server's email sending queue
- Can be affected by spam filters
- Delivery status tracked in activity logs
Post-Submission Behavior
How Different Submission Actions Work:
1. Thank You Message Display
- After successful server-side processing
- JavaScript on form page displays configured message
- Message replaces form or appears in modal
- Visitor stays on form page
- Page refresh clears the form
2. Website Redirect Mechanism
- Server sends HTTP redirect response
- Browser follows redirect to specified URL
- Visitor's browser makes new request to target site
- Visitor sees target page immediately after submit
- Original form data is not visible to target site
3. Platform Autologin Process
- Server creates temporary authentication token
- Token includes user credentials and permissions
- Form passes token via URL parameter or cookie
- Browser navigates to CRM platform URL with token
- Platform recognizes token and automatically logs user in
- Session established without password entry
Duplicate Lead Prevention
How the Duplicate Prevention Works:
1. Detection Method
- When "Allow duplicate lead" is unchecked
- System queries database for existing leads with same:
a) Email address (most common match field)
b) Phone number
c) Name
- Uses fuzzy matching or exact match (depends on configuration)
2. Decision Logic
- If matching lead found:
a) Submission is rejected
b) Error message returned to visitor
c) No new lead is created
- If no match found:
a) New lead is created normally
b) Submission is processed
3. Limitation
- Only prevents exact/near-exact duplicates
- Different name variations may not be detected
- Same person with different email treated as new lead
- Checking enabled per-form basis
Data Flow Diagram
Complete Submission Flow:
1. Visitor → Fills form fields
2. Browser → Validates fields (client-side)
3. Visitor → Clicks Submit button
4. Browser → Sends HTTPS POST request with data
5. Internet → Transmits encrypted data
6. CRM Server → Receives and parses request
7. Server → Validates data (server-side)
8. Server → Checks for duplicates
9. Server → Maps form fields to lead fields
10. Server → Creates Lead record in database
11. Server → Applies prefix to lead name
12. Server → Assigns source, status, owner
13. Server → Returns success response to browser
14. Notification System → Queues notification email
15. Browser → Displays thank you message or redirects
16. Email System → Sends notification
17. Lead appears in Leads → Module and assignee's dashboard
Source and Status Field Logic
How Source and Status Are Applied:
1. Source Assignment
- Every lead from form gets source from form settings
- Source is stored in lead's "Source" field
- Used for tracking form effectiveness
- Enables filtering leads by source in reports
- Cannot be changed per-submission (static per form)
2. Status Assignment
- Initial status set from form settings
- Stored in lead's "Status" field
- Status can be changed manually after creation
- Determines lead's position in sales pipeline
- Used for workflow automation and filtering
3. Database Storage
- Both stored as foreign keys or values in lead record
- Permanent part of lead history
- Searchable and reportable
- Initial status shown in lead creation timeline
Language and Validation
How Language Settings Affect Form Behavior:
1. Validation Message Language
- Form language setting determines error message language
- When field validation fails, error displays in selected language
- Example: Required field error shows: "This field is required" (English) or "Questo campo è obbligatorio" (Italian)
2. Client-Side Validation
- Browser validates fields based on field type
- Language setting affects error messages
- Validation happens before form is submitted
3. Server-Side Validation
- CRM server performs secondary validation
- Enforces field requirements regardless of language
- Language setting doesn't affect server validation logic
- Ensures data integrity across all submissions