> For the complete documentation index, see [llms.txt](https://doc.dastra.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.dastra.eu/en/features/general/custom-fields.md). # Custom fields Add the fields specific to your business to your forms with custom fields: field types, options, usage and API. ## When to use custom fields Some information specific to your industry is not included in the default fields of the ROPA, data subject requests, tasks, etc. Custom fields let you create your own form fields to enrich the data you enter. Here is an example of a field configuration for a stakeholder:
Custom fields page of the stakeholder with a field group and its fields

Field configuration of a stakeholder

And here is the result in the form:
Stakeholder form with the custom field group

The custom fields in the stakeholder form

## Functionalities concerned Custom fields are not available in every module. You can customize the following forms: * [Processing activities](/en/features/ropa.md) * [Data subject requests](/en/features/requests.md) * [Tasks](/en/features/tasks.md) * [Assets](/en/features/ropa/activity/assets.md) * [Stakeholders](/en/features/ropa/activity/stakeholders.md) * [Security measures](/en/features/ropa/activity/security.md) * [Datasets](/en/features/ropa/activity/datasets.md) * Data fields * [Data breaches](/en/features/incidents.md) * [Risk assessments](/en/features/risks/attach-to-processing.md) * [AI systems](/en/features/ai-systems.md) * [Contracts and policies](/en/features/contracts.md) * [Control points](/en/features/risks/process/monitor.md) {% hint style="warning" %} **Limit on the number of fields.** The number of custom fields depends on the plan and subscription of your organization. A quota indicator is shown on the configuration page. For more information, see the [pricing page](https://www.dastra.eu/en/pricing). {% endhint %} ## Available field types Dastra offers the following field types: | Type | Use | | ---------------- | ----------------------------------------------- | | Text | One line of text | | Text area | Text on several lines | | Rich text | Text with formatting | | Number (integer) | A number without decimals | | Number (decimal) | A number with decimals | | Date | A date | | Date with time | A date and a time | | Check box | Several answers possible from a list of choices | | Radio | A single answer from a list of choices | | Single select | One value chosen in a drop-down list | | Multi select | Several values chosen in a drop-down list | | Boolean | A Yes or No answer | ## Using custom fields Once created, custom fields work like the native fields: * They are displayed and edited in the forms of each module. * They can be displayed in all the tables of the application: click the **Customize columns** button of the table. They are hidden by default. * They are **present in all Excel data exports**. For more information on exports, see [the page on exports](/en/features/ropa/export-import.md). * They are present in PDF and Word reports when the field has **Included in PDF and Word reports** ticked (ticked by default). * They can be filtered with the [advanced filters](/en/features/general/filters.md). **Check box** and **Multi select** fields cannot be used to sort a list, however. * They can be updated in bulk in data tables. * They can be imported from flat files with the [import system](/en/features/general/import.md). * They are **accessible and editable through all APIs**, using the variable name assigned to the field. See [Handling custom fields in APIs](#handling-custom-fields-in-apis). ## Setting up custom fields 1. In the sidebar, click **Workspace settings**, then **Custom fields**. 2. In the list on the left, choose the module in which to add a custom field. 3. Fields are created in groups. Click **Create a group of fields**. 4. Fill in the **Custom field label** of the group and its **Form position**. For some modules, such as the processing activity, you can choose the step of the form where the group is displayed.
Create a group of fields window with the label and the form position

Creating a field group

5. Once the group is created, drag a field type from the **Custom fields** list into the group. The field window opens. 6. Fill in the options of the field (see below), then save.
Window to create a custom field with its options

The options of a custom field

You can reorder fields, or move them from one group to another, by drag and drop. A group can only be deleted once it no longer contains any field. A deleted field goes to the recycle bin: turn on **View recycle bin** to restore it. ### Field options | Option | Description | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Custom field label** | The name of the field shown in forms. Required. | | **Variable name (slug)** | The technical name of the field, used by APIs and imports. It is suggested from the label, in lowercase with underscores (for example `business_owner` for "Business owner"), and cannot be changed once the field is created. It is shown in this window only: open the field from the list to read it. To fill the field from a questionnaire, write `custom_` followed by this name (see [Fill a record from the answers](/en/features/questionnaires/templates/record-mapping.md)). | | **Tooltip text** | A help text shown next to the field. | | **Required field** | Makes the input mandatory. | | **Included in PDF and Word reports** | Adds the field to the generated reports. Ticked by default. | | **Validation rule** | For Text fields: checks that the input follows a syntax (email, URL) or a **Custom regex** (JavaScript format). | | **Minimum size** and **Maximum size** | Length of the input for text fields. | | **Minimum value** and **Maximum value** | Bounds for numeric fields. | | **Possible answers** | For types with a list of choices: one row per choice, with a color. **Add answer** adds a row; pasting text that contains one option per line creates one answer per line. | The label and the variable name of a field must be unique within a module. ## Handling custom fields in APIs Dastra lets you retrieve, modify and create, through the [REST API](/en/api/configuration.md), all the values of entities that include custom fields. A `customFields` property is present in every entity you retrieve with a `GET`: ```json { "id": 1234, "label": "Test asset", etc... "customFields": { "dpo_name":"jean-marc le dpo", "dpo_email":"dpo@github.com", "dpo_habilitations": ["Expert","Consulting","Data Mapping"], "has_large_dataset":false, etc... } } ``` To modify this property, send the element with `POST` or `PUT`, updating the elements of the collection. The variable names to use are listed on the custom fields configuration page. {% hint style="info" %} All **custom fields are validated by the server**. If a column is not present in the configuration, it is automatically removed. If a field is not valid (for example, if it is empty although it is marked as required), the API returns an error with the code 400. {% endhint %} --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://doc.dastra.eu/en/features/general/custom-fields.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.