Forms And Form Responses
Build A Form
Forms and Form Builder require the community_forms feature. Open Form Builder, then select Create. Give the form a name, description, tags, and fields in the order members should answer them.
Each field has a type, label, description, required setting, and validation rules. C2 offers text, long text, number, date, select, radio, checkbox, and file field types. Options are required only for option-based types; multiple values are available only where the selected type supports them. Review the preview as a member would before saving.
| Control | Result | Permission checked by C2 | API evidence |
|---|---|---|---|
| Open list or a form | Views forms. | forms:read | Standard form read derives forms:read. |
| Create | Opens the builder/create flow. | forms:create | Standard form create derives forms:create. |
| Save | Creates or saves the configured form. | forms:create on create; forms:update on edit | Standard API actions derive the matching key. |
| Modify | Opens editor. | forms:update | Standard update derives forms:update. |
| Delete | Opens destructive confirmation. | forms:delete | Standard delete derives forms:delete. |
The API provides the available field types and validation rules. C2 blocks obvious incomplete configuration, but the API may still return field-specific errors. Correct the named field and retry; do not recreate the whole form.
Collect A Response
Open a form, choose Submit, complete the displayed fields, and submit. The button and page both use forms:read in C2. The generic form-submissions API derives form-submissions:create for a new response.
Give a member or staff test account both keys before relying on the workflow. C2 may display the submit control with forms:read, while the API can still reject the submission without form-submissions:create.
Review Form Responses
Open a form and then its response. Viewing the response control and detail route requires form-submissions:read. Select Update status, choose a configured status, and confirm the change. The API derives form-submissions:update for that status update.
Configure response statuses first
Open Forms → Statuses before accepting real responses. This route requires the separate community_form_submission_status feature.
| Control | Result | Permission checked by C2 |
|---|---|---|
| Open statuses | Views review status labels. | form-submission-statuses:read |
| Create | Adds a response status. | form-submission-statuses:create |
| Edit | Changes a response status. | form-submission-statuses:update |
| Delete | Removes a response status. | API-derived form-submission-statuses:delete; confirm with a test role because the current C2 route has no literal delete check. |
Keep the status set small and understandable. A reviewer should be able to tell whether a response is new, needs follow-up, or is complete without opening every record.
Access Checklist
| Job | Minimum known keys |
|---|---|
| Form viewer / respondent | forms:read, form-submissions:create |
| Form author | forms:read, forms:create, forms:update; add forms:delete only for authorised owners |
| Form reviewer | forms:read, form-submissions:read, form-submissions:update, form-submission-statuses:read |
| Status manager | form-submission-statuses:read, :create, :update; add :delete only when status removal is authorised |
Related: Applications And Review, Roles And Permissions, and Errors And Troubleshooting.