Salesforce Forms That Write to Leads: Web-to-Lead and Beyond

Updated 30 September 2026

A Salesforce form that writes to Leads sounds like a solved problem. Salesforce has shipped Web-to-Lead for years, and there are dozens of form builders with a Salesforce connector. The trouble starts when the form is more than a contact request: an application with several steps, a document to upload, a consent box that must be ticked, a signature at the end, or a deposit to pay. That is where most routes into Salesforce either stop or turn into three tools stitched together.

This guide covers what Salesforce gives you out of the box, the four common ways teams build forms that create or update Leads, and what to check before you choose one. It is written for Salesforce admins and revenue operations teams in 2026.

What Salesforce gives you out of the box

Web-to-Lead is the built-in option. An admin picks Lead fields in Setup, Salesforce generates an HTML form, and a developer pastes it into the website. Each submission creates a new Lead, assignment rules and auto-response rules can run, and reCAPTCHA can be switched on to cut spam. It is included with Sales Cloud and it works.

What it does not do is just as important:

• It only creates. Every submission is a new Lead; Web-to-Lead never updates the Lead or Contact you already have. A duplicate rule set to block rejects the matching submission instead of merging it, so repeat visitors become either duplicates to clean up or lost submissions.
• It has a daily limit. Salesforce caps Web-to-Lead at 500 leads in 24 hours. Extra submissions wait in a pending queue until the limit resets, which matters for campaigns and events.
• No files, steps or logic. There is no file upload, no multi-step layout, no rule that shows a question only when an earlier answer calls for it, and validation is limited to what the web page adds itself.
• No signature or payment. The form ends at submit. If the applicant needs to sign terms or pay a deposit, that is a separate email and a separate system.
• It looks like HTML from Setup. Styling it to match your brand is a web development task, and every field change means editing the page again.

Four ways to build Salesforce forms that write to Leads

1. Web-to-Lead with your own front end

Many teams keep Web-to-Lead as the transport and build a nicer form on the website that posts to it. This fixes the look but not the limits: still create-only, still no uploads into Salesforce, still no signature. It suits enquiry, demo and newsletter forms, and little else.

2. A form builder with a Salesforce connector

Dedicated form tools such as FormAssembly and Formstack, and general builders with Salesforce integrations, give you drag-and-drop forms, conditional logic and file uploads, and push the answers into Salesforce objects through a connector. They are strong on the form itself. The costs are a separate licence, a connector to maintain, field mapping that lives outside Salesforce, and a hand-off when the applicant must also sign a document or pay: that is usually a second product again.

3. Screen flows on an Experience Cloud site

Salesforce admins can build a screen flow, place it on an Experience Cloud site and let unauthenticated guests complete it. Everything stays on the platform and Flow can create or update any object. The trade-offs are build time, guest user security configuration that has to be done carefully, limited styling, and no e-signature or card payment without adding more apps.

4. An app inside Salesforce that runs form, signature and payment together

The newer approach treats the form as part of the document. The applicant fills in the form, signs the agreement that contains their answers, pays if required, and every answer, file and status lands on the Lead or Contact without a connector. This is how SalesSign Forms work, and the rest of this guide uses it as the worked example.

How the four routes compare

What a Salesforce form looks like in practice

Take a training provider that needs an online application: personal details, an eligibility question, a copy of an identity document, agreement to the terms, and a deposit. With SalesSign the admin builds it like this.

1. Build the form in the document. Drop a Form component onto a page and drag fields in: text, number, date, dropdown or multi-select, radio buttons, checkbox and file upload. Add a second Form component and the application becomes multi-step, one step per component.
2. Map each field to Salesforce. Choose Lead or Contact as the target, then map each field to a compatible field. The picker only offers fields of a matching type: text to text, email, phone, URL or picklist; number to number, currency or percent; date to date or date-time. Answers that have no home on the Lead can go to custom fields on the SalesSign Form Submission record instead.
3. Add the rules. Conditional rules show or hide fields when an earlier answer equals, does not equal, contains, is greater than or is less than a value, and rules can chain. Submission rules must pass before Submit or Sign becomes available, for example “the consent box must be ticked”. Hidden questions are never sent to Salesforce, and every rule is checked again on the server.
4. Publish it. Publishing gives a public application link with an optional closing date and a cap on completed applications. Applicants always see the published version while you keep editing a draft, and every published version is kept.

When an applicant arrives, nothing is saved until they confirm a six-digit code sent to their email. From then on, progress saves on every Next, so they can close the page and resume later. On submit, SalesSign finds the Lead or Contact by that verified email and updates it, or creates one if there is no match, creates a Form Submission record, attaches uploaded files as Salesforce Files and moves the applicant into signing. If the form takes payment, the Sign & Pay checkout follows the signature and a Transaction record links to the Form Submission.

What to check before you choose

1. Does it update or only create? Ask how the tool finds an existing Lead or Contact, and on which field. If the answer is “it creates a new one”, budget for duplicate management.
2. Where do files end up? Uploads should arrive as Salesforce Files on the record, not as links to a third-party storage bucket.
3. Are rules enforced on the server? Client-side validation alone can be skipped. Required consent and eligibility checks should be re-checked when the answers arrive.
4. What happens after submit? If the applicant must sign or pay, count the tools and hand-offs involved. Each one is a place applications stall.
5. Can you see drop-off? Look for step-by-step tracking: started, step reached, abandoned, submitted, signed and paid. That is how you find the question that loses applicants.
6. What is the total cost? Add the form licence, the connector, the signature tool and the payment add-on together, per user or per submission, and compare the all-in figure.

When Web-to-Lead is still the right answer

If the form is a short enquiry, a demo request or a newsletter sign-up, keep Web-to-Lead or your marketing platform’s form. It is free, it is fast and assignment rules handle routing well. Move to something richer when the form becomes an application: steps, files, rules, a signature or a payment. SalesSign Forms are included with the Max plan at £49 per user per month, and every 14-day free trial runs with Max features, so you can build and publish a real form before choosing a plan.