Code Lists define and manage standardized labels used across your organization. They ensure consistency when assigning classifications, statuses, or any predefined values to your metadata.

General overview

Code lists are essential for maintaining a controlled vocabulary in your data governance framework. Whether it’s categorizing documentation types, setting security levels, or tagging objects by department or geography, code lists provide a centralized way to define and apply these labels.

Without code lists, labels like “Internal,” “Confidential,” and more might be entered inconsistently or forgotten altogether, leading to errors and misinterpretation. With code lists, these options are clearly defined and consistently available.

The Code Lists application allows you to create and maintain these reusable lists, ensuring that predefined values remain accessible, standardized, and governed in one place.

Code List object types

diagram-1

Each code list consists of two object types, forming a parent-child structure:

Parent objectChild object
Code ListThe parent object represents a list category (e.g., Labels, Country Codes).
Code List itemThe child object represents an individual, selectable value in the list.

Code Lists relations

diagram-2

Relations between code lists and other objects depend on the type of code list. Each code list defines its own relation names, reflecting the nature of the attribute it represents.

For example:

  • A code list for Areas will use relations such as has area (on the object) and is area for (on the code list item).
  • A code list for Labels will use has label and is label for.
  • A code list for Documentation will use has doc type and is doc type for.

Although relation names vary, the principle remains the same:

  • Objects reference a code list item to define an attribute (e.g., assigning a label, classification, or type).
  • Code list items list all objects that are associated with them.

Key features

Centralized label management

The primary advantage of the Code Lists app is the ability to manage all organizational labels in one place. This centralization ensures that terms like “Confidential,” “Deprecated,” or “High Priority” are not only used consistently but also clearly defined and maintained.

By assigning code list items to metadata fields, you make your data more structured, interpretable, and secure.

Adding Code Lists to your space

Add Code List app

  1. In the top-right corner of your space, click  and select + Add application.
  2. Select Code Lists and choose your workflow (for more information on workflow types, see Workflows).

Add Code List objects

First, add a parent object.

  1. In your Code List app, click Create in the top navigation bar.
  2. Name the new object and select one of the following parent object types:
    1. Areas Code List
    2. Countries Code List
    3. Labels Code List
    4. Security classifications Code List
    5. GDPR classifications Code List
    6. Documentation types Code List
  3. Click the icon in the top-right of the Description box to add a description for your code list.

Next, add your child objects (items in your code lists).

  1. On the Code list page, click Create in the top navigation bar.
  2. Name your child object and click Add object.
  3. Click the icon in the top-right of the Description box to add a description for your code list.
Tip

The object type of child objects depends on the parent object. For example, if you create a Labels Code List you can only add labels to your list.

Code List vs. Other Selectables

Not all fields with dropdown selections in Dawiso are Code Lists. While Code Lists are structured as separate objects with full lists, ownership, and editing capabilities, other selectables may behave differently.

  • Codetable labels are lists of relations to objects in other applications. While they use a similar dropdown component, they don’t rely on Code List objects and don’t offer centralized management.
  • Codetable values offer a predefined set of options but are not linked to actual objects. This means you cannot track or view a complete list of where these values are used.

These fields with selectors can be created and added to object pages using packages.

Understanding these differences helps avoid confusion when managing or customizing selectable fields across your workspace.