Customer intake forms that create real records

Q: How do I embed the form on my own website?

Publish it, grant the anonymous identity forms:read and forms:submit on the form's key, then paste the embed snippet into your page. Without that grant the embedded page returns 404.

Build a public intake form that validates input and creates a real customer record — no retyping, no spreadsheet inbox, spam-protected out of the box.

A customer intake form should finish in the system your team already works in. This guide builds one in AxisIQ: a hosted page — or an iframe inside your own site — where a customer or an engineer on site fills in a few fields, and every submission lands in your workspace as a validated record your lists, reports, queues and automations can act on.

By the end you will have a published intake form, a record for each submission, and one thing happening automatically afterwards: an owner assigned, an entry on a board, or a call out to another system you run. Allow about forty minutes, most of it spent deciding what to ask.

What you need before you start

A workspace. Forms is part of it, not a separate product.
Somewhere for intakes to land. An object type — an existing one such as customers, or a new one for leads or service requests. Types and their fields live in Operations.
The questions you ask today, taken from the WhatsApp thread or paper docket you are replacing.

Step 1 — Shape the type first, the form second

This is the step people skip and regret. A form carries no schema of its own: point it at an object type and the builder pulls its questions from that type's field definitions, so anything you mean to capture must exist on the type first.

Add the fields you are missing — phone, site address, preferred callback date, budget band, how they heard about you. Set the real options on your choice lists now (Referral, Instagram, Trade show): they reach the public page as a dropdown, nothing retyped.

No type yet? Create one — it gets the same lists, search, reporting and permissions as everything built in, so "enquiries" is as first-class as "orders".

Step 2 — Create the form and point it at the type

Open Forms, create one, name it and set a key. The key appears in the public URL, so service-request reads better than a random string.

Then set the target. Pointing a form at an object type is what turns a submission into a record. A form can instead target one of your functions, or nothing at all (see the variations below), but for intake the type is the whole point.

Step 3 — Build the fields from the type

Three ways in, all ending in the same place:

Pick from the type. The builder lists its fields; tick the ones you want asked. Key, data type, required-or-not and the choice options come across from the definition.
Build the whole set in one click, then delete what a stranger has no business filling in — internal status, margin, assigned owner.
Let AI draft the field list. Describe the form — "service request form for an appliance repair business" — and review what comes back. It suggests and nothing else: no access to your data, no say in the target, and each field must survive the same checks as one you added by hand.

One failure mode: if a field's key matches nothing on the target type, the submission is stored but no record is created. The builder flags an unknown key while you edit, so do not click past the warning.

Then fix the wording: labels are for the person filling it in, so Where should the engineer come? beats site_address.

Step 4 — Let the validation you already have do the work

There is no second rulebook to configure. Everything a visitor types is checked against the rules already attached to that field — required, email and link formats, allowed options, number ranges, dates. A value that fails is refused with a message the sender can act on, and never lands as a record.

The form keeps its own copy of those rules, taken from the definition the moment you added the field. Tighten the type afterwards and a built form does not follow — re-add the field there too, or it keeps accepting a value the record behind it now rejects.

Mark as required only what you would chase someone for; each one costs completed submissions.

Step 5 — Publish it, then open it to the public

Publishing gives the form a URL of its own plus an embed snippet to drop into your website or help centre as an iframe. Both render the same form and follow your edits.

Publishing is not the same as opening it to the world. Nobody signs in to fill in a public form, so AxisIQ gives those visitors an identity of their own — the anonymous one, which starts with no rights. Until it holds forms:read and forms:submit on the form's key the public link answers 404, published or not. Grant those two in Team & Permissions once per form and the page is live. Unpublish and it goes quiet again — visitors get nothing, not a login wall.

Prefill from the URL when you already know something. Pass a declared field's key as a query parameter and the hosted page opens with it filled in:

/f/<your-org-id>/service-request?source=newsletter&plan=annual

Send a different link per channel and the source arrives with the submission.

Step 6 — Decide what happens after submit

Once a submission is a record, everything the platform already does applies to it.

Assign it. A flow on the new record sets the owner, stamps a follow-up date, or fills a default status.
Queue it. An enquiry can enter a work queue, so the team pulls from one ordered list instead of watching an inbox and you can see how long intakes wait.
Tell another system. A flow can make an outbound HTTP call, so an intake can be pushed to a CRM, a helpdesk or any service that accepts a webhook. That is the honest version of "connect it to anything": you supply the endpoint, the flow calls it.
Notify the team in the app, so whoever is on duty sees it without watching a screen.
Acknowledge the customer. A flow's send-message block can email or WhatsApp a confirmation through the provider account your company connects in Phone & Messages.

Start with one.

Step 7 — Decide who reads the responses

Four rights are held separately per form: seeing it, submitting it, reading what everyone else submitted, and authoring or publishing it. Someone who files a damage report each week rarely needs everybody else's — which is why the public grant in step 5 covers reading the form and sending one in, never the responses. Same permissions model as the rest of the workspace: no second place to manage access.

Step 8 — Test it as a stranger would

Open the public URL in a private window and submit something realistic. Check three things: the record exists with the values you expect, the submission is on the Responses tab, and step 6 ran. Then send a deliberately bad one and confirm you are told what to fix.

When something downstream breaks

Nothing a visitor sends is discarded because a later step failed. What they typed is written down first, so if the record cannot be created or a flow throws, the entry is already on the Responses tab, flagged as failed with the reason — fix the cause, then handle that one by hand.

Whoever filled it in is thanked as usual: they did nothing wrong, and your setup problems are not theirs to read. For a lead form that is the property that matters — a misconfiguration costs a tidy record, never the lead.

Spam, and what it does not stop

Every public form includes a decoy field real visitors never see. Anything that fills it in is dropped, and the sender is thanked anyway: a script told it failed simply tries again with that box left empty. There is also a ceiling of 30 submissions a minute per IP.

That defeats scripted stuffing, and only that. Someone who opens the page and types like a customer is indistinguishable from one, and there is no captcha option today — keep an eye on the Responses tab in the first weeks.

Variations

No target at all. A pure collector — submissions stored and read in the app, all a feedback box needs.
A function instead of a type, for a form with nothing to file: your own JavaScript receives the values.
One form per campaign. Duplicate it, change the key, keep the target type; prefill keeps the channels apart.

What this will not do

Forms only collect. They create new data and never read your records back or edit what you hold, so this is not a portal where a customer maintains their own details. That limit is what makes a form safe to face the open internet.
No file uploads, multi-page forms or conditional logic on public forms today. If you need a document attached, or fields that appear based on earlier answers, a dedicated form tool is better right now.
No payment collection on a form. Taking money is done with payment links.
Responses are read in the app; exporting the log is not available yet.

FAQ

Can I send intake form submissions to my CRM? Yes, with a flow on the created record that makes an outbound HTTP call to your CRM's endpoint. The record is created first, so the lead stays in AxisIQ whether or not the other system accepts it.

How do I embed the form on my own website? Publish it, grant the anonymous identity forms:read and forms:submit on the form's key, then paste the embed snippet into your page. Without that grant the embedded page returns 404.

Can I capture website leads without a separate form tool? Yes. Forms are part of every AxisIQ plan rather than sold separately, and you can try them in the 7-day trial with no card. Each lead is a record in your workspace, not an entry in a form tool you later migrate out of.

Can a customer use the same link later to update their own details? No. A form only ever creates new data — it cannot read or edit existing records, which is deliberate for something published on a public URL.