Known limitations

Current behaviors that may surprise you, with workarounds. We list these so you can design around them.

Limitation	Workaround
The `onSuccess` callback in `f2wf.load()` currently throws after a successful submission, which triggers the error path.	Don't use `onSuccess` for now; rely on the built-in success message.
Button and row-action webhooks send no metadata, and the signed-in person only on Verified and Protected forms (as `X-F2WF-User-*` headers).	On public forms, put identifying values in the URL or hidden fields and verify them in n8n.
Multipart (file) submissions drop nested values and aren't retried.	Keep file forms flat.
Roles accept dashboard members only, so form users can't be added to roles.	Assign form users to forms directly.
One sign-in is shared by all form2wf forms on the same website.	Use one organization per website where users differ.
The SDK's `fetch` doesn't forward query parameters and ignores login.	Use a form with an onload webhook for parameterized or per-user data.
Table search and paging work on the rows the onload webhook returned; there is no server-side paging.	Return a filtered subset for very large lists (e.g. by a `{{params.q}}` value).
Verified sign-in offers Microsoft only so far.	Use Protected (form users) for people without a Microsoft account.
No conditional fields, pattern validation or multi-select.	Split into multiple forms; validate in n8n.
Deleting a theme doesn't block forms that use it; they fall back to default colors.	Reassign forms before deleting a theme.
The hosted page shows the form name as a page heading, so the form title appears twice.	Set `showTitle: false` on forms shared mainly by link.
The “Powered by Form2Workflow” footer shows on all plans.	—