Naming Conventions for datasources, entities and their fields

Benefits of Following Naming Conventions

The primary benefit of adhering to the naming conventions below is that you gain a better overview over the data sources and entities you use. If your organization consists of multiple sites in different locations, each using their own data sources and entities, it becomes easier to identify which ones belong to the different sites. This becomes particularly relevant if your organization is multilingual, as it ensures that everyone responsible for managing the service at your organization can understand what they are doing. Finally, having a clear naming structure makes it easier to ensure that integrated data appears in the right place.

Names of Data Sources & Entities

• Always use English.
• Do not use special characters (with the exception of underscores "_").
• Use descriptive names to clearly indicate the type of data that should be stored in the data source/entity. Avoid names like "team1_data_source" or "johns_deviations_3."
• Avoid abbreviations as they can be difficult for others to understand.

Naming of Fields (key names)

• Use descriptive names to clearly indicate the type of data that should be stored in the field. For example, use "goal" or "outcome" instead of "value_x."
• Avoid overly long names. While descriptive names are important, you should avoid making field names excessively long. Strike a balance between clarity and readability. If the name becomes too long, it can be challenging to manage and maintain an overview.

Field Names with Multiple Words

When naming fields where you want to communicate ownership, start with the ownership and end with what it pertains to.

Example:

• s_value
• group_1_goal
• group_1_value

Standard Names for Entity Fields

These names are recommended for use where applicable. They are used by various standard types of entities that we have, such as the Project module, Visit module, simple entities, etc.