Agiled Docs

Use this guide when a public form should start work automatically.

Start with one small automation and test it with a real form submission before adding branches, delays, or multiple actions. This keeps the form-to-workflow handoff easy to debug.

Before You Start

Create the form fields you need for routing, such as name, email, service, budget, priority, or message.
Decide what the first action should create: a CRM contact, deal, ticket, task, notification, or internal follow-up.
Decide who owns the created work.
Prepare a test submission with realistic values.
Confirm the form is published if the trigger depends on public submissions.

Steps

Create and publish the form.
Submit a test response so you know the field names and sample values.
Open Workflows and create a workflow.
Choose a form submission trigger and select the correct form.
Add one simple action, such as creating a task or sending an internal notification.
Map form fields into the action. For example, use the submitted name and email in the task title or CRM contact fields.
Save the workflow as a draft and run a simulation if the builder supports it.
Publish the workflow.
Submit the public form again and review the workflow run.
Add conditions, delays, or extra actions only after the simple workflow works.

Useful Starter Workflows

Create a CRM contact from every lead form submission.
Create a deal when the submitted budget is above a threshold.
Create a ticket when the form is a support request.
Notify a Slack or email channel when the form has an urgent priority.
Create a project task for onboarding requests.

Map Form Fields Carefully

Use the exact form fields in the workflow action. Required destination fields should always receive a value from the form, a fixed default, or a fallback owner chosen in the action configuration.

Keep internal notes separate from customer-facing messages. A form message can be safe to store in a task description or ticket body, but it may need review before it is sent back to a customer.

When the workflow creates a contact or deal, map the submitter name, email, company, phone, service interest, and message into the right CRM fields. Use the form message as context, but keep the record title readable for the sales or support user who will open it later.

If duplicate contacts are possible, add a review step or duplicate-checking process before creating multiple follow-up records. A form workflow should help the team respond faster, not fill CRM with repeated contacts from the same person.

Test and Debug

After publishing:

Submit the public form with realistic data.
Open the workflow run.
Confirm the trigger payload contains the submitted values.
Open every created record and check ownership, title, status, and due dates.
If the run failed, open the failed step and fix the missing field, permission, or integration setting.

When to Add Conditions

Add conditions after the base flow works. Common conditions are service type, budget, country, priority, or whether the submitter already exists in CRM. Use a single condition first, publish, submit test data for both paths, and then add more branching.

First Live Run Review

After the first real submission, open the created contact, deal, task, ticket, or notification and compare it with the form response. Confirm the right owner, priority, due date, customer-safe description, and source context were applied.

If anything is wrong, pause the workflow before promoting the form more widely. Fix the mapping, submit another test response, and verify the new run before turning on ads, website traffic, or customer announcements.

Create a Workflow From a Form Submission