Definitions can be described as the columns of your database. The definitions tab holds a complete list of the definitions within the project, as well as detailed information on the setup of each of them.
Table of contents:
Screen overview
Once you've selected a database and navigated to the definitions tab, you'll land on a screen that is similar to the one that is shown below.
The left hand side, there is a list of already existing definitions which are automatically created by the system. These are system columns and questionnaire columns, which hold the answers that are given by respondents.
By adding extra columns to these current variables you'll create new area's for extra background variables. You can fill these columns with data by mapping them to your import source or by means of dynamic rules.
Adding definitions
If you want to add new columns to the database click on the plus icon and a popup will appear, where you can fill out details about the column
To add a column you will need to fill out the following fields:
- Header name - The title of the header by which the definition is recognized in the database.
- Main type - Does this column contain general Data, Labelled Data or Questionnaire Data.
- Sub type - Does the data within this column concern textual data, numeric data or date formatted data.
Once you've saved this information, a new definition will be added to the list on your left. Again, you can move about or rename these definitions.
The main type and sub type cannot be changed once records are already present in the system.
When you only submit a header name, and you create the column without indicating the Main type and Sub type, the column will be generated as a textual data column by default.
The data that gets gathered under the project definitions can be ranked based on the risk level it contains, such as High risk/ Medium risk/ Low risk.
By default a newly created column is assigned a low risk level, but any type of data has its own risk level, so it can be classified manually accordingly. Based on the risk level of definitions, data management rules can be applied, such as anonymization after a certain retention period.
Flagging definitions
Flagging definitions is particularly useful as a way of administrating and logging the setup of the project. What are columns used for? Will something impactful happen if I change the value within one of them? By keeping a close administration on your definitions, you are less likely to make mistakes when making changes or additions to a project that is already running.
For this reason, you can also flag the data that is gathered under a certain column. The options you are presented with are:
Unique identifier: Using this flag you can mark a definition as a unique identifier within the project for an easy search or filter through your records or to recognize a key column for a VLookup rule.
Multi project variable: Using this flag you can mark a definition as being used across projects by stating that the information in this column is also used in the exact same way in other projects, for instance when using a smart search filter in dashboarding.
In order for the smart filtering on multi project variables to work, the definition header names need to be exactly the same, as that is used as the reference to connect them.
Follow up task: Using this flag, you can mark a definition as generated with a purpose to be used in or filled by means of the dashboard Follow Up Widget. You need to activate this flag in order to connect the column to the Follow Up Widget.
Allow to edit field: Using this flag you can mark a definition as authorized to edit. When you deactivate this flag, this column becomes greyed out when using the Edit option in your database.
Required field: Using this flag you can mark this definition as a field that is required, that needs to be filled in order for a correct proceeding of the project. If a user edits the record manually, they will not be able to save the changes if any of the required fields are empty.