--- title: "App building basics" slug: "app-building-basics" tags: ["Priority 1"] updated: 2025-05-13T17:32:28Z published: 2025-05-13T17:32:28Z canonical: "support.tulip.co/app-building-basics" --- > ## 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. # App building basics Building an app in Tulip may seem intimidating at first, but once you break down and understand the core elements to it, it’s not so complicated. Applications combine the following principles: - **Design** - The layout, organization, physical appearance, and color scheme of steps and the components on a step. - **Functionality** - How the app logic performs, such as: trigger behavior, step navigation, or widget configuration - **Architecture** - The defined scope of the app, the data model (the data that’s read from or written to), and the integrations and/or devices connected. Remember–Tulip is a no-code platform, so we’ll focus on the features you need to design production-ready apps, regardless of your coding experience. Before you build an app, you need to understand what you’re building and why. ## App Development Process Following a development process for apps ensures that you’re building apps that address business and operational needs. When building multiple apps, ensure that they work together as a solution by sharing data and routing between process. The app development process includes the following steps: ### Set business objectives 1. **Pick 1-3 goals to focus on** - Be realistic when setting goals. Your goals must be specific and measurable. - Identify areas for improvement that will have the biggest impact on your business. - Align goals with overall business strategy. 1. **Ensure goals fit your business' maturity level and growth focus** - Assess your current stage of development and growth focus. - Align goals with available resources. - Anticipate future needs and challenges. 1. **Use these goals to prioritize use case development with Tulip Identify and prioritize use cases that support your goals based on potential impact.** - Develop a roadmap for implementation. - Use the business objectives template below to help pinpoint operational pain points, prioritize goals, and set measurable KPIs. ![Set business metrics graphic](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Set%20business%20metrics%20graphic.png) ### Pick a first use case A use case is a broad improvement area or process that you build applications around, such as digital work instructions or inventory management. Work backwards from your business objectives to app design. #### Example **Your business objectives are:** - Increased first pass yield - Fewer rework loops - Less scrap by volume **The data you need to evaluate these objectives are:** - Scrap by station (in weight) - Throughput by line - Number of defects by type **Use cases to build apps:** - Weigh and categorize scrap with scale connection - Track throughput with production data - Detailed error and defect reports Take the Tulip University course to learn more: [How to Pick Your First Use Case](https://university.tulip.co/how-to-pick-your-first-use-case). ### Map the shop floor When designing a solution in Tulip, it is critical to think about where the solution will physically live (equipment, tools, constraints), as well as what activities (process sequence, time of day) the operators perform in the location. An operational flow diagram (OFD) helps you map apps to your factory floor and breakdown the processes that will be the models for those apps. **Example Activity OFD** [Embedded object](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Activities%20OFD.svg) Learn more about building an OFD in the Tulip University course: [Tulip Solution Design](https://university.tulip.co/tulip-solution-design) ### Document operator activities to app features and functionality Before you start building an app in Tulip, it is helpful to create a wireframe. This is a high-level map or sketch of your application layout and workflow, minus the detailed elements and design. You can build these wireframes from the OFD. 1. **Identify main functionality** The first step is to determine the primary function of your application. What key task will it accomplish? Who will be using it? 1. **Sketch the app steps** Sketch out the steps of the app, which are essentially the different screens that the operator will interact with. What actions will operators perform, and in what order? Your apps should model every step of a process on the floor. 1. **Establish user flow** Illustrate the potential paths a user may take through the app by drawing arrows between steps to map the user flow. 1. **Indicate interactive elements** Add interactive elements for each step to indicate anything operators will physically interact with. These elements can include buttons, forms, tables, and devices. 1. **Features outside of workflows** Include additional functionalities that operators may need access to outside of their flow, such as defect report forms, call for help screens, analytics screens, etc. **Example Wireframes** ![Solution Wireframe Examples 1 2](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Solution%20Wireframe%20Examples%201%202.png) Once you’ve sketched out a basic wireframe, app builders can easily start building out each step in the App Editor. ## App Editor The App Editor is where you build and edit your apps without needing any coding experience. ![App editor ex functionality](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/App%20editor%20ex%20functionality.gif) For an in-depth overview of the app editor, visit [Intro to the Tulip App Editor](https://support.tulip.co/docs/intro-to-the-tulip-app-editor). ### Steps Steps are the “pages” of your app, the various screens that display content Steps can be linear or non-linear, in that they don't have to consecutively follow each other in the order you arrange them. The logic you add to your app will determine the transition of steps. Learn more about Steps [here](https://support.tulip.co/docs/steps). ### Base Layout The Base Layout is the template that applies to each step you create. Creating a base layout makes it easier to build your app, with the foundational elements automatically added to each step, and ensures a cohesive style throughout your app. Learn more about base layout [here](https://support.tulip.co/r230/docs/how-to-use-base-layout). ### Widgets Widgets are the building blocks of apps. They can display information, collect data, execute Trigger logic, and more. ![Widgets.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Widgets1.png) Here are the different types ofm widgets: - **Icon widgets** - Place shapes, icons, or logos within the workspace and configure logic to design the look and branding of your app. - [**Button widgets**](https://support.tulip.co/r230/docs/how-to-use-buttons-in-apps) - Choose from a variety of buttons, one with pre-programmed logic or blank custom ones, to use in your app. - [**Input widgets**](https://support.tulip.co/r230/docs/input-widgets) - Collect data from app users with Input Widgets, with each type of input representing a different variable of data. - **Text widgets** - Display static or dynamic text including the values of Variables, plain static text, and entire Record Placeholders. - [**Embedded widgets**](https://support.tulip.co/r230/docs/embedded-widgets) - Embed videos, images, CAD, documents, barcode scanners, and more into your app. - [**Camera widgets**](https://support.tulip.co/r230/docs/vision) - Show your Tulip Vision camera feed or scan a barcode all with the camera on your device. - [**Electronic signature widgets**](https://support.tulip.co/docs/how-to-use-the-electronic-signature-widget) - Sign data within Tulip in accordance with 21 CFR Part 11 - [**Custom widgets**](https://support.tulip.co/r230/docs/custom-widgets-overview-1) - If none of the above widgets are suiting your needs, you can create your own widget using HTML, CSS, and Javascript to extend the platform’s capabilities. Learn more about widgets [here](https://support.tulip.co/docs/widgets). ### Triggers Triggers enable you to add logic to your app. Triggers make your app *do something*. An app is a flat screen without them. Triggers can be added to widgets, as well as to steps (Step Level Triggers) and apps (App Level Triggers), and upon certain events like a device firing. ![ex first app display hello world message ](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/ex%20first%20app%20display%20hello%20world%20message%20.gif) All triggers follow the same basic format: **when** an action happens, **then** perform the following Action and/or Transition. Triggers can be as simple or complicated as you need, having the ability to add multiple actions. You can also add if statements, that add a condition to the action being performed, if the criteria is met. With an **If** statement, you set the conditions that allow actions to follow. ![Trigger-If Statement.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Trigger-If%20Statement.png) **Then** statements are either an action or a transition. An action is a change in the app that is not related to changing the steps. A transition is either changing the steps or completing the app. ![Trigger-New Action/Transition.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Trigger-New%20Action3.png) Finally, to coincide with if statements, there are **else if** statements which determine the alternate action to take when the if statement is proven false. ![Trigger-Else If Statement.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Trigger-Else%20If%20Statement.png) Learn more about triggers [here](https://support.tulip.co/docs/triggers). ### Variables Variables are the primary means for storing and referencing data within Tulip apps. They capture data from various sources, including user input and device output, and enable calculations based on app activity. You can use variables to control app behavior through triggers, display dynamic content, and build detailed reports in Analytics. Variables can have the following datatypes: - Boolean - Yes/no - Color - Dynamic color to set widget status - Datetime - Date and time timestamp - File - Link to a file stored in Tulip - Image - Link to an image stored in Tulip - Integer - A whole number - Interval - Amount of time displayed in seconds - Machine - Machine object in Tulip - Number - A real number - Object - Configurable object structure with child attributes which have their own data type - Station - Station object in Tulip from the Shop floor - Text - Sequence of characters - User - User object in Tulip from Account/Workspace settings Learn more about variables [here](https://support.tulip.co/docs/variables). ## App building best practices The following practices for each element of apps: ### Design The layout, organization, physical appearance, and color scheme of steps and the components on a step. - **Single Role, Single Process:** Each app should be tailored to support a specific user role and the tasks associated with that role. This ensures that the app is focused and easy to use. - **Base layout**: A base layout applies a step design to every step in an app. This standardizes the UI and ensures an intuitive user experience for operators. Learn how to design an effective base layout [here](https://support.tulip.co/docs/how-to-design-an-effective-base-layout). - **Clear component names**: App components such as steps, triggers, and variables should all have clear and unique names. This allows app developers to intuitively understand what each component is or does. Learn more about best practices for naming components [here](https://support.tulip.co/docs/best-practices-for-naming-elements-in-tulip-1). - **Standardized statuses:** A predefined set of (order, station) statuses that you can reuses across additional apps to maintain consistency and enable seamless integration. ### Functionality How the app logic performs, such as: trigger behavior, step navigation, or widget configuration. - **Unified Record Placeholders:** Consistent use of record placeholders across different apps ensures data integrity and simplifies data management. - **Step naming:** Use proper step naming and step group naming to determine what the task or activity is - **Variable management:** Use generic variables where possible and clear variables before reusing them ### Architecture The defined scope of the app, the data that’s read from or written to, and the integrations and/or devices connected. - **Standalone function:** Apps should be designed to operate independently without relying on other apps. This promotes modularity and maintainability. - **Integrate on an as-needed basis**: Any external data should only be used in Tulip as necessary to provide context in an app. This ensures you are maintaining a source-of-truth. Learn more about system integrations here. ## App Design Best Practices When designing your app, navigability and accessability are two important notions to keep in mind. Users must navigate through the app without getting lost or stuck in their process. Learn more about designing apps [here](https://support.tulip.co/docs/app-design). ## Next Steps Start building apps with Tulip experts’ guidance: - [Walkthrough: Build your first app](/r230/docs/walkthrough-build-your-first-app) - [Basic App Design and Logic University course](https://university.tulip.co/basic-app-design-and-logic) **Become a Tulip certified app builder:** [Basic app builder certification](https://university.tulip.co/certification-exam-basic-app-builder) --- 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 faced a similar question! **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. **Base Layout** The **Base Layout** is the base template that all other **S****teps** will be built on top of. Establishing common navigation buttons, and a consistent app background and style across all of your app steps can expedite the training and app-building processes. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Intro%20to%20the%20Tulip%20App%20Editor_511473104%201.png) **Widgets** **Widgets**are the elements that make up a specific **App Step.**Widgets can display information to users, collect user input, or trigger app logic. *Common widgets include: Interactive Tables, Number inputs, Machine attribute widgets, and more.* **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**. **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**. **Step-Level Trigger** A**step-level trigger** is a trigger configured with each app step. Step-level triggers can be triggered based on 4 actions: 1. Step Opened 2. Every X seconds (Timer) 3. Machine/Device outputs data 4. Step Exited **App-Level Triggers** **App-level Triggers**are triggers that are configured with each app. App-level triggers can be triggered based on 3 actions: 1. App Started 2. App Cancelled 3. App Completed **Action** **Actions**are different operations that can be executed in **Triggers. Actions**cannot move users to other apps, or other**steps.** Many **Actions**can be added to a single **Trigger.** *ex. Store the value of variable x to table field y, Print app step, Adjust Edge device GPIO pin.* **Transitions** **Transitions** are a type of logic in **triggers**. **Transitions** can move operators between steps/apps or start/stop the app.**** Only 1**Transition******can be added to a single **Trigger.** *ex: Complete then change to X app, Next step, Previous step, Cancel app, etc.* **Analytics** **Analytics** are live updating graphs and metrics calculated based on app data, Table data, and machine data. Analytics can be embedded and dynamically filtered within an application. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image-1662410510869.png) **Boolean** **Boolean's**are a Tulip Datatype. Booleans can have True/False (Yes/No) values. **Color** **Colors**are a Tulip Datatype to represent a color. Color variables can support transparent or semi-transparent colors. **Datetime** **Datetimes**are a Tulip Datatype. Datetimes represent a time in the ISO8601 format. *ex. 2022-08-31T19:56:16+00:00* **Image** **Images**are a Tulip Datatype. Images are a reference to a web-hosted location for all Tulip Images. **Integer** **Integers**are a Tulip Datatype. Integers can have any whole number. *ex. -5, 15, 47, 155. **NOT** 15.2, -12.73* **Interval** **Interval**is a Tulip Datatype. Intervals represent pieces of time, represented in seconds. Intervals can be added or subtracted from **Datetime**variables. **Machine** A **Machine**is a digital representation of a physical datasource. Machines have **Attributes**that are updated through an OPC-UA Connector or the Tulip API. **Number** **Number**is a Tulip Datatype. Numbers can be any positive or negative number. Numbers support decimals. *ex. -5, 15, 47, 155, 15.2, -12.73* **Object** **Objects**are a Tulip Datatype. Objects represent an arbitrary grouping of attributes. Leveraging objects can simplify the process of working with complex data architectures. Often **Connector** **Functions** will return **Arrays** of **Objects** *ex. My car object has 5 attributes, Color, Make, Model, # of wheels, # of seats.* **Station** **Stations**are a digital representation of a physical place or device in your facility. Stations are 1:1 with **Interfaces (display devices)** running Tulip Player, but Stations can also be assigned **Edge Devices,**Tulip Vision Camera Configurations, Machines,****and more. **User** **User**is a Tulip Datatype. Users represent a single user in your Tulip **Instance.**User****variables include attributes like **Badge Id, Name, and Shift.** **Table Record Placeholder** A **Table Record Placeholder** is a reference to a row in a **Tulip Table**. Table Records can be created either from the Table UI or from an App Trigger.