> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-functionalities/module-overview/forms.md).

# Forms

The **Forms** module provides extensive functionality to support your risk management activities. It enables you to efficiently collect, distribute, and evaluate information across your organisation.

With Forms, you can:

* Conduct tests, checks, surveys, and questionnaires
* Collect structured input from employees or external stakeholders
* Monitor responses in real time
* Provide feedback to participants
* Export results to Excel for further analysis and reporting

Forms can be completed through a web browser, including on mobile devices, making it easy for users to respond anytime and anywhere.

Every form is created by a designer and completed by one or more participants. The submitted data is stored as **Form Results**.

### Form types

Within the module, three types of forms can be created:

#### Regular Form

A **Regular Form** is used to collect or distribute information without additional review steps. Key characteristics:

* Each assigned user completes their own form.
* Results are individual and not shared with other participants.
* There is no built-in review or approval workflow.

This type of form is suitable for standard surveys, questionnaires, or data collection activities.

#### Workflow Form

A **Workflow Form** extends the functionality of a Regular Form by including review and approval steps. Key characteristics:

* Users can be assigned per page (individual users or user groups).
* Workflow pages can be configured for reviewers.
* Reviewers can view submitted results, provide feedback, and approve or reject submissions.

Workflow Forms are ideal when submissions require validation, assessment, or managerial approval.

#### Form with Mapbacking

A **Form with Mapbacking** allows submitted results to automatically create records in other CERRIX modules. The purpose of mapbacking is to ensure that collected information is directly integrated into operational processes.

Currently, mapbacking can be applied to:

* The **Event** module
* **Data Breaches**

This ensures that submitted form data is not only collected, but also actively used within the system.

### User roles

Each Forms role determines what actions a user can perform, such as creating, editing, releasing, or viewing forms.

{% hint style="info" %}
Every CERRIX user can complete and submit a form, even without having a specific Forms role. This general permission is included in the overview of roles and rights below.
{% endhint %}

| # | Permission / Action                   | Forms Administrator | Forms Responsible | Forms Designer | All CERRIX Users (Entry User) |
| - | ------------------------------------- | ------------------- | ----------------- | -------------- | ----------------------------- |
| 1 | Create Forms                          | Yes                 | Yes               | Yes            | No                            |
| 2 | Edit all Forms                        | Yes                 | No\*              | No\*           | No                            |
| 3 | Edit assigned Forms only              | Yes                 | Yes               | Yes            | No                            |
| 4 | Set Form to *Ready for Release*       | Yes                 | Yes               | Yes            | No                            |
| 5 | Release Forms                         | Yes                 | Yes               | No             | No                            |
| 6 | View Form Results                     | No\*\*              | No\*\*            | No\*\*         | No                            |
| 7 | View Results (if assigned Data Owner) | Yes                 | Yes               | Yes            | No                            |
| 8 | Submit / Complete a Form              | Yes                 | Yes               | Yes            | Yes                           |

\* Forms Responsible and Forms Designer can only edit forms to which they are assigned.

\*\* Viewing results is only possible when the user is assigned as **Data Owner** for that specific form.

#### Forms Administrator

The **Forms Administrator** has the highest level of access within the Forms module: viewing and editing all created forms within the system. However, a Forms Administrator cannot view form results by default — access to results is only granted when the user is assigned as **Data Owner** for that specific form.

#### Forms Responsible

The **Forms Responsible** role is intended for users who manage specific forms. They can create new forms, edit forms where they are assigned as Form Responsible, and release forms. The Forms Responsible can only view results when assigned as Data Owner for the relevant form. This role is typically assigned to users who oversee the lifecycle and distribution of specific forms.

#### Forms Designer

The **Forms Designer** focuses on the creation and configuration of forms. They can create new forms, edit forms where they are assigned as Form Designer, and set forms to *Ready for Release*. The Designer role does not automatically grant access to form results; access depends on being assigned as Data Owner. This role is typically assigned to users responsible for the technical and structural setup of forms.

#### Forms Entry User

Every CERRIX user can submit a form response, even without a dedicated Forms role:

* No specific Forms role is required to complete a form.
* Users can only fill in forms to which they are assigned or invited.
* This role does not grant rights to create, edit, release, or manage forms.

This ensures that participation in forms is widely accessible across the organisation, while management and configuration rights remain controlled.

### How the module is structured

The Forms module is organised around three building blocks: categories, forms, and groups.

#### Category

* Used to organise and classify forms (for example, Compliance forms or Risk Assessment forms).
* A form belongs to one category.
* Categories have no direct influence on permissions.

#### Form

* The central object within the module.
* Created by a Designer or Responsible.
* Assigned to one or more groups.

#### Groups

Groups determine **who can do what** within a form:

* **Participant (entry) group** — users who are allowed to complete and submit the form.
* **Reviewer group** (Workflow Forms only) — users who review submitted results and provide feedback, approval, or rejection.
* **Data Owner group** — users who are allowed to view form results.

{% hint style="warning" %}
Without a Data Owner assignment, users cannot see submitted results — even if they created or released the form.
{% endhint %}

In summary: **categories** structure forms, **forms** collect information, **groups** control participation and access, **participants** submit results, **reviewers** validate results (Workflow Forms), and **Data Owners** can view results.

### In this section

* **Forms Standing Data: Categories and Groups** — setting up the categories and groups that forms rely on.
* **Creating a Form** — form settings, field types, previewing, and workflow forms.
* **Completing and Managing Form Entries** — filling in forms, reopening entries, inviting users, and troubleshooting access.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.cerrix.com/cerrix-functionalities/module-overview/forms.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
