Workspace administration
Forms: definitions, versions, requests and submissions
Forms separates the reusable definition, the version presented to a participant and the submission they provide. External Forms supplies the participant-facing experience.
Confirm that Forms is enabled
Forms is a customer-facing module with authenticated administration and a separate External Forms experience. Its availability is feature-gated, and administration requires the relevant permissions. If the area is missing or unavailable, confirm activation and your access before following the remaining steps.
The dashboard, definition detail, version editor, submission lists, My Requests and My Submissions serve different tasks. Use administration to design and publish a form; use the participant-facing flow to respond to a particular request.
Create a definition and edit a draft version
A definition identifies the reusable form. Versions let you prepare changes without treating every edit as the current published experience. The administration interface supports creating versions, viewing them, editing drafts and duplicating an existing version for further work.
Start with the information the business needs and clear field labels. Review required fields, instructions and validation in the rendering experience before publication. If a version has an associated PDF, check that it agrees with the form being presented. Keep the version name meaningful for the staff who will maintain it.
Publish the intended version and check its availability
Publishing a version and activating a definition or version are distinct operations in the Forms service. Check which version is published and whether the relevant records are active. A completed draft is not proof that participants will receive that version.
After publication, open the intended participant route or request and verify the actual rendered form. Test a valid response and a validation error. For a changed form, check that the workflow still presents the correct instructions and that staff can interpret the submitted information.
Understand requests and submitted responses
A form request asks for a response within a defined context. The request workflow supports creation, updates, closure, rejection and submission. A submission records the participant’s response to a form version or request; it is not the reusable form design itself.
My Requests and My Submissions help participants find their own work. External Forms has authenticated views and separate external submission capabilities governed by the request rules. Do not assume that knowing a form path grants access to someone else’s response, or that every external flow is anonymous.
Use localization, files and configured AI assistance
Form localization supports language-specific entries and overrides. Review translated labels in the rendered form so that instructions, validation and field meaning remain consistent. File uploads and PDF access depend on their feature and authorization settings; see files and documents.
The module includes configured AI help for creating or editing form versions and an assistant path for submissions. Those features depend on the registered agents and settings. Review any generated schema or proposed response before relying on it; an AI conversation is not itself confirmation that a form was published or a response accepted.
Troubleshoot a form that cannot be opened or submitted
Check module activation, permissions, the definition’s active state, its published version and the status of the particular request. Then review the displayed validation and whether a required file feature is available. For participant access, use the correct external route rather than a staff editor link.
When AI assistance is unavailable, inspect the configured form agent and its published version. When submission succeeds, verify the response in the permitted submission view. A form submission does not automatically create a ticket or mailing-list member unless your deployment has an explicitly configured integration for that action.