Forms & Lead Capture

Forms live under Landscapt → Communication → Forms (/crm/communication/forms). The list shows every form in your org. Opening one takes you to its detail page (/crm/communication/forms/[id]), which has three tabs:

• Design — the drag-and-drop field builder.
• Configure — confirmation behavior, notification emails, Account Management, and Tags on Submit.
• Responses — every submission, with a status you can act on.

Once published, the form itself is publicly reachable at /forms/[slug] — no login required. That page is what a visitor actually sees and fills out.

The Design tab groups field types into four categories. Every field can be marked required individually — there's no form-level "require everything" toggle, it's a per-field flag.

Simple

Advanced

Layout

Widget

attachment — lets a visitor upload a file with their submission. See below for the size/type limit that applies to it.

Every field label must be unique. Answers are stored by label, so two fields with the same label would overwrite each other's answer. The builder won't let you save (or publish) a form with two input fields sharing a label — matching is not case-sensitive, so "Email" and "email" clash — and it names the label to fix. Header, paragraph and divider elements are exempt. A form that already had duplicates before this rule keeps saving as long as you don't edit one of those labels, but it can't be republished until one is renamed.

Jump to page rules. On a multi-page form, a rule can send a visitor from one page straight to another. Pages a visitor skips this way are skipped for validation too: a required field on a page they never saw does not block their submission. The server replays the visitor's path from page 1 using their final answers (the same logic the form page uses), so this holds even when the form is submitted directly. Required fields on pages they did pass through, and required fields hidden by a Hide Field rule, follow the usual rules. If jump rules loop back on themselves, every page is treated as visited.

Email fields are also validated on the server: a value that isn't a well-formed email address is rejected with the field's label, not just caught in the visitor's browser.

A complete lead-capture form, built end to end, using only settings covered on this page.

Design tab — fields, in order

1. header — "Request a Free Estimate"
2. text — Full Name, required
3. email — Email, required
4. phone — Phone, required
5. text — Service Address, required
6. select — Service Interested In (Lawn Care, Landscaping, Snow Removal, Other), required
7. textarea — Anything else we should know?, optional

Configure tab

• Confirmation — type message: "Thanks! A member of our team will follow up within one business day to schedule your free estimate."
• Account Management — auto-manage on, matching strategy email. A submission whose email matches an existing client attaches to that client; otherwise a new client is created with status lead.
• Tags on Submit — add tag "Website Lead" to the resulting client, every time.

Publish the form, then share the Direct Link on the site's "Get a Quote" button — see Embedding & sharing for the other two options.

Result: every submission becomes an open ticket immediately, and because auto-manage is on and the email matches cleanly, the response also lands as completed with a lead client already tagged and attached — no manual matching needed. See Responses tab & the review workflow for what changes if auto-manage were off instead.

• Confirmation — what the visitor sees immediately after submitting. Either an on-page message (text you write) or a url redirect to another page (e.g. a thank-you page on your marketing site). A redirect URL must start with http:// or https://; anything else is refused when you save, and the public form falls back to the thank-you message instead of redirecting.
• Email notifications — recipients, from address, subject, and body are all configurable, with merge tags available in subject/body and an "Include a copy" toggle for CC'ing the submitter. Every field on the form is also available as a tag named after its label with punctuation and spaces removed (a field called "How can we help?" becomes [howcanwehelp]). The built-in tags ([formname], [companyname], [submittedname] and so on) always win, so a field labelled "Company Name" will not replace your own company name.
• Account Management — the auto-manage on/off toggle, an update strategy (replace_all or add_new), and a matching strategy (email, name_and_email, name_email_and_company, or custom). This block decides whether a submission gets tied to a client automatically — see What happens on submission for the effect.
• Ticket Settings — every submission creates a ticket by default so your team can follow up. Turn it off if you only want the response, the email notification or the client record, or set the ticket's priority and category (the category defaults to the form's name).
• Tags on Submit — separate add/remove tag lists applied to the resulting client record on every submission.

A form has exactly two statuses: draft and published. Nothing else — no "archived" or "closed" state for the form itself.

To start a new form from an existing one, open the row menu on the Forms list and choose Copy form (requires the Forms edit permission). It creates "<name> (Copy)" with the same fields, pages, rules and Configure settings, always as an unpublished draft with its own link — rules that point at fields are re-pointed at the copied fields. Responses are not copied.

Before a form goes live — from the builder's Publish button or the Forms list row menu — it's checked for things that would make it quietly useless: no questions, Account Management turned on with no email or phone field to match on, an email notification with no recipients, or nothing set up to tell anyone about new submissions. These show as a Publish with warnings? prompt you can accept (Publish anyway). Two fields sharing the same label still hard-blocks publishing from either place.

Three ways to put a published form in front of someone, all built off the same slug.

Every submission does two things immediately (the ticket step only when Ticket Settings is on, which is the default):

1. Creates a CRM ticket with status open.
2. Fires the form_submitted automation trigger — the same event that feeds Communication Automations sequences. See the Automations guide for what you can chain off of it. A Form submitted trigger can be limited to this form, tags the form adds fire Tag added, and the sequence's first step (an auto-reply, say) goes out within seconds of the submission.

What happens next depends on the Account Management setting on that form:

• Auto-manage on — the submission is matched (or a new client is created) using the configured matching strategy, related_client_id is set, and the response status becomes completed. A client created this way starts at status lead, not active.
• Auto-manage off — related_client_id may still get set, but the response status is on_hold pending manual staff review on the Responses tab.

Response status is a separate concept from form status — it applies per submission, not to the form as a whole. Four values exist:

In practice: check the Responses tab for anything sitting at on_hold, decide whether it's a real lead, and either attach it to an existing client, let it create a new one, or mark it spam/ignored to clear it from the queue.

Click a response to open its detail panel, which has these actions:

• Mark resolved — sets completed once you've dealt with it.
• Move back to on hold — undoes any of the status changes.
• Ignore and Mark as spam — move it to the Ignored or Spam filter tab.
• Mark unread — puts the blue unread dot back so it stands out in the list.
• Delete — asks you to confirm, then removes the response from the list. Any client or ticket it created is left alone.

Changing a status or deleting needs the Forms edit permission; marking unread only needs permission to view responses. Creating or updating a client straight from a response is not available yet — attach it by hand from the client record.

Attachment field limit. The server-enforced limit on the attachment field type is 15 MB, images or PDF only — anything larger or a different file type is rejected at submission. Design any form using an attachment field around that limit. Files upload through a rate-limited link created when the visitor picks the file (about 20 uploads per 10 minutes per visitor and form), so a visitor who keeps retrying will be asked to wait a few minutes. Submissions are also size-limited (up to 200 answers, 5,000 characters each), and a lead's email is only saved when it is a valid address.

Public form pages can show a Cloudflare Turnstile challenge before allowing submission — it's opt-in at the environment level, not per-form. Set NEXT_PUBLIC_TURNSTILE_SITE_KEY and TURNSTILE_SECRET_KEY (see .env.local.example) and every public form immediately shows the widget and rejects submissions that don't pass server-side verification. Leave both unset and forms behave exactly as before — no widget, no verification.

• Leads from forms. A lead created from a form gets the submitted address as both its service and billing address, so it can be scheduled and routed once converted, and it fires the Lead created automation trigger.