--- title: "Best Practices for Naming Elements in Tulip" slug: "best-practices-for-naming-elements-in-tulip" tags: ["App Editor (Route)", "Variable", "Variables"] updated: 2026-03-30T13:07:01Z published: 2026-03-30T13:07:01Z --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Best practices for naming elements in Tulip ## Purpose *Review our best practices for naming custom elements in Tulip as a starting point for your own apps and naming conventions.* All custom named elements, e.g. Variables, Steps, Records, etc., in Tulip should be named in a way that makes them human readable, unambiguous, and understandable to facilitate usability of apps during their life cycle. It is recommended to adopt the following general naming conventions for all elements: - Descriptive name - Words written out in full, no abbreviations - First letter of each word in upper case, subsequent letters in lower case - Individual words separated by a space - No underscores | **Example** | **Issue** | **Better Example** | | --- | --- | --- | | Done | Non-descriptive | Operation Finished | | operatorName | Lowercase and no space | Operator Name | The sections below outline some more detailed guidelines for specific elements. ## Variables Variable names must be unique with an App, however the same names can be reused within the Tulip platform. - Variable type not included in name - Unit abbreviations written in parenthesis next to name of numeric variables | **Example** | **Issue** | **Better Example** | | --- | --- | --- | | Total wgt | Abbreviation and units.For regulated industries, see comment below. | Total Weight (g) | | fltTemperatureF | Type in name, no space and wrong unitFor regulated industries, see next subsection | Temperature (°F) | ### Regulated industries It is recommended to store a value and its unit of measure in two separate Variables/Table Record Fields, e.g. “Total Weight” and “Total Weight_UOM”. See GxP App Building Best Practices for more information. | **Example** | **Issue** | **Better Example** | | --- | --- | --- | | Temperature (°F) | Only one variable used for value and unit of measure | Temperature TemperatureUOM | ### Variables used to filter Tables Variables used to filter a table with respect to a specific column should be named with the prefix ‘Filter’. This improves the usability of those variables during app building. This is recommended for variables solely used for filtering. General purpose variables in Apps do not need a prefix. | **Example** | **Issue** | **Better Example** | | --- | --- | --- | | Status Filter | Suffix without | FilterStatus | | IPCtimestamp Filter | Suffix vs. prefix | | | Lowercase and no space | FilterIPC Timestamp | | ### Variables for key indicators For Apps with key indicators, e.g. CPPs/CQAs (Critical Process Parameters / Critical Process Attributes) or KPIs, add a prefix to the variables’ names to improve the readability of the variables. | **Example** | **Issue** | **Better Example** | | --- | --- | --- | | CPP Temperature | Prefix not clearly separated from variable name | CPP_Temperature (°C) | | AssayB_CQA | Use as suffix vs. prefix | CQAAssay B | | Availability | Missing prefix for key indicator | KPIAvailability | ## Tables Tables names should adapt the same naming convention used for Variables and be grouped with a prefix. Tables should be grouped against general purpose, e.g. multiple/all use cases, or specific use cases. It is recommended to use ‘ ##’ for general purpose grouping and not to use ‘*’. The ‘*’ is used by Tulip to mark tables originating from Tulip library Apps. | **Example** | **Issue** | **Better Example** | | --- | --- | --- | | Printed lables_table | Use of suffix | #Printed Labels | | *Printed_labels | Use of ‘*’ prefix | #Printed Labels | ## Triggers Do not use the default “unnamed trigger” name. Instead, the name of a trigger should describe its functionality in a few words. | **Example** | **Issue** | **Better Name** | | --- | --- | --- | | Unnamed Trigger | Default name | Increment defect counter | | Check status | Too little context | Check order delivery status | --- Did you find what you were looking for? You can also head to [community.tulip.co](https://community.tulip.co/?utm_source=intercom&utm_medium=article-link&utm_campaign=all) to post your question or see if others have solved a similar topic! **Variables** **Variables**are a location to store app information. Variables have a specific type that must match the contents they can store. Variables are only accessible within a single application and are cleared when the app is restarted or completed. **Steps** A view your users will see within an application. **Steps** can be viewed chronologically or in whatever order best fits your process. Steps can be grouped into **Step Groups**to manage and organize your app Steps. **Table Record** A **Table Record** is a reference to a row in a **Tulip Table**. Table Records can be created either from the Table UI or from with an App Trigger. To edit a record it must be loaded into a **Table Record Placeholder.** **Variable** **Variables**are a location to store app information. Variables have a specific type that must match the contents they can store. Variables are only accessible within a single application and are cleared when the app is restarted or completed. **Table Record Field** **Table Record Fields**are single columns within a **Tulip Table.****![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Table%20Record%20Field.gif)** **Tulip Tables** **Tulip Tables**are a global location to store your production data. Tables are made up of Records (rows). A single can be accessed from multiple apps or stations at the same time. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Tulip%20Tables%20Overview%20-%20Feature%20Overview.gif) **Trigger** **Triggers** are groups of logic that are tied to an app event, such as step open, timer, widget interaction, etc. App builders can add triggers to **widgets**, **machines**, **devices**, **apps**, and **steps**. **Triggers** can contain **actions**, **transitions**, and **conditions**.