## Why Automate CRM Data Entry?

This is the most common form automation use case by volume. A sales team generates leads at a trade show, collects business cards, or receives a list from a marketing campaign. That data lives in a spreadsheet. It needs to go into the CRM. And someone on the team is going to spend hours clicking through create-contact dialogs, copying and pasting fields one by one, and fighting with dropdown menus that take three seconds to load.

The real cost is not just the time — it is the error rate. Manual data entry into CRMs has a typical error rate of 2-5%. Across 500 leads, that is 10-25 records with misspelled names, wrong phone numbers, or misattributed companies. Those errors compound downstream — sales reps call the wrong number, marketing emails bounce, and pipeline reports show inaccurate data.

### The Shadow DOM Problem

Salesforce Lightning is built entirely with web components and shadow DOM. Every field is a custom `lightning-input` or `lightning-combobox` that traditional automation tools cannot interact with. Shadow DOM creates encapsulated DOM subtrees that standard CSS selectors — the kind used by Selenium, browser macros, and most RPA tools — cannot pierce at all. An automation tool that queries `document.querySelector` will not find elements inside a shadow root unless it specifically handles shadow DOM traversal.

This is not a theoretical problem. Teams that try to automate Salesforce with traditional tools spend weeks building workarounds, only to have them break on the next Salesforce release. Autonoly's AI bypasses this entirely by treating each field as a visual element with a label. The AI reads "Contact Name" on screen and fills it, regardless of whether the underlying HTML is a plain `<input>`, a Lightning `lightning-input`, or a custom web component.

### Platform-Specific Handling

**Salesforce Lightning**: Shadow DOM, custom `lightning-*` components, server-side validation, and lookup fields that require searching and selecting from existing records. The agent handles the search-and-associate pattern for linking contacts to accounts — type the account name, wait for the dropdown suggestions, and click the correct match. Custom objects and custom fields are handled the same way as standard objects.

**HubSpot**: React-based forms with standard labeling that works well with vision-based detection. The main complexity is association lookups — linking a contact to a company requires searching the company name, waiting for dropdown suggestions, and selecting the right match. HubSpot's custom properties with specific validation rules (URL format, number ranges, date formats) are handled by the AI's data formatting engine.

**Zoho CRM**: A mix of standard HTML and custom JavaScript components. Zoho's multi-module structure (Leads, Contacts, Accounts, Deals) means the agent needs to navigate to the correct module before creating records. The agent handles Zoho's mandatory field validation and custom picklist values.

### Step-by-Step Setup

**Step 1: Prepare your data source.** Open Google Sheets and create (or import) a spreadsheet with columns for each CRM field: First Name, Last Name, Email, Phone, Company, Job Title, and any custom fields. Make sure the data is clean — run it through [Data Processing](/features/data-processing) to normalize phone numbers, validate email addresses, and standardize company names.

**Step 2: Create a new workflow.** In Autonoly, open the [Visual Workflow Builder](/features/visual-workflow-builder) and create a new workflow. Name it something descriptive like "HubSpot Contact Import."

**Step 3: Add a data source node.** Connect your Google account through [Integrations](/features/integrations) and select the spreadsheet. Choose the sheet and row range. The workflow loops through each row.

**Step 4: Add a Browser Navigation node.** Set the URL to your CRM's contact creation page. Add a Login step using credentials from the encrypted vault. The agent logs in and navigates to the create form.

**Step 5: Add a Form Automation node.** Click "Auto-Detect Fields" — the AI opens the CRM's create dialog, identifies all form fields, and presents them to you. Map each field to a column from your spreadsheet.

**Step 6: Add submission verification.** After each entry, the agent checks for the new record appearing in the CRM. It captures the record URL as confirmation.

**Step 7: Test with one row.** Enable [Live Browser Control](/features/live-browser-control) and run the workflow with a single row. Watch the agent fill the form in real time. Correct any field mapping issues.

**Step 8: Run the full batch.** Disable Live Browser Control and run for all rows. Each row processes independently — if row 47 fails due to a duplicate email, it logs the error and continues with row 48.

### Processing Speed

- **Simple CRM entries (5-10 fields)**: 15-25 seconds per record
- **Complex entries (15-30 fields, associations)**: 40-75 seconds per record
- **Batch throughput**: 80-150 simple records per hour, 40-70 complex records per hour

These numbers include login overhead (amortized across the batch), field interaction time, and submission verification. Salesforce is typically the slowest due to shadow DOM rendering overhead and server-side validation.

### Error Handling

The most common CRM data entry errors:

- **Duplicate detection**: The CRM rejects a record because an email or phone already exists. The agent detects the duplicate warning and either updates the existing record or skips and logs the duplicate.
- **Required field missing**: The spreadsheet has a blank cell for a required CRM field. The agent flags the row for review and continues with the next.
- **Picklist value mismatch**: The spreadsheet says "Technology" but the CRM picklist has "Information Technology." The agent selects the closest matching option.
- **Association lookup failure**: The company name in the spreadsheet does not match any existing CRM account. The agent can either create a new account or flag the record for manual association.

### When to Use Form Automation vs. CRM API

If your CRM has a well-documented API and you have developer resources, direct API integration is faster for bulk imports. Form automation is the right choice when:

- You do not have API access (many [Salesforce](https://www.salesforce.com) orgs restrict API access by license type)
- The CRM has custom validation or business rules that only trigger through the web UI
- You need to handle complex workflows like association lookups that are easier through the UI than the API
- Your team changes CRMs periodically and you do not want to rebuild API integrations each time
- You are entering data into a third-party CRM you do not control (e.g., a client's CRM)

### Data Quality and Privacy Governance

CRM data entry is deceptively high-stakes because the records you create become the foundation for every downstream sales, marketing, and support process — bad data compounds. The single most valuable governance practice is normalization before entry: run your source spreadsheet through [Data Processing](/features/data-processing) to standardize company names, deduplicate against existing records, and map free-text values to the CRM's controlled picklists, so the agent is filling clean, canonical values rather than propagating inconsistencies. Equally important is the privacy dimension. CRM records hold personal data — names, emails, phone numbers, and often notes about individuals — which means they fall under regulations like the [General Data Protection Regulation](https://gdpr.eu) when your contacts include people in the EU. In practice this means you should only import contacts you have a lawful basis to process, honor opt-outs and suppression lists during the import, and avoid loading speculative or scraped personal data that you cannot demonstrate consent for. Configure the workflow to skip rows flagged as do-not-contact and to log exactly which records were created or updated, giving you the auditable trail regulators and your own compliance team will expect.

### Advanced Usage and Edge Cases

At scale, the interesting behavior is in upsert logic and association handling. Decide up front whether a matching record should be updated or skipped, and define the match key precisely — email is usually more reliable than name, but watch for shared inboxes and role addresses that collide across distinct contacts. For records that must link to a parent account, the agent's lookup-and-select flow handles existing accounts well, but you should set an explicit policy for misses: auto-create the account, or route to a manual queue, depending on how much you trust the source data. Another common edge case is picklist drift, where the CRM admin adds or renames options after your mapping was built; pair the agent's closest-match logic with a periodic review of which values it had to approximate, so silent mismatches do not accumulate. Finally, when entering data into a client's CRM you do not control, treat permissions and rate limits conservatively — use a dedicated integration user, keep within the client's acceptable-use expectations, and validate against a small batch through [Live Browser Control](/features/live-browser-control) before running a full import, since a misconfigured run in someone else's system is far harder to unwind than in your own.

### Keeping Records in Sync Over Time

The first import is rarely the end of the story; CRM data needs ongoing maintenance, and form automation is well suited to recurring sync jobs as well as one-time loads. A common pattern is the periodic top-up: new leads accumulate in a spreadsheet or arrive from [Data Extraction](/features/data-extraction), and a scheduled workflow enters only the rows added since the last run, using a match key to skip anything already present. Another is enrichment, where the agent revisits existing records to fill fields that were blank at creation — a newly discovered phone number, an updated job title, a corrected company name — without overwriting good data with worse. To make these safe, define an explicit precedence rule for conflicts (source-of-truth wins, most-recent wins, or human review for high-value accounts) and log every change the agent makes so a reviewer can spot a bad sync before it propagates. Combined with [Scheduled Execution](/features/scheduled-execution), this turns CRM data entry from a dreaded periodic project into a quiet background process that keeps your records current, complete, and trustworthy — which is ultimately the only reason the CRM exists.

It is also worth deciding deliberately between form automation and the CRM's native import or API for each job. Bulk one-time loads of clean, well-structured data are often fastest through a native CSV importer; form automation earns its place when validation rules, required associations, or custom business logic only fire through the web UI, when you lack API access on the org's license tier, or when you are working inside a client's instance you do not administer. A pragmatic team uses both — native import for the bulk backbone and the agent for the records that need the UI's logic or human-style judgment — and routes any ambiguous row to a review queue rather than forcing a guess. Documenting which path you used for which batch, alongside the per-record change log, gives you a clean operational history that pays off the next time the data needs auditing or the same import has to be repeated.

Explore more about the tools and techniques used in this workflow: [Automate Data Entry](/blog/automate-data-entry), [No Code Automation Guide](/blog/no-code-automation-guide), [Browser Automation](/features/browser-automation), [Integrations](/features/integrations).

CRM Systems

Enter hundreds of leads from spreadsheets into Salesforce, HubSpot, or Zoho CRM automatically — no API integration needed. The AI handles shadow DOM, custom fields, and association lookups.

How to Automate CRM Data Entry from Spreadsheets

Tell the AI agent which CRM to use, provide your spreadsheet with lead data, and specify which sheet columns map to which CRM fields.

Describe your task

The agent logs into your CRM, navigates to the contact or lead creation form, and identifies all fields — even those inside shadow DOM or custom web components.

AI opens the CRM

Each spreadsheet row becomes a new CRM record. The agent fills fields, handles association lookups (linking contacts to companies), and submits each entry.

Data is entered row by row

Every entry is logged with success/failure status, the CRM record URL, and any error details. Failed entries are flagged for manual review.

Results logged

Automate data entry from spreadsheets to Salesforce, HubSpot, and Zoho CRM. Handle shadow DOM, custom components, and association lookups without API integration.

Automate CRM Data Entry: Spreadsheet to Salesforce, HubSpot | Autonoly

Automate CRM Data Entry from Spreadsheets

Automatically enter lead and contact data from spreadsheets into Salesforce, HubSpot, and Zoho CRM web forms — including shadow DOM and custom components.

Google Sheets

## Why Government Forms Are the Hardest to Automate

Government portals are the ultimate stress test for form automation, and they are also where automation saves the most time. Immigration law firms processing dozens of DS-160 visa applications per week spend entire workdays on this single form. Tax preparers filing hundreds of state and federal returns during tax season face the same repetitive data entry across portals that were built a decade ago and have not been updated since.

The specific challenges that make government forms uniquely difficult:

### Session Timeouts That Kill Progress

The US DS-160 visa application expires after 20 minutes of inactivity. The SBA disaster loan application times out after 10-15 minutes. The IRS e-file system has a 15-minute session limit. If your automation is slow on one step — waiting for a dropdown to load, handling a CAPTCHA, or dealing with a slow server response — the session expires and you lose all progress on that page.

Most automation tools do not handle this. They fill fields at their own pace, and when the session expires, the entire run fails. Autonoly's agent monitors session timers in real time, speeds up field filling when time is running low, and re-authenticates automatically when sessions expire — resuming from the last saved checkpoint rather than starting from scratch.

### Conditional Field Cascades

On immigration forms like the DS-160, selecting a country of birth triggers new fields for province, district, and city — each with its own dynamic dropdown that loads from a server call. Each selection cascades into more fields. Selecting "India" shows 36 states. Selecting "Maharashtra" shows 50+ districts. Selecting a district shows hundreds of cities. A rigid automation script cannot anticipate which fields will appear or how many levels of cascading dropdowns exist.

The AI handles this by watching for new fields to appear after each selection, reading their labels, and mapping the appropriate data from the applicant's record. It waits for each dropdown to fully populate before making a selection — unlike a script that tries to select an option before the dropdown has loaded its data, causing silent failures.

### Strict Input Validation

Government forms have the strictest input validation of any website category. The DS-160 rejects dates that are not in the exact DD-Mon-YYYY format (e.g., "15-MAR-2024" is correct, "03/15/2024" is rejected). The IRS e-file system requires Social Security numbers in XXX-XX-XXXX format with the dashes. State business registration portals have their own address format requirements that differ from state to state.

The AI uses [Data Processing](/features/data-processing) to normalize input data before filling each field, matching the exact format each portal expects. Dates, phone numbers, addresses, and identification numbers are all reformatted automatically based on the target portal's validation rules.

### Bot Detection on Government Sites

Government portals deploy increasingly aggressive bot detection. Cloudflare's Turnstile protects many state portals. Google's reCAPTCHA guards IRS and SBA sites. Some portals use custom CAPTCHA implementations that no third-party solving service supports. Rate limiting is another factor — multiple rapid submissions from the same IP trigger account lockouts.

Autonoly runs a real browser with human-like interaction patterns through [Browser Automation](/features/browser-automation), which passes most behavioral analysis. For CAPTCHAs that require human intervention, [Live Browser Control](/features/live-browser-control) lets a human solve the challenge without interrupting the rest of the automation. The agent pauses at the CAPTCHA, notifies the operator, waits for human input, and then resumes filling the form.

### Specific Government Forms Supported

**US DS-160 Visa Application**: 15 pages of form fields with conditional logic that changes based on nationality, visa type, and travel history. The agent handles all visa types (B1/B2, F1, H1B, L1, O1), fills the entire application from structured applicant data, saves progress at each checkpoint, and captures the confirmation barcode page.

**IRS e-File System**: Federal tax returns filed through the IRS e-file portal. The agent handles form selection (1040, 1040-ES, 1099), fills financial data from prepared worksheets, handles the PIN-based electronic signature, and captures the acceptance confirmation. For preparers filing multiple returns, the workflow processes each return independently with configurable delays between submissions.

**State Business Registration**: California's bizfile, Delaware's Division of Corporations, New York's Department of State, and similar portals. Each state has a unique registration form with different fields, document upload requirements, and payment flows. The agent adapts to each state's portal layout using vision-based field detection.

**SBA Loan Applications**: Multi-page applications with financial data entry, business plan uploads, and conditional sections based on loan type and business structure. The agent handles document uploads (financial statements, tax returns, business plans) and waits for slow server-side validation between pages.

### Accuracy and Reliability

Government form automation has a lower first-attempt success rate than standard web forms due to the complexity involved:

| Form Type | First-attempt Success | After Auto-Recovery | Notes |
|---|---|---|---|
| DS-160 Visa | 88.5% | 94.8% | Conditional cascades are the main failure mode |
| IRS e-File | 91.2% | 96.5% | Format validation catches most issues |
| State Business Reg | 90.8% | 95.2% | Varies significantly by state |
| SBA Loan | 87.3% | 93.5% | Complex multi-page with document uploads |

The auto-recovery system reads error messages, reformats data, and retries. For high-stakes filings, enabling [Live Browser Control](/features/live-browser-control) for the first few runs lets a human verify accuracy before switching to fully unattended mode.

### Security Considerations

Government form data frequently includes sensitive information — Social Security numbers, passport numbers, financial data, and personal identification. All data is encrypted in transit (TLS 1.3) and at rest (AES-256). Browser sessions run in isolated, ephemeral containers destroyed after each workflow execution. Sensitive fields are redacted from all logs, screenshots, and execution history.

For immigration and tax preparers handling client data, Autonoly provides data processing agreements and region-specific execution environments for data residency requirements. Where you handle the personal data of individuals in the European Union, those residency and processing controls are what let you stay aligned with the [General Data Protection Regulation](https://gdpr.eu), which treats government-filing data — identity documents, financial details, immigration status — as exactly the kind of sensitive personal data that demands a lawful basis and strict access controls. Full audit trails are available in the [Security](/features/security) dashboard.

### Authorization and Accuracy Obligations

Filing government forms on someone else's behalf carries obligations that ordinary form automation does not. For tax returns, immigration petitions, and benefit applications, the preparer is often legally accountable for the accuracy of what is submitted, and many forms require a preparer identification or an attestation that the information is true to the best of your knowledge. Automation does not transfer that responsibility — it concentrates it, because one misconfigured workflow can replicate the same error across dozens of filings. The practical safeguard is a documented authorization for every applicant: a signed engagement letter or power-of-attorney form that establishes you are permitted to file on their behalf, retained alongside the submission record. Configure the workflow so that any field the agent cannot populate with high confidence is escalated rather than guessed, and reserve the final submit action on high-stakes filings — visa applications, tax returns, loan applications — for a human review step. This keeps the speed benefit of automation for data entry while preserving human judgment at the point of legal consequence.

### Advanced Usage and Edge Cases

Government portals are the most adversarial environment for form automation, so the edge cases are worth anticipating. Many public-sector portals are required to meet accessibility standards based on the [Web Content Accessibility Guidelines](https://www.w3.org/WAI), and those well-labeled, semantically clear forms are precisely the ones the agent fills most reliably — though plenty of legacy government systems fall short, which is where visual detection and a review checkpoint earn their keep. Cascading dropdowns are a recurring trap: selecting a country populates a state list, which populates a city list, each loaded by a separate request, and the agent must wait for each to resolve before selecting the next rather than racing ahead into an empty list. Many portals also enforce idempotency poorly — a network hiccup during submission can leave you unsure whether a filing went through, so build a verification step that checks for a confirmation number or receipt before the workflow marks the filing complete, and never blindly resubmit. Scheduled-window portals add another wrinkle: some government systems are only available during business hours or impose nightly maintenance windows, so pair the workflow with [Scheduled Execution](/features/scheduled-execution) to run inside the portal's operating hours. For agencies processing seasonal surges — tax season, open enrollment, visa lottery periods — stagger batches and respect throttling rules; a government portal that locks an account for excessive activity can stall an entire firm's filing pipeline at the worst possible time.

### Recordkeeping and Audit Trails

Government filings are uniquely audit-sensitive: years after a submission, a client, an auditor, or the agency itself may ask you to prove exactly what was filed and when. Build the workflow so it captures and stores the confirmation number, receipt, or stamped copy returned by each portal, writing those artifacts back to a [Database](/features/database) or document store keyed to the applicant. Pair this with the field-level submission history Autonoly records, and you have an end-to-end account of every filing — the source data, the values submitted, the timestamp, and the agency's acknowledgment. For firms, this recordkeeping is not just good hygiene; it is often a professional or regulatory requirement, and it is the difference between resolving a disputed filing in minutes and reconstructing it from memory. Schedule periodic reconciliation runs that compare your internal queue of intended filings against the confirmations actually received, so any submission that failed silently is caught and re-filed well before a deadline, rather than discovered when an applicant calls to ask why their petition was never processed.

### Best Practices for Government Forms

- **Test each form type with Live Browser Control first.** Government portals have unique quirks that only surface during real interaction. Watch the agent fill one complete application before running a batch.
- **Build in delays between submissions.** Government portals throttle rapid submissions. Add 60-120 seconds between filings to prevent account lockouts.
- **Save progress checkpoints.** For multi-page forms, configure the workflow to save data at each page boundary. If a session timeout occurs, the agent resumes from the last checkpoint.
- **Validate data format before submission.** Run applicant data through [Data Processing](/features/data-processing) to match each portal's specific format requirements. A wrong date format causes a rejection that wastes the entire form-filling effort.
- **Keep a human in the loop for the first batch.** Government filings have real consequences — a rejected visa application or incorrect tax filing creates problems beyond a failed automation run.

Explore more about the tools and techniques used in this workflow: [Automate Form Filling from Excel](/blog/automate-form-filling-from-excel), [No Code Automation Guide](/blog/no-code-automation-guide), [Browser Automation](/features/browser-automation), [Live Browser Control](/features/live-browser-control).

Government Portals

Government portals are the ultimate stress test for form automation. Session timeouts, conditional field cascades, strict validation, and aggressive bot detection. Here is how to handle all of it.

How to Automate Government Form Filing Without Losing Your Mind

Specify the government form and portal — DS-160, IRS e-file, state business registration, SBA loan application — and provide the applicant data in a spreadsheet.

The agent logs into the government portal, handles CAPTCHA challenges, navigates multi-page forms, and fills fields using vision-based detection that works regardless of the portal's dated HTML.

AI navigates the portal

When selecting a country triggers province, district, and city dropdowns that each load from the server, the agent waits for each to populate and selects the correct option.

Conditional fields are handled

The agent verifies the submission was accepted, captures a confirmation number and screenshot, and logs the result. Session timeouts are detected and recovered from automatically.

Submission verified

Automate government form filling — visa DS-160, IRS e-file, state business registration, SBA loans. Handle session timeouts, conditional fields, and strict validation automatically.

Automate Government Forms: Visa DS-160, Tax, Business Registration | Autonoly

Automate Government Form Filing

Automate filling visa applications (DS-160), tax filings, business registrations, and other government portal forms from structured data.

Spreadsheet Data

## Why Automate Insurance Claims Forms?

Insurance adjusters submit claims across multiple carrier portals daily. A single property damage claim might require: claimant information, policy details, incident description, damage assessment, contractor estimates, photo uploads, and an adjuster's digital signature. Each carrier's portal structures this differently — some use a single long form, others split it across 8-10 pages. Manually entering the same claim data into three different carrier portals for a multi-carrier insured takes 45-90 minutes of repetitive work.

The real complexity in insurance forms is not the data entry itself — it is the conditional logic. Every carrier portal has branching paths that depend on the specifics of each claim:

### Conditional Field Cascades in Insurance Forms

- **Damage threshold**: If the claimed amount exceeds a carrier-specific threshold (often $5,000 or $10,000), additional sections appear for detailed line-item breakdown, independent adjuster assignment, and sometimes salvage value assessment.
- **Third-party involvement**: If the incident involves a third-party (another vehicle, a neighbor's property), liability forms appear requiring the third party's insurance information, police report numbers, and witness statements.
- **Policy type**: A homeowner's claim shows different sections than a renter's or commercial property claim. Auto claims branch based on collision vs. comprehensive vs. liability-only.
- **Prior claims**: If the policyholder has previous claims on record, the portal may require a claims history explanation section.
- **Geographic location**: Claims in certain states trigger additional regulatory forms — Florida's Assignment of Benefits form, Louisiana's hurricane supplemental form, California's earthquake endorsement.

The AI navigates these conditional paths based on the claim data, filling only the sections that are relevant to each specific claim. It does not need to be pre-configured for every branching path — it reads the field labels and section headers as they appear and maps the appropriate data.

### Multi-Page Form Navigation

Insurance claim portals typically split the submission into 5-10 pages:

1. **Claimant Information** — name, contact, policy number
2. **Incident Details** — date, time, location, description
3. **Damage Assessment** — type of damage, affected areas, estimated cost
4. **Supporting Documentation** — photo uploads, police reports, contractor estimates
5. **Additional Parties** — witnesses, third-party insurance, legal representation
6. **Review & Submit** — summary page with digital signature

The agent navigates through each page, waits for dynamic content to load, and handles the "Save & Continue" buttons that some portals use between pages. If a page fails validation, the agent reads the error messages, corrects the flagged fields, and retries submission for that page before proceeding.

### Document Upload Handling

Insurance claims require multiple document types:

- **Photos**: Damage photos, property photos, scene photos
- **PDF Reports**: Police reports, fire department reports, medical reports
- **Contractor Estimates**: Repair estimates in PDF or image format
- **Prior Documentation**: Previous inspection reports, maintenance records

The agent handles both traditional file upload buttons and drag-and-drop upload zones. Files can come from cloud storage, a local folder path, or URLs. The agent validates file type requirements (some portals only accept PDF, others accept images) and waits for each upload to complete before proceeding.

For claims that require [PDF reports](/features/pdf-ocr), Autonoly can extract data from PDF documents — adjuster reports, medical records, contractor estimates — and use that extracted data to fill form fields automatically. This eliminates the manual step of reading a PDF, finding the relevant numbers, and typing them into the portal.

### Carrier-Specific Adaptations

Each insurance carrier's portal has unique characteristics:

- **State Farm**: Clean, modern React-based forms with standard field types. Relatively easy to automate with good field labeling.
- **Allstate**: Multi-step wizard with heavy client-side validation. The portal validates each field on blur (when you click away), which the agent handles by properly tabbing between fields.
- **Nationwide**: Older portal with table-based layouts and nested iframes for certain sections. The agent navigates iframe boundaries using visual detection.
- **Progressive**: Fast, modern interface but aggressive session management. The agent monitors session state and re-authenticates when needed.
- **USAA**: Requires 2FA on every login. [Live Browser Control](/features/live-browser-control) handles the 2FA prompt, or TOTP secrets can be stored in the encrypted vault for automatic code entry.

### Processing Speed and Accuracy

| Claim Type | Fields | Pages | Time per Claim | First-attempt Success |
|---|---|---|---|---|
| Simple auto collision | 15-20 | 4-5 | 2-3 minutes | 95.2% |
| Property damage (below threshold) | 20-30 | 5-7 | 3-5 minutes | 93.8% |
| Property damage (above threshold) | 35-50 | 7-10 | 5-8 minutes | 91.5% |
| Third-party liability | 40-60 | 8-10 | 6-10 minutes | 89.7% |

Auto-recovery brings effective success rates above 95% for all claim types.

### Compliance and Data Protection

Insurance claims are among the most sensitive data any business handles. A single claim file can contain a claimant's full name, home address, government ID numbers, financial details, medical records, and photographs of their property and injuries. When you automate the movement of this data into carrier portals, you become responsible for protecting it at every step — in transit, at rest, and in the audit trail. If any of your claimants are located in the European Union or you process their personal data, the [General Data Protection Regulation](https://gdpr.eu) applies, which means you need a lawful basis for processing, a defined retention period, and the ability to honor data-subject requests such as access and erasure. In the United States, claims that touch medical information may fall under HIPAA, and many states impose their own breach-notification and insurance-data-security requirements. Autonoly's encrypted vault stores carrier credentials and 2FA secrets without exposing them in workflow logs, and every form submission is recorded with a timestamp and field-level history so you can demonstrate exactly what data was sent to which carrier and when. Configure retention on the underlying claim spreadsheets and uploaded documents so that supporting evidence is purged on the schedule your policy and regulators require, rather than accumulating indefinitely.

Equally important is consent and accuracy. Because the agent fills carrier forms on the policyholder's behalf, you should retain the source authorization — the signed claim form or the recorded instruction — that establishes the claimant agreed to the submission. Build a verification step into high-value claims so a human adjuster reviews the populated form before the agent clicks submit; an erroneous figure on an above-threshold property claim can trigger fraud review or a coverage dispute that takes far longer to unwind than the review would have taken. Treat the automation as a tireless data-entry assistant operating under adjuster supervision, not as an unsupervised decision-maker.

### Advanced Usage and Edge Cases

Real-world claim batches rarely run cleanly end to end, and the value of automation shows most in how it handles the exceptions. A common edge case is the partially complete claim: the source data is missing a contractor estimate or a police report number that a particular carrier marks as required. Rather than failing the entire submission, configure the agent to fill everything it can, save the carrier's draft if the portal supports it, and route the claim to a "needs attention" queue with the specific missing fields flagged — so an adjuster can supply the gap and resume rather than restart. Another frequent edge case is carrier portal drift: insurers periodically redesign their submission flows, rename sections, or insert new mandatory disclosures. Because the agent reads field labels and section headers as they appear rather than relying on fixed coordinates, it adapts to minor layout changes automatically, but a major redesign should still trigger a quick re-test through [Live Browser Control](/features/live-browser-control) before the next batch.

For multi-carrier insureds, sequence matters. Submitting the same incident to a primary and an excess carrier often requires the primary's claim number on the secondary submission, so chain the workflow with [Logic & Flow](/features/logic-flow) to capture the confirmation number returned by the first portal and inject it into the second. Catastrophe events — hurricanes, wildfires, hailstorms — produce surges of structurally similar claims; for these, build a templated claim profile that pre-fills the shared incident details (event date, peril type, affected region) so adjusters only supply the per-property specifics. Finally, watch for portals that throttle or temporarily lock accounts after rapid submissions: stagger batches, respect each carrier's rate expectations, and let the agent back off and retry on transient errors rather than hammering a portal that has flagged the session.

A further edge case worth planning for is the supplemental or follow-up filing. Claims are rarely a single submission — an adjuster often returns later to add a contractor's revised estimate, upload additional damage photos, or respond to a carrier's request for more information. Configure the workflow to locate an existing claim by its carrier claim number and append to it rather than creating a duplicate, and keep the original submission's field history on hand so the supplement is consistent with what was filed before. For catastrophe surges, also build a reconciliation step that compares your internal list of claims to the confirmations actually returned by each carrier, so a claim that failed to submit during a high-volume event is caught and re-filed promptly rather than slipping through while attention is elsewhere.

### Best Practices

- **Standardize claim data format.** Create a master spreadsheet template with all possible fields across your most common carriers. Use [Data Processing](/features/data-processing) to normalize dates, currency amounts, and phone numbers to each carrier's format.
- **Upload photos in batch before starting.** Pre-upload all claim photos to an accessible location (cloud storage or Autonoly assets). The agent references them by filename during the form-filling process.
- **Test each carrier portal separately.** Each carrier has unique quirks. Run one claim through each portal with [Live Browser Control](/features/live-browser-control) to verify the agent handles that portal correctly before batching.
- **Build in delays between claims.** Some carrier portals flag rapid sequential submissions. Add 60-90 seconds between claims on the same portal.

### Accessibility and Portal Variability

A practical reality of insurance automation is that carrier portals vary enormously in quality. Some are modern, accessible, and well-labeled; others are aging systems with unlabeled fields, table-based layouts, and inconsistent markup. The agent's reliance on visible labels and accessible field semantics means it performs best on portals that follow the [Web Content Accessibility Guidelines](https://www.w3.org/WAI) — the same standards that make a form usable for a person relying on a screen reader also make it readable for an AI agent. Where a portal is poorly built, the agent leans on visual detection and contextual reasoning to compensate, but those are the portals most likely to need an occasional human-in-the-loop pass through [Live Browser Control](/features/live-browser-control). Tracking first-attempt success rates per carrier over time tells you which portals are reliable enough for fully unattended batches and which warrant a review checkpoint, letting you tune the level of oversight to the actual risk of each carrier rather than applying a single blanket policy.

Explore more about the tools and techniques used in this workflow: [Automate Form Filling from Excel](/blog/automate-form-filling-from-excel), [No Code Automation Guide](/blog/no-code-automation-guide), [PDF & OCR](/features/pdf-ocr), [Browser Automation](/features/browser-automation).

Carrier Portals

Insurance adjusters submit claims across multiple carrier portals, each with different form structures. Automate the entire process — from claimant data entry to document uploads and conditional field handling.

How to Automate Insurance Claims Form Submission Across Carriers

Specify the carrier portal and claim type. Provide claim data in a structured format — claimant information, policy details, incident description, damage assessment, and supporting documents.

The agent logs into the carrier portal, navigates to the claims submission form, and identifies all fields across every page of the multi-step form.

When damage exceeds a threshold, additional itemization sections appear. Third-party liability triggers more forms. The AI fills only the sections relevant to each specific claim.

Conditional sections handled

Photos, PDF reports, contractor estimates, and supporting documents are attached at the appropriate upload steps. The claim is submitted and the confirmation number captured.

Documents uploaded & submitted

Automate insurance claims form submission across carrier portals. Handle multi-page forms, conditional fields, document uploads, and cross-carrier differences automatically.

Automate Insurance Claims Forms: Multi-Page, Multi-Carrier | Autonoly

Automate Insurance Claims Form Submission

Automate filling multi-page insurance claims across carrier portals — claimant info, policy details, damage assessments, and document uploads.

Claims Data

## Why Automate Job Application Forms?

Staffing agencies and active job seekers fill out dozens of applications per week across different applicant tracking systems. Each ATS has a different form structure, but the underlying data is the same: name, contact info, work history, education, skills, resume upload, and sometimes a cover letter. Manually filling the same information into 30 different application portals each week is a staggering waste of time.

The challenge is not just volume — it is complexity. Greenhouse, Lever, and Workable all use custom React-based application forms with dynamic sections. Greenhouse in particular generates unique field IDs on every page load, making selector-based automation completely useless. A traditional macro recorder saves something like `#app > div.form-container > div:nth-child(3) > input.MuiInput-root`, and the next time Greenhouse regenerates the page, that selector is invalid.

### How AI Form Filling Handles Job Applications

Autonoly's AI takes a fundamentally different approach from selector-based tools. Instead of memorizing DOM addresses, the AI reads the field labels the way a human does — "First Name," "Years of Experience," "LinkedIn Profile URL," "Are you authorized to work in the US?" — and fills them regardless of the underlying HTML implementation.

The agent uses [Browser Automation](/features/browser-automation) to open a real browser, navigate to the application form, and interact with it exactly as a human would. It waits for slow-loading dropdowns, handles conditional sections that appear based on previous answers, and adapts to the specific quirks of each ATS platform.

For each application, the workflow:

1. Opens the job listing URL from your spreadsheet
2. Navigates to the application form
3. Fills all standard fields from candidate data
4. Uploads the resume file in the required format (PDF, DOCX)
5. Generates a tailored cover letter using [AI Content](/features/ai-content) that references the specific job description and company
6. Answers screening questions based on candidate qualifications
7. Submits and captures a confirmation screenshot as proof

### Platform-Specific Handling

**Indeed** uses a multi-step application flow with pre-filled data from your Indeed profile. The agent handles the profile merge — using your spreadsheet data over Indeed's saved data when they conflict — and navigates through Indeed's screening questions, which vary by employer.

**LinkedIn Easy Apply** is deceptively simple on the surface but includes employer-specific custom questions on roughly 40% of postings. The agent detects these custom fields, maps them to your candidate data or generates appropriate answers, and handles the "Additional Information" free-text field with a contextual response.

**Greenhouse** is the most technically challenging ATS. Its React-based forms generate new element IDs on every render cycle. Traditional automation breaks immediately. The AI reads field labels visually — "Upload your resume," "Expected salary range," "How did you hear about us?" — and interacts with each field based on its type and label, not its DOM position.

**Lever** and **Workable** use similar React-based architectures with their own quirks — Lever's file upload uses a custom drag-and-drop zone, and Workable's multi-step flow sometimes loses state on slow connections. The agent handles both by watching for visual cues (upload progress indicators, step completion markers) before proceeding.

### Handling Common Failure Modes

Job application forms have specific failure patterns that the agent handles automatically:

- **Resume format rejection**: The form accepts only PDF but the uploaded file is DOCX. The agent detects the rejection, converts the file format, and retries.
- **Character limit on cover letters**: Different ATSes have different character limits (500, 1000, 2000 characters). The AI Content feature generates cover letters that fit within the specific platform's limit.
- **Screening question mismatches**: "Are you authorized to work in the US?" with a Yes/No dropdown, but the candidate data has "Yes - H1B" as the value. The agent maps this to the closest valid option.
- **Session timeouts**: Some ATSes timeout after 10-15 minutes. The agent detects the timeout, re-authenticates, and resumes from where it left off.
- **Duplicate application detection**: Many platforms reject duplicate applications. The agent checks for "You've already applied" messages and skips to the next application instead of failing.

### Processing Speed and Accuracy

On Autonoly's cloud infrastructure:

- **Simple applications (5-10 fields)**: 30-60 seconds per submission including resume upload
- **Complex applications (15-30 fields, screening questions)**: 2-4 minutes per submission
- **Batch throughput**: 40-80 applications per hour for simple forms, 15-30 for complex ATSes

Field detection accuracy by platform:

| Platform | Field Detection Rate | Notes |
|---|---|---|
| Indeed | 97.5% | Standard HTML with some React components |
| LinkedIn Easy Apply | 96.8% | React-based with custom question sections |
| Greenhouse | 95.4% | Dynamic IDs, fully React, custom components |
| Lever | 96.2% | React with custom file upload zones |
| Workable | 96.9% | Multi-step React forms |

### Data Source Setup

Pull candidate data from a [Google Sheets](/integrations/google-sheets) spreadsheet or [Database](/features/database). Each row represents one application with columns for:

- **Job URL** — the direct link to the application form
- **First Name / Last Name** — candidate identity
- **Email / Phone** — contact information
- **Resume File** — path or link to the resume file
- **Cover Letter** — pre-written or "auto-generate" to use AI Content
- **Work History** — formatted for the most common ATS fields
- **Education** — degree, institution, graduation year
- **Skills** — comma-separated list
- **Screening Answers** — responses to common screening questions

The workflow processes each row independently — if application #12 fails due to a duplicate, it logs the error and continues with #13.

### Integration With Other Features

- **[AI Content](/features/ai-content)** — generate tailored cover letters for each application using the job description
- **[Data Processing](/features/data-processing)** — clean and format candidate data before it reaches the form
- **[Database](/features/database)** — track which applications have been submitted, their status, and outcomes
- **[Scheduled Execution](/features/scheduled-execution)** — submit applications daily as new job postings appear
- **[Data Extraction](/features/data-extraction)** — scrape job listings to build your application queue automatically

### Best Practices

- **Test with Live Browser Control first.** Watch the agent fill one application in real time using [Live Browser Control](/features/live-browser-control). Catch field mapping errors before running a batch.
- **Format your data before it reaches the form.** Phone numbers, dates, and addresses should match the target form's expected format. Run them through [Data Processing](/features/data-processing) first.
- **Do not exceed 50 applications per day per account.** Most job boards throttle rapid submissions. Space applications 2-5 minutes apart for safety.
- **Verify submissions by checking confirmation pages.** Some ATSes silently fail — the submit button triggers a JavaScript error without showing an error message.

### Compliance, Honesty, and Fair Hiring

Automating job applications raises questions that pure data-entry automation does not, and it is worth being deliberate about them. First, accuracy and honesty: the data the agent submits — work history, dates, certifications, salary expectations — must be truthful. The automation should fill applications from a verified candidate profile, never fabricate or embellish answers to screening questions, and flag any field where the source data is ambiguous rather than guessing. Misrepresentations on an application can void an offer or, in regulated industries, carry legal consequences, so treat the agent as a faithful transcriber of accurate information rather than a tool for gaming filters. Second, respect each job board's terms of service; platforms like LinkedIn — whose [User Agreement](https://www.linkedin.com/legal/user-agreement) governs automated activity — and Indeed set rules on automated access, and high-volume submission can trigger account restrictions, which is why the practical cap of 50 applications per day exists.

It is equally worth understanding the hiring-side context your application enters. Employers in the United States are bound by anti-discrimination law enforced by the U.S. [Equal Employment Opportunity Commission](https://www.eeoc.gov), and many now run applications through automated screening of their own. Voluntary self-identification questions about race, gender, disability, or veteran status exist for EEO reporting and are always optional — configure the agent to leave them blank or to submit only the responses the candidate has explicitly chosen, never an inferred or default value. Keeping a clean separation between factual application data and protected-characteristic fields protects both the candidate and your own compliance posture, and it ensures the automation never becomes the source of a discrimination concern.

### Advanced Usage and Edge Cases

Beyond the happy path, several patterns recur at scale. Knockout questions — "Are you authorized to work in this country?", "Do you have 5+ years of experience with X?" — gate the rest of the application, and a wrong answer can auto-reject a qualified candidate. Map these explicitly from the candidate profile and route any application whose knockout answers are uncertain to a manual queue. Resume-and-cover-letter tailoring is another advanced use: chain [AI Content](/features/ai-content) to generate a role-specific cover letter from the job description before the agent attaches it, so each submission reads as bespoke rather than templated. Watch for ATSes that parse an uploaded resume and then ask you to correct the auto-extracted fields — the agent should reconcile the parsed values against your authoritative profile, not blindly accept the parser's interpretation. Finally, build a deduplication check using [Logic & Flow](/features/logic-flow) so the agent never submits the same role twice across job boards that syndicate the same posting, which both wastes effort and looks careless to recruiters who see duplicate applications.

### Scaling and Tracking Applications

Once the basics are reliable, the bottleneck shifts from filling forms to managing the pipeline of applications themselves. Feed the agent a live queue of postings by chaining [Data Extraction](/features/data-extraction) to scrape new listings that match your criteria, then deduplicate and prioritize them before the form-filling step runs. Write every submission back to a tracking spreadsheet or [Database](/features/database) with the company, role, board, timestamp, and confirmation status, so you have a single source of truth for follow-up rather than a scattered memory of where you applied. Layer in [Scheduled Execution](/features/scheduled-execution) to submit a measured number of applications each day within the platform's limits, which both respects throttling rules and produces a steadier, more natural application cadence than a single large burst. For job seekers and staffing teams alike, this turns a tedious manual chore into a monitored, auditable process where the metric that matters — applications submitted and confirmed per day — is visible at a glance, and where any board that starts rejecting submissions surfaces immediately in the log instead of silently failing.

Explore more about the tools and techniques used in this workflow: [Automate Form Filling from Excel](/blog/automate-form-filling-from-excel), [No Code Automation Guide](/blog/no-code-automation-guide), [Browser Automation](/features/browser-automation).

Job Boards

Fill and submit job applications across Indeed, LinkedIn, Greenhouse, Lever, and Workable automatically — with resume uploads, cover letter generation, and submission verification.

How to Automate Job Application Form Filling at Scale

Tell the AI agent which job boards and application forms to target, and provide your candidate data in a spreadsheet — name, contact info, work history, education, skills.

The agent opens each application, identifies form fields by reading labels (not CSS selectors), and fills in the data — handling dynamic fields, custom dropdowns, and multi-step wizards.

AI navigates & fills forms

Resumes are uploaded in the required format. Cover letters are generated using AI Content, tailored to each specific job posting and company.

Documents are uploaded

The agent verifies each submission by checking for confirmation pages, captures a screenshot as proof, and logs the result. Failed submissions are flagged for review.

Submissions verified

Automate filling job application forms across Indeed, LinkedIn, Greenhouse, Lever, and Workable. Upload resumes, generate cover letters, and submit applications at scale.

Automate Job Application Forms: Indeed, LinkedIn, Greenhouse | Autonoly

Automate Job Application Form Filling

Automatically fill and submit job applications on Indeed, LinkedIn, Greenhouse, Lever, and Workable from a spreadsheet of candidate data.

## The Universal Form Automation Solution

Most form automation needs do not fit neatly into a category like "job applications" or "government forms." You might need to fill out product registrations, survey responses, event sign-ups, vendor onboarding forms, compliance questionnaires, or any of the thousands of web forms that businesses interact with daily. This is the general-purpose form automation workflow that handles any web form on any website.

### How AI Form Filling Differs from Auto-Fill

Chrome's built-in auto-fill stores your name and address and pastes them into checkout forms. That covers maybe 5% of real form work. The other 95% — business forms, internal tools, legacy enterprise systems, partner portals — requires understanding form structure, handling conditional logic, uploading documents, and recovering from validation errors.

Autonoly's AI form automation opens a real browser, navigates to the form, reads the field labels the way a person would, fills in the data from your spreadsheet or database, handles the weird date picker, waits for the slow dropdowns, clicks Next on multi-step wizards, and repeats until the confirmation page appears. Then it moves to the next row.

### Why Traditional Automation Breaks

Most form automation tools work by recording CSS selectors. You click a field, the tool saves something like `#app > div.form-container > div:nth-child(3) > input.MuiInput-root`, and next time it tries to find that exact selector. This approach is brittle by design:

- **CSS selectors are a house of cards.** A developer renames a CSS class, wraps a form in a new `div`, or upgrades from Material UI v4 to v5, and every recorded selector becomes invalid.
- **Modern frameworks make it worse.** React, Angular, and Vue generate DOM dynamically — field IDs change on every render cycle. Shadow DOM in web components creates encapsulated subtrees that traditional selectors cannot pierce.
- **Bot detection is getting smarter.** Cloudflare Turnstile, reCAPTCHA v3, and hCaptcha run behavioral analysis. Scripts that fill fields instantly and in tab order get flagged immediately.

### Vision-Based Field Detection

The AI renders the page in a real browser and analyzes the visual layout. It identifies form fields by their labels ("First Name," "Date of Birth," "Upload your resume"), their position relative to other elements, and their visual appearance. This works regardless of the underlying HTML structure.

A field labeled "Full Name" is recognized as a name field whether it is a plain `<input>`, a Material UI `TextField`, a Chakra UI `Input`, a custom web component, or a Salesforce Lightning `lightning-input`. The AI does not care about the implementation — it reads the label. Forms that follow the [Web Content Accessibility Guidelines](https://www.w3.org/WAI) from the W3C, with properly associated labels and clear field semantics, are the easiest for the agent to fill accurately — the same characteristics that make a form usable for a person relying on a screen reader make it legible to an AI agent.

### Self-Healing When Layouts Change

Because the AI identifies fields by label and context rather than by CSS selector, it naturally adapts when a website updates its layout. If a form redesign moves the "Email" field from the second row to the third row, or wraps it in a new container div, the AI still finds it — because it still says "Email."

This self-healing is not a bolt-on feature. It is the natural consequence of vision-based detection. There is nothing to "heal" because nothing "broke."

### All Input Types Supported

The AI handles every form input type you will encounter:

- **Text inputs** — single-line and multi-line, with format detection (email, phone, URL)
- **Dropdowns** — standard HTML `<select>`, custom JavaScript dropdowns, searchable dropdowns, and multi-select
- **Checkboxes and radio buttons** — including grouped selections and toggle switches
- **File uploads** — both `<input type="file">` and drag-and-drop upload zones
- **Date pickers** — calendar widgets, date input fields, and custom date picker components
- **Rich text editors** — TinyMCE, CKEditor, Quill, and other WYSIWYG editors
- **Sliders and range inputs** — drag to specific values
- **Color pickers** — hex input or visual selection
- **Signature fields** — digital signature pads

### Multi-Step Form Navigation

Many forms span multiple pages or steps. The AI navigates through each step:

1. Fills all fields on the current page
2. Validates that all required fields are complete
3. Clicks the Next/Continue button
4. Waits for the next page to fully load (including dynamic content)
5. Fills the next page and repeats
6. On the final page, reviews the summary (if present) and submits

The agent tracks progress through the wizard and can resume from the last completed step if a session timeout or error occurs.

### Handling CAPTCHAs

For simple image CAPTCHAs and basic challenge-response prompts, the AI has built-in solving capabilities. For reCAPTCHA v2, the real browser with human-like interaction patterns passes the behavioral analysis in most cases. For difficult CAPTCHAs, two fallback options:

1. **[Live Browser Control](/features/live-browser-control)** — pause and notify you so you can solve it manually
2. **Third-party solving service** — route the challenge to a CAPTCHA-solving API via [API & HTTP](/features/api-http)

### Error Recovery

When a form submission fails, the agent follows a specific recovery sequence:

1. Read error messages — both inline field errors and page-level error banners
2. Identify the failing fields
3. Diagnose the cause — format mismatch, missing required field, invalid option
4. Apply correction — reformat data, select the closest matching option
5. Retry the submission
6. Escalate if needed — after two failed retries, flag for human review

### Accuracy and Speed Benchmarks

| Form Type | Field Detection Rate | Time per Submission | Notes |
|---|---|---|---|
| Standard HTML forms | 99.2% | 8-15 seconds | Plain inputs, selects, textareas |
| React / Vue / Angular forms | 97.5% | 12-20 seconds | Dynamic IDs but readable labels |
| Shadow DOM / Web Components | 95.4% | 15-30 seconds | Visual detection fallback |
| Legacy enterprise forms | 96.5% | 20-45 seconds | Weird markup but stable layouts |
| Multi-step wizards (3-5 pages) | 95.0% | 1-3 minutes | Includes navigation time |

### Cross-Session Memory

When the AI successfully fills a complex form, it remembers the approach — which fields required special handling, what format the date picker expected, whether dropdowns needed a search query or a click-scroll-select sequence. On subsequent runs against the same form, it applies these learned behaviors immediately. The first run might take a few seconds of analysis per field. By the tenth run, the AI handles each field without hesitation.

### Setting Up a Form Automation Workflow

**Step 1: Prepare your data.** Create a spreadsheet with columns matching the form fields, or connect to a [Database](/features/database). Clean your data with [Data Processing](/features/data-processing) — normalize phone formats, validate emails, standardize dates.

**Step 2: Create the workflow.** In the [Visual Workflow Builder](/features/visual-workflow-builder), add a data source node (Google Sheets, CSV, or database) and a Form Automation node with the target URL.

**Step 3: Map fields.** The AI auto-detects form fields. Review the mappings and adjust if needed.

**Step 4: Test with one row.** Run with [Live Browser Control](/features/live-browser-control) to watch the agent fill the form. Catch any issues before batching.

**Step 5: Run the batch.** Process all rows. Each processes independently — failures do not stop the batch. Review results in the execution log.

**Step 6: Schedule if recurring.** For forms you fill regularly (weekly reports, monthly filings), use [Scheduled Execution](/features/scheduled-execution) to run automatically.

### Best Practices

- **Format your data before it reaches the form.** The number one cause of submission failures is data format mismatches. Run dates, phone numbers, and addresses through [Data Processing](/features/data-processing).
- **Test with Live Browser Control on the first run.** One test run saves hours of debugging later.
- **Do not assume submission succeeded because the button was clicked.** Configure verification — check for confirmation pages, success messages, or reference numbers.
- **Handle CAPTCHAs up front.** Discover the CAPTCHA strategy before building the workflow, not at runtime when your batch stops.
- **Build in delays for rate-limited sites.** Add 30-60 seconds between submissions for sensitive portals.

### Compliance and Responsible Use

Generic web-form automation is powerful precisely because it works on any site, which makes responsible use a matter of intent rather than capability. Two principles govern almost every legitimate use case. First, respect the target site's terms of service and the signals it sends — robots directives, rate limits, and explicit prohibitions on automated submission exist for a reason, and ignoring them risks account bans and, in some jurisdictions, legal exposure. Use the automation to fill forms you are authorized to fill, on your own accounts or on behalf of users who have asked you to, rather than to flood public forms or evade access controls. Second, mind the data you are submitting. When a form collects personal information — names, emails, addresses, identifiers — you become a data controller for that processing, and where the individuals are in the EU the [General Data Protection Regulation](https://gdpr.eu) requires a lawful basis, purpose limitation, and the ability to honor deletion requests. Keep a clear record of where each form submission's data came from and the consent or contract that justifies it, and avoid repurposing data collected for one form into submissions on another without checking that the original basis still applies.

### Advanced Usage and Edge Cases

The hardest forms reward a few advanced techniques. Dependent and dynamically revealed fields — a "reason for return" textarea that only appears after selecting "Defective," or a tax-ID field that surfaces once you choose "Business" — require the agent to act, observe what changed, and then continue, which is exactly how the vision-based engine operates rather than assuming a fixed field set. File uploads and rich inputs (signature pads, date-range pickers, address autocompletes that must be selected from a suggestion list rather than typed) are common failure points worth testing explicitly with [Live Browser Control](/features/live-browser-control) before a batch. For forms behind authentication, store credentials and any TOTP secrets in the encrypted vault rather than embedding them in the workflow, and let the agent re-authenticate gracefully when a session expires mid-batch. When the same logical record must be submitted across several sites — a change of address pushed to multiple vendors, for instance — chain the steps with [Logic & Flow](/features/logic-flow) so that a confirmation number or status from one submission can gate or inform the next, and so a single failure routes to review instead of silently breaking the chain.

### Integration With Other Features

- **[Data Extraction](/features/data-extraction)** — scrape data from one site and submit it as form entries on another
- **[Database](/features/database)** — store form data and submission results for tracking
- **[Scheduled Execution](/features/scheduled-execution)** — automate recurring form submissions
- **[AI Vision](/features/ai-vision)** — handle complex custom widgets that resist standard interaction
- **[Logic & Flow](/features/logic-flow)** — branch workflows based on form responses or submission results
- **[AI Content](/features/ai-content)** — generate free-text answers, product descriptions, and cover letters
- **[PDF & OCR](/features/pdf-ocr)** — extract data from PDFs to feed into form fields

Explore more about the tools and techniques used in this workflow: [Automate Form Filling from Excel](/blog/automate-form-filling-from-excel), [No Code Automation Guide](/blog/no-code-automation-guide), [Browser Automation](/features/browser-automation).

Any Website

Fill any web form automatically — text inputs, dropdowns, checkboxes, file uploads, date pickers, and CAPTCHAs. The AI reads field labels like a human, adapts to layout changes, and works on any website without configuration.

How to Automate Form Filling on Any Website

Provide the URL of the form you need to fill and your data source — a spreadsheet, database, or manual input. The AI auto-detects all form fields.

The AI identifies every form field by its label, placeholder, and context. It maps your data columns to the appropriate fields automatically — you review and adjust if needed.

AI maps data to fields

The agent fills each form with human-like interaction — variable typing speed, natural pauses, realistic scroll behavior. Multi-step wizards, dynamic fields, and CAPTCHAs are handled automatically.

Forms filled with intelligence

Each submission is verified by checking confirmation pages, success messages, or redirect URLs. Results are logged with screenshots for audit trails.

Submitted & verified

Automate form filling on any website with AI that sees forms like a human. Handles dynamic fields, multi-step wizards, CAPTCHAs, file uploads, and self-heals when layouts change.

Automate Web Form Filling: Any Website, Any Form | Autonoly

Automate Any Web Form Filling

Automate filling any web form — login flows, signup forms, checkout processes, surveys, registrations, and multi-step wizards on any website.

Form Automation Automation

Explore more automation categories

Automate form automation today

Autonoly

Subscribe to Our Newsletter