What are workflows?
A workflow in TeleportHQ is a visual recipe that makes your site do something when something happens. Every workflow starts with one trigger, for example "a form is submitted", followed by steps, for example "save the message to the database, email the owner, show a thank-you message". You build workflows in the Workflows panel of the editor by adding boxes and connecting them, without writing code. Workflows are a web app feature: adding one to a website turns it into a web app.
What you can build with TeleportHQ workflows
Some everyday examples of TeleportHQ workflows:
- A contact form that emails you. When the Contact form is submitted, save the message to a table and send yourself an email.
- A button that does something. When Book now is clicked, check a value, then go to the Booking page.
- A daily job. Every morning at 9 AM, count yesterday's orders and post the number to Slack.
- Data from another service. When another service sends your site a message (a webhook), save what it sent to a table.
- AI inside your app. When a visitor submits a review, run a sentiment check with your own AI provider key and store the result.
- Payments. When a visitor clicks Subscribe, make sure the subscription plan exists and take them to checkout. Store sites get these workflows ready-made. See How to accept payments with Stripe or PayPal.
The parts of a TeleportHQ workflow
- Trigger (the first box, marked Trigger). What starts the workflow. Examples: An Element is Clicked, Form is Submitted, Page is Loaded, Scheduled (Cron), Webhook Received. Each workflow has exactly one trigger.
- Steps (the boxes below it, marked Step 1, Step 2 and so on). What the workflow does, in order. TeleportHQ calls each box a node. Steps are grouped into categories such as Data, Email, SMS, Push Notifications, Navigation, AI, E-Commerce and Integrations. The E-Commerce category holds the payment steps: Price Order On Server, Charge User, Refund Payment, Ensure Subscription Plan, Manage Subscription, Open Billing Portal and Close Open Checkout. The E-Commerce steps need your store turned on, and the payment steps also need a payment provider set up in its settings.
- Branches. Some steps split the workflow. An If Statement has a true path and a false path, a Switch Statement has one path per case, a Loop repeats steps for each item in a list, and Parallel runs several paths at once.
- Context. Every step can use the results of the trigger and earlier steps, for example the email address someone typed into your form. See How to use data from one workflow step in the next.
- Error handler. Every new workflow also has a Workflow Error box. Steps attached to it run only if something in the workflow fails.
- Custom nodes. A group of steps you build once and reuse in several workflows. See How to reuse a group of steps (custom nodes).
For the full list, see the Workflow triggers and steps reference.
The TeleportHQ workflow editor
When you open a workflow, the TeleportHQ workflow editor shows the steps on a canvas and three tabs on the right:
- Node Properties: the settings of the step you clicked.
- AI Assistant: describe what you want and the AI builds or changes the workflow. See How to build a workflow with AI.
- Test runs: every test you ran on the workflow's steps, with its result. See How to test a workflow step.
At the top right of the canvas, Tidy layout arranges every step top to bottom, with branches to the right. After you copy a step, a Paste button appears next to it. See How to create a workflow.
Where TeleportHQ workflows run
Most TeleportHQ workflows start in your visitor's browser, for example when they click a button. The steps that need your site's server, such as saving to the database, sending an email or calling an AI provider, run there, so your secret keys never reach the browser. Some workflows run entirely on the server:
- Scheduled (Cron) workflows run on the server at set times, with no visitor needed.
- Webhook Received workflows run on the server when another service calls your site.
- The Custom JavaScript step lets you choose its Execution Context: client (the browser) or server.
Because scheduled and webhook workflows run without a visitor, they can't use browser steps such as Show Toast, Go to Page or Hide Element.
Workflows run on your published site. After you change a workflow, publish your site again so visitors get the new version. Workflows that a visitor starts, with a click, a form or a page load, also run in the editor's Preview, which builds a working copy of your site. Scheduled and webhook workflows only work after you publish. See How to preview your site before publishing.
A Page is Loaded workflow also runs again when a visitor opens another record of the same page, changes the address after ? or switches language, because the page starts over. See Do page-load workflows run again when a visitor opens another record of the same page?.
Which workflows make a website a web app
In TeleportHQ, every workflow you add is a web app feature. If your project is still a Website:
- Adding a workflow yourself opens the Enable Web App features? window first. This happens wherever you start: Add Workflow in the Workflows panel, a new custom node, or the Workflows section of a selected element (On Click, On Visible, More event types or Add workflow). It happens whatever the workflow will do, even if it only changes a state on the page.
- Asking the AI Assistant for a workflow on a website: it tells you a web app is needed and opens the same window. If you enable it, send your request again.
- One exception: when you create a website with the AI website builder, small workflows the AI adds that only change what the visitor's own page shows don't make it a web app. These start when an element is clicked, becomes visible or the page loads, and only set page or component states, use the browser's storage, or check a condition (for example, a menu that opens or a tab that switches).
To make a click show, hide or switch something on a website without a web app, don't use a workflow. Use a state: change it from the element's Events tab, and show or hide elements with Conditional Rendering. Both work on every project. You can also ask the AI Assistant to show or hide an element: it does that on a website without asking for a web app. See How to store and use values with States and How to show or hide elements based on a condition.
Enabling web app features is permanent: you can no longer download the project's code (you can still publish from TeleportHQ), and the project needs a web app slot to keep publishing and running after a 7-day window. Read What's the difference between a website and a web app? and Why does my web app need a slot? before you start.
Plans and limits for TeleportHQ workflows
- Building workflows is not limited by plan: you can add as many workflows as you like in the editor.
- Scheduled (Cron) triggers work on Trial, Pro and Premium. If your trial or subscription has ended, the Scheduled category shows a PRO badge and Paid plan required.
- Real-Time triggers and steps show Coming Soon and can't be added yet.
- The Data Triggers (Item Added, Item Updated, Item Deleted) are in the menu but don't currently start workflows, and an Emit Custom Event step doesn't start a workflow whose trigger is A Custom Event is Triggered. Add follow-up steps right after the step that changes the data, or share steps between workflows with a custom node. See the Workflow triggers and steps reference.
- A web app keeps running only while it is covered by your plan or a web app slot. While it isn't, the Workflows panel says "Workflows run free for 7 days — this project needs a Web App slot subscription to keep running after that." with a Subscribe project button. See Why does my web app need a slot?.
- TeleportHQ doesn't keep a log of your workflows' runs on the live site, whether they start from a visitor, a schedule or a webhook. The Test runs tab lists only the tests you ran in the editor. To check a live workflow, look at its result, for example the new record or the email that was sent. See Why isn't my workflow running?.