Build Form Fields
Add fields, steps, mapping, and submission actions in the form builder.
The form builder controls what the submitter sees and what Agiled does with the submission.
Builder Layout
The editor includes:
- Form setup and appearance settings.
- A builder canvas.
- Field tools.
- Preview.
- Submission action controls.
- Save and save-as-template actions.
Add Fields
Add only the fields needed to act on the submission. Shorter forms usually convert better. Use clear field labels so submissions are easy to review later.
Use helper text or placeholders when the answer format matters. For example, tell submitters whether to enter a website URL, a budget range, an order number, or a preferred contact time. Avoid asking for information your team will not use.
Put identity fields near the top when the form creates CRM records. Name, email, company, and phone are easier to validate before asking for longer project or support details.
Required Field Discipline
Make a field required only when the team cannot process the submission without it. Too many required fields reduce completion and can push visitors to submit incomplete information through chat or email instead.
Steps
Use steps when the form is long or when questions belong in separate sections. Keep each step focused on one topic.
Use step titles that explain the topic, such as Contact details, Project scope, Budget, or Support issue. Do not split a short form into steps just for style; extra steps can reduce completion.
Mapping
When a form should create or update a CRM record, map form answers to the right entity fields. Supported mapping areas include contacts, accounts, deals, tickets, and tasks, depending on the submission action.
Test mappings with one private submission before publishing. Confirm the created or updated record contains the expected name, email, owner, status, custom fields, and related account or deal. Mapping mistakes are easier to fix before a form receives real submissions.
For contact and account fields, make sure required identity fields are captured. For deals and tickets, confirm pipeline, stage, status, priority, owner, and related customer fields are populated where the team will work the record.
If a field maps into a custom attribute, confirm the attribute already exists and uses the expected field type. A free-text form answer may not behave like a select option in filters, views, or workflows.
Submission Action
Choose what should happen after submission. For example, a lead form may create a contact or deal, while a support form may create a ticket.
If the form should trigger workflows, make sure the submission action creates the record type that the workflow listens for. A form that only stores a submission will not behave the same as a form that creates a contact, deal, ticket, task, or account.
After changing fields or mappings, submit another private test. Field changes can affect workflows, notifications, saved templates, and downstream reports.
Field Review Checklist
Before publishing, check field labels, required flags, option spelling, mobile layout, mapping, and the created record. If a field affects routing or workflow logic, test the value that should match and one value that should not.
Troubleshooting Field Behavior
If a submission saves but the CRM record is incomplete, review the submission action and field mapping first. If the record is created correctly but workflows do not run, check that the workflow trigger listens to the record type created by the form.
If mobile layout feels long, remove optional fields, group related questions into steps, or move extra context into a follow-up task after submission.