Build workflows: when a rule is not enough
How to build a workflow on the canvas in stipt, with webhooks, schedules, branches and custom code. Plus how to tell when a simple rule is enough.
In this guide
- What is a workflow in stipt?
- When should I use a rule and when a workflow?
- How does a workflow start?
- Which nodes can I use in a workflow?
- How do I build a workflow step by step?
- How do I test and publish a workflow?
- How do I connect a workflow to other systems safely?
- What happens when a workflow fails?
- Frequently asked questions
Short answer
A workflow in stipt is an automated flow you build on a canvas in Studio, by connecting a trigger, actions and logic such as branches. You use a workflow for connections to other systems, waits, multi‑step logic and custom code. For simple follow‑up inside stipt, when this happens do that, rules are the better choice. A workflow only runs in the background once you publish it, and every run is kept in the log.
By the makers of stiptUpdated October 5, 20268 min read
What is a workflow in stipt?
A workflow is a series of steps stipt carries out automatically. You build it on a canvas by adding nodes and connecting them: one trigger that starts the workflow, actions that do something, and logic that decides which way it goes. That lets you build flows with multiple steps, branches, requests to other systems and custom code.
You find workflows in Studio. Open Studio from the lightning‑bolt icon in the left rail and go to Workflows in the What dot does group, below Rules. One sentence at the top of the list says what workflows are for: connecting to other systems. Each workflow card shows its trigger, node count, run stats and last run, and you can see who created it and who last edited it.
Workflows are not a module from the Module center; they are part of Studio. Admins have Studio included. A team member with the User role needs the Studio add‑on: €30 per person per month on annual billing, or €36 on monthly billing, excluding VAT. External members have no access.
When should I use a rule and when a workflow?
Start with a rule. A rule is the no‑code path: one trigger, optional conditions, and one or more actions that run one after another. Think of a reminder when a quote sits unanswered, a task when a form is rejected, or a WhatsApp after a no‑show. You build rules with pick lists, try them out on a real record, and a limit keeps a customer from getting the same email twice. How that works is in the guide on creating your first automation rule.
Reach for a workflow when a rule falls short: when you want to branch (if yes this, if no that), wait between steps, need custom code, chain several API requests or call other workflows. And when the start comes from outside stipt, such as a webhook from your website, a fixed schedule or email arriving in a mailbox over IMAP, a workflow is the right place.
A rule of thumb: if it is follow‑up inside stipt, pick a rule. If it involves another system or logic with choices along the way, pick a workflow. And if another system only needs to hear that a record changed status or got an appointment, an outgoing webhook under Connections in Studio is often enough, no workflow needed.
How does a workflow start?
Every workflow has exactly one trigger, which you pick when you create it. Webhook starts the workflow as soon as another system sends a request to stipt, for example your website form. Manual starts it when you do. Schedule starts it at a fixed, recurring moment. Email (IMAP) starts it as soon as mail arrives in a mailbox you connect over IMAP.
There are also triggers from inside stipt. Inbox Event starts on a new message or a new task. Task Event starts when a task's status, priority, tag or assignment changes. Workflow error starts as soon as another workflow fails, which is handy for alerting your team.
stipt stores inbound webhooks first and processes them after that. You find them under Inbound webhooks in the Logs group of Studio, and you can replay a failed one from there.
Which nodes can I use in a workflow?
Actions do the work. HTTP Request calls any API. Send Email sends an email through your connected provider. Set renames or transforms fields, Code runs your own JavaScript and Wait pauses the workflow for a set time. For stipt itself there is the Inbox Action (internal notes on a conversation), the Task Action (assign, tag, set a field or status) and the stipt action, which creates, reads, updates or deletes contacts, businesses, records, forms and appointments. The Salesforce node creates or updates data in Salesforce.
Logic decides the route. If splits into a true and a false branch. Router sends the data to one of several routes based on an expression, and Merge brings two branches back together. Call Workflow runs another workflow and uses its output; Trigger Workflow starts another workflow without waiting for the result.
Good to know: If and Router evaluate each item separately. If ten items come in, each item follows its own branch, and the Router sends each item to the first route that matches.
How do I build a workflow step by step?
In Studio, under Workflows, click New workflow, give it a name and pick the trigger type. Edit canvas opens the builder. Click New node, search or pick a node from Actions, Logic or Integrations, and connect it to an existing node. Select a node to open the inspector: that is where you set its parameters, and after a run you see per node what went in and what came out.
An example. A webhook receives a request from your website. An If node checks whether the request is complete. If so, a stipt action creates a contact and a record; if not, Send Email alerts the office. Finally an HTTP Request reports the request to your own system. Clean layout then tidies up the canvas.
You can also ask dot. In the chat, dot adds, updates or removes nodes; you review the proposed changes and apply them. dot can also propose a complete new workflow. After you confirm, it sits in Studio as a disabled draft, and testing and publishing stay up to you.
How do I test and publish a workflow?
You always edit a draft. Background triggers, such as a webhook, IMAP or a schedule, only run the published version. So a change only goes live when you click Publish; Save just keeps the draft.
Test first. Execute runs the whole workflow, Execute step runs a single node; that second button works once the workflow has run once. On the trigger node you can set test input, so you can try the draft with sample data without waiting for a real request. That test input only applies to the draft.
Want to throw a draft away? Use Sync from published or Revert to published. You are then back on the version that runs live.
How do I connect a workflow to other systems safely?
You store credentials for other systems under Connections, in the Connections group of Studio. A connection is of type HTTP, IMAP, Salesforce OAuth2 or Google OAuth2, and nodes refer to it. The values are stored encrypted, so they do not sit loose in your workflow.
The same Connections group holds API keys, API names and Webhooks. API names are the fixed machine names of pages, fields, statuses and more. They never change, so a workflow or integration that refers to them keeps working.
Pick the lightest route per connection. If the other system can call the stipt API itself, you sometimes need no workflow at all: a record created or moved to another status through the API fires the same rules as a change made in the app.
What happens when a workflow fails?
Every run is kept. Open the Runs tab on a workflow, or Workflow runs in the Logs group of Studio. Per run you see the status (Success, Failed, Running, Waiting, Queued or Cancelled), the trigger, the start time and the duration.
If a run failed, ask dot to run it again, with the workflow open on the canvas. dot looks up the cause in the real run data and proposes a fix. The new run executes against the current draft, so a fix you just applied is included, and you watch the nodes run live.
You do not have to check the log yourself to spot an error. On the home page the Sending and automation section shows failed workflow runs from the last 24 hours, for admins and team members with the Studio add‑on. With the Workflow error trigger you can also build your own alert.
Frequently asked questions
Do I need to code to build a workflow?
Not always. You set up most nodes through their parameters in the inspector; only the Code node asks for your own JavaScript, and a Router works with an expression. For follow‑up inside stipt without any technical work, rules are the better choice.
Who can build workflows and what does it cost?
Admins have Studio included. A User needs the Studio add‑on, at €30 per person per month on annual billing or €36 on monthly billing, excluding VAT. External members have no access to Studio.
Can dot build a workflow for me?
dot can add, change or remove nodes and propose a complete workflow. dot never creates or publishes anything on its own: after you confirm, a new workflow is ready as a disabled draft, and testing and publishing stay up to you.
Why does my edited workflow still run the old version?
Most likely you only saved it. Save keeps a draft, but background triggers such as a webhook, IMAP or a schedule run the published version. Click Publish to put your change live.
What is the difference between Call Workflow and Trigger Workflow?
Call Workflow runs another workflow and uses its output in the next step. Trigger Workflow starts another workflow and carries on right away, without waiting for the result.
Can I connect a workflow to Salesforce?
Yes. The Salesforce node creates or updates data in Salesforce. You store the credentials as a Salesforce OAuth2 connection under Connections in Studio.
Keep reading. More guides on related topics.
See what stipt can handle for your business?
We'll show you what your working day looks like in stipt, set up for your kind of work and your way of working.