CRM Forms

CRM forms can create or update People, Organizations, custom Records, Tickets, Interactions, and Signals. Use Ticket forms for customer and service requests.

Create and test a form

Open CRM → Forms and create a form for the customer or work type you want to collect.
Give each question a clear label, map it to the destination field, and mark required answers.
Choose the access mode below. For a public form, assign its Pages domains before enabling it.
Configure duplicate matching, consent, and files if needed, then save.
Submit a test using demo information through the intended private, portal, or public route. Check Submissions and the resulting CRM record before sharing the form.

Choose access

Private forms are available to workspace members with CRM management access.
Portal forms require an active customer portal session. A Person form can update only the customer bound to that session.
Public forms accept anonymous new submissions on their assigned Pages domains. They cannot update a caller-selected record.

Public submissions have spam and rate-limit protection. Reference fields in public forms can link to an existing customer only through a default configured by a workspace manager; visitor-supplied customer references are rejected. Portal forms accept references only to customers that are already available to the signed-in person.

Configure questions and destinations

Workspace managers choose the fields, required values, defaults, source, duplicate matching, relationship mappings, consent questions, success message, automation triggers, and optional file limits. Public forms must be assigned to at least one Pages domain before they can be enabled. Portal forms automatically use the Pages domains and Forms selected in the customer portal settings; they do not need a second Page allowlist.

Open CRM → Forms to create or edit a definition and review its submissions. Give each question a visible label and choose its destination from the configured CRM fields. The list shows only destinations that belong to the selected customer type and uses plain names such as Owner, Status, or Related tickets. Bnder validation patterns match the complete value. They support literals, wildcards, character classes such as [A-Z], and repetitions such as {4} or +; use at most one variable repetition and do not use groups or alternatives. Bnder assigns the stable internal ID automatically. If Pages cannot be loaded, the form editor keeps the draft intact and offers a retry. Duplicate matching fields, Pages domains, and consent questions are selected by name; consent questions guide you through the field, channel, and purpose separately. Required fields are marked with *. Save points to the specific missing name, destination, or record type. If saving fails, your entered values remain in the editor with a visible error so you can correct them or retry.

Enable file upload and set both a maximum file count and per-file byte limit. Each form can contain one file field; enable multiple selection there when you need several files in one submission. Public and customer-portal forms accept up to 20 files and 25 MiB per file. The configured count multiplied by the per-file limit must stay within 25 MiB so the complete upload fits through the public request boundary. Files use the workspace's existing type policy, storage quota, malware scan, and audit log. If the form submission fails or safely repeats an already completed attempt, newly uploaded files from that attempt are removed.

Consent questions must be boolean fields on a Person form. Every answer stores the channel, purpose, source, timestamp, and form-submission evidence; leaving out a consent question never implies permission. Form consent purposes are Marketing, Transactional, or All; create separately named custom consent records outside Forms when you need a custom legal purpose.

Duplicate review and success

Select stable fields such as email, phone, domain, or a record identifier for duplicate matching. Public submissions with any existing match are saved for review, even when there is only one match. They do not change the customer's details, relationships, or consent. Open CRM → Forms → Submissions to inspect the submitted information before making any customer changes.

No matches creates a new item. Private forms may update one matching item because they require CRM management access; multiple matches require review. Portal Person forms update the signed-in customer only. Matching Organizations or custom Records in other portal forms also requires review.

After an accepted submission, Bnder shows the configured success message or redirect and emits the form's automation trigger keys. Review events do not target the matched customer; the submission remains available for inspection.

Customer relationships and approval

Portal forms can select only customers already available to the signed-in person. An unavailable selection is rejected before any customer details are changed. Existing approved relationships can be reused. New relationships that would grant portal access require a manager's review, even if both customers are already visible. Public submissions with relationship selections are also saved for review. While review is required, the submission does not change customer details or consent.

A manager can inspect the submission, verify the relationship, and add it from the customer's detail view. Apply approved profile changes separately, or send a new portal submission after approval. Older relationships created by external forms no longer grant access automatically: remove an old link and explicitly add it again only after verification. Editing its label alone does not approve access.

Submission problems

Public form uploads accept at most 30 MiB for the complete multipart submission and 25 MiB per individual file. Larger submissions are rejected before CRM processing. Choose smaller files and submit the form again.

After an input, file-policy or reference validation error, correct the values and submit again; the same browser attempt can succeed. A lost response does not create another submission when retried.

If processing is interrupted, retry the same attempt. Bnder keeps your original answers and files and finishes the missing steps without creating another customer or repeating consent changes. If the first request is still running, wait a few minutes before retrying. Older attempts that say they need review must be checked by a workspace administrator before starting a new attempt.

Uploaded files are retained if processing may already have saved them, even when a later storage error is shown. Retrying a completed attempt returns its existing result and removes only the new retry uploads, not the original attachments.