FAQ
Frequently asked questions
Search or browse by topic.
Getting Started
It turns a chosen HighLevel Contact, Business, Opportunity or any HighLevel Custom Object into a secure, pre-filled form so the right person can review or update it without CRM access.
Add the Generate Record Update Form action to any HighLevel workflow, select the object, and configure the form. See How It Works.
Objects and Record Targeting
Yes.
No. The Record ID does not appear in the public form.
Yes. Update Records with Forms works with all HighLevel Custom Objects available in the installed account – there is no subset of "supported" Custom Object types. Individual field-type limitations are covered separately below.
Yes. A blank Record ID creates a new record on first successful submission.
No. Chained forms are independent and do not automatically share record context.
Fields and Pre-filling
No. Whether the Object has 5 fields or 500 doesn't change the product's pricing or setup. The form automatically loads the current form fields and existing values rather than requiring every field to be mapped individually into the form URL.
The form uses HighLevel's current schema. After the short field-metadata refresh period, typically around two minutes, reload the existing form link – the new field can then appear automatically, provided it isn't Hidden and its field type can be displayed.
No. Field order comes from HighLevel rather than being independently maintained in another form builder.
Normally no. Current schema is read again when the form opens or reloads.
Unsupported field types are omitted rather than guessed.
Field order follows current HighLevel field positions, but it is not guaranteed to always exactly match every HighLevel UI folder ordering. This doesn't change the core benefit: field order comes from HighLevel rather than being separately maintained in another form.
Files
Existing files satisfy Required unless they are removed without replacement.
No. Replace mode does not delete existing files when no replacement is supplied.
Submission and Concurrent Editing
No. Only changed normal fields are deliberately written back.
Stale existing-record forms can be blocked if the CRM record changed after opening, rather than overwriting the newer CRM change. The recipient can reload the form, but will lose anything they'd already entered, and will see the updated details from HighLevel instead.
Yes. The form can be submitted with no field changes.
Yes. Successful no-change submissions can still fire Record Update Form Submitted.
Expiry and Multiple Submissions
Every newly generated form link has an expiry.
Expiry is entered as a number of days (decimals allowed), blank defaults to 7 days, and the maximum is 3,650 days.
There is no manual link revocation.
Workflow Automation
form_url, form_id, form_reference, record_id, object_key and expires_at.No, that redundant configuration no longer exists.
Yes. Use Record Update Form Submitted – a successful form submission can start another HighLevel workflow for follow-up, notifications, routing or the next operational process. See Pricing for HighLevel's own billing note on this trigger.
Security and Privacy
HighLevel remains the source of truth. CRM field values and submitted form contents are not persisted as a duplicate CRM database. See Security.
No. Recipients never receive HighLevel CRM access.
Pricing
Troubleshooting
Every form-link request gets a response. If the form itself can't be displayed, the recipient sees a specific message explaining why (link not recognised, link expired, form already submitted, and so on) rather than a generic error page. See Support for the full troubleshooting checklist.