Web forms
Overview
A web form is the embed on somebody else's page that works without a login. It is addressed through its own embed key — no sign-in, no session.
Every submission that is not spam becomes a lead. That is the point of this area: a form should turn into a case, not into an email in a shared mailbox.
Origin is carried along — UTM parameters and referrer sit on the submission and travel into attribution.
Core tasks
Build a form. Define the field schema, store a default origin, use the embed key.
Require double opt-in. Switchable per form: the submission then creates a pending consent with a token and a deadline, and the address may only be used for marketing after confirmation — see Consent & suppression.
Review submissions. The list shows incoming entries.
Known senders are not created twice. Before creating a lead, Octibiz looks the address up in the CRM — regardless of upper and lower case:
- If there is an open lead with this address (or the same address already produced a lead
earlier), it receives the submission as an activity "Form submission" with the submitted values. No second lead is created.
- Otherwise a contact is searched — by its main and every additional email address. A match
receives the same activity; the inbox entry then shows Known contact with a link to the contact.
- Only without a match is a new lead created — carrying the form's brand.
This applies per brand: a form with a brand finds records of that brand and records without a brand, not those of another brand. A form without a brand searches all of them.
Required fields are checked. A field you mark as required is required on the server too — not only in the browser. A submission with something missing is rejected and creates nothing: no submission, no lead. Without a field schema of its own the form asks exactly for the email address, and that is then the required field.
Field names are unique. Two fields with the same name overwrite each other — saving therefore rejects them, as it does a field without a name (the browser would not send it at all).
Handle spam. A simple detector without external services applies: honeypot field and a link heuristic. Anything misfiled can be released.
Convert to a lead. What gets through becomes a lead — with its origin, without retyping.
Fields in detail
The What it does column answers what changes in the system — not what the field is called. The grey name behind the label is the API field: the same thing runs under that name through automation, import and AI tools.
Creating and editing a form
| Field | Required | Values / format | What it does |
|---|---|---|---|
Name name | yes | text | What the form is called internally. |
Address slug | yes | text | The part of the public address the form is reachable under. Do not change it once it is embedded — every existing embed would then lead nowhere. |
Fields fields | yes | list of fields | What is asked, with label, type and required flag. Every extra required field costs completions — ask for what you really need. |
Source sourceId | no | master data "sources" | What origin the leads created are kept under. |
Default UTM defaultUtm | no | campaign markers | What submissions without markers of their own are tagged with. |
Double opt-in doubleOptIn | no | yes/no | Whether a confirmation mail is required before the consent counts. For advertising consents this is the dependable route — without it the burden of proving the address owner really signed up is yours. |
Consent purpose consentPurpose | no | text | What is consented to. Recorded as a consent. |
Channel consents channelConsents | no | per channel (SMS, WhatsApp) one wording of 10–1000 characters | Shows a separate checkbox per channel below the mail consent. Ticked, it creates a separate consent for the mobile number — with exactly this text as proof. Needs a field for the mobile number in the form. Confirm by SMS reply "YES" (channelConsents[].confirmByReply, SMS only): the number receives a text asking for "YES"; only the reply confirms the SMS consent — the click in the confirmation mail does not. Same deadline as the email double opt-in. On by default as soon as you newly ask for SMS; a form already saved keeps its setting. Costs one text per sign-up; submitting again with the same number sends no second one. |
Consent text consentText | no | text | The wording next to the checkbox. Precisely this text is the evidence in a dispute — which is why it is stored, not merely displayed. |
Redirect redirectUrl | no | address | Where to go after submitting. Empty means the system's thank-you page. |
Targets targets | no | list of targets | What a submission becomes — lead, contact, audience entry, notification. |
Brand brandId | no | one of your brands | Which brand the form stands for. |
Active active | no | yes/no | Off takes the form offline. Existing submissions remain. |
Settings & permissions
- Module
module.marketing. marketing.form.manage— create and edit forms.marketing.submission.view— see submissions ·marketing.submission.convert— turn into a
lead · marketing.submission.spam — mark as spam or release.
- All four are pre-assigned to the role Vertrieb.
- Retention is governed: submissions carry their own GDPR retention rule. Anonymising drops the
plain address, raw payload, referrer and user agent — the address hash stays, because it is the suppression and dedupe key. See GDPR / data protection.
FAQ & troubleshooting
A submission produces no lead. It was classified as spam — or a matching contact or lead already exists. The submission then appears there as an activity "Form submission"; the inbox entry links to the record.
A genuine entry landed in spam. Release it; detection is deliberately simple and runs without an external service.
The address may not be marketed to although the form was filled in. With double opt-in, consent only counts after confirmation. Until then it is pending.
After the retention period the email address is gone. By design. The hash remains so suppression and dedupe keep working — the plain data does not.