First Steps

Welcome to Floogos. Here you will learn how to design and create workflows from scratch, from problem analysis to production activation.

Prerequisites

• Have access to the platform
• Be authenticated with your account
• Access to credentials if you need external APIs or email sending

1. Before opening the editor: analyze the problem

The most common mistake is starting to drag nodes without having thought through the flow. Before touching the editor, answer these questions:

Key questions

a) What event starts the process?

• Does someone submit a form? -> FormTrigger
• Does an external system send a notification? -> Webhook
• Should it run at a fixed time? -> Start + Schedule
• Does a piece of data change in my system? -> DataStore Trigger
• Does a message arrive from Telegram/MQTT/Redis? -> Corresponding Trigger

b) What data do I need and where does it come from?

• From an external API? -> HTTP
• From a database? -> SQL Query
• From a file? -> ReadExcel, CSV, PDF
• Already in the DataStore? -> DataStore (filter)
• Entered by a user? -> FormTrigger / Webhook

c) What decisions need to be made?

• Are there yes/no conditions? -> Decision
• Are there multiple paths based on a value? -> Switch / Router
• Are there validations that can fail? -> Decision + error branch

d) What actions should I execute?

• Send email? -> SendMail
• Call an API? -> HTTP
• Save data? -> DataStore / SQL Query
• Notify someone? -> Slack / Telegram / SendNotification
• Generate a file? -> GeneratePDF / SaveToExcel / CSVCreate

e) Is there repetition?

• Do I need to process a list of items? -> Iterator + Merge
• Do I need to do the same thing for N records? -> Iterator

f) What happens if something fails?

• Should I notify someone?
• Should I retry?
• Can I continue without that step?

---

2. Sketch the flow on paper

Before building, draw the data path. You don’t need precision, just the logical sequence.

Example - “When a customer places an order in my store, check stock and send confirmation”:

1. Order arrives (Shopify Webhook)
2. Check product stock (HTTP to my inventory API)
3. Is there stock?
   -> Yes: Confirm order, send email to customer
   -> No: Notify team via Slack, mark order as pending
4. Save result in DataStore

This translates directly to:

Webhook -> HTTP (stock) -> Decision (is there stock?)
  -> true:  HTTP (confirm) -> SendMail (customer) -> DataStore (save)
  -> false: Slack (team) -> DataStore (save pending)
-> Merge -> End

Each line of your sketch is a node. Each question is a Decision.

---

3. Golden rule: one workflow, one purpose

A workflow should do ONE thing well. If when describing your workflow you need to use the word “and” more than twice, you probably should split it.

Bad example: a workflow that does everything

Receive order AND check stock AND process payment AND generate invoice
AND send to warehouse AND notify customer AND update CRM
AND sync with accounting

This is fragile: if the invoice fails, everything stops. If you change the CRM, you touch a huge workflow.

Good example: separate and connected workflows

Workflow 1: "Receive order"
  Webhook -> Validate -> DataStore (save order) -> SubWorkflow (check stock)

Workflow 2: "Check stock"
  Start -> HTTP (inventory) -> Decision -> DataStore (update status)
  -> SubWorkflow (process payment)

Workflow 3: "Process payment"
  Start -> Stripe (charge) -> Decision (successful?)
  -> true: SubWorkflow (generate invoice)
  -> false: SendMail (payment error)

Workflow 4: "Generate invoice"
  Start -> Bill.pt (create document) -> SendMail (send invoice) -> End

Workflow 5: "Notifications"
  DataStore Trigger (new confirmed order)
  -> Slack (team) -> SendMail (customer) -> End

Each workflow is independently testable, reusable, and easy to maintain.

---

4. When to use SubWorkflow

The SubWorkflow node executes another workflow as if it were a function. Use it when:

Situation	Example
Reusability: The same logic is used in multiple flows	”Send invoice” is called from orders, subscriptions, and refunds
Complexity: A flow has more than 10-12 nodes	Split into logical blocks of 5-8 nodes each
Responsibility: Different teams manage parts of the process	The payments team maintains their workflow, the logistics team theirs
Testing: You need to test a part of the process in isolation	Test only invoicing without running the entire order
Maintenance: A change in one part should not affect the rest	Change shipping provider without touching the payment flow

SubWorkflow modes

• Synchronous: Waits for the sub-workflow to finish and continues with its output data
• Asynchronous: Launches the sub-workflow and continues immediately without waiting
• Parallel: Launches multiple instances in parallel

Do not use SubWorkflow when

• The flow is linear and simple (fewer than 8 nodes)
• It is only used in one place and there is no plan to reuse it
• The artificial division complicates more than it simplifies

---

5. Step-by-step process to create a workflow

Step 1: Define input and output

Write in one line:

• Input: “I receive a JSON with order_id, product_id, quantity from Shopify”
• Output: “The customer receives a confirmation email and the order is saved in DataStore”

Step 2: List the intermediate actions

Write each action as a numbered step:

1. Receive data from the webhook
2. Query the product in my API
3. Check if there is enough stock
4. If there is stock: confirm the order
5. If there is no stock: notify the team
6. Save result
7. Send email to customer

Step 3: Identify the node types

For each step, assign the node type:

Step	Node	Main config
1. Receive data	Webhook	-
2. Query product	HTTP	URL: {{var.api_url}}/products/{{product_id}}
3. Check stock	Decision	data.stock >= {{#2.quantity}}
4. Confirm order	HTTP	POST to orders API
5. Notify team	Slack	Message with details
6. Save result	DataStore	group: “pedidos”, key: {{@Webhook.order_id}}
7. Send email	SendMail	to: {{@Webhook.customer_email}}

Step 4: Draw the connections

Webhook
  -> HTTP (query product)
  -> Decision (is there stock?)
    -> true: HTTP (confirm) -> DataStore (save confirmed)
    -> false: Slack (notify) -> DataStore (save pending)
  -> Merge
  -> SendMail (customer)
  -> End

Step 5: Build in the editor

Now yes, open the editor and:

1. Drag the trigger (Webhook)
2. Add the nodes in order
3. Connect the arrows
4. Configure each node with the parameters
5. Use descriptive names in labels (they are used in {{@Label.field}})

Step 6: Test with real data

1. Use the development URL (/webhooks-dev/{hash}) to see detailed traces
2. Send a test request with curl or Postman
3. Review the traces: each node shows input, output, and execution time
4. Verify that dynamic variables resolve correctly
5. Test the alternative paths (true branch AND false branch)

---

6. Simplicity: the most important rule

Signs that a workflow is too complex

• It has more than 15 nodes -> split with SubWorkflow
• You can’t explain what it does in one sentence -> split into parts
• It has more than 3 levels of nested Decisions -> use Switch or Router
• A change in one node breaks distant nodes -> dependencies are coupled
• It takes more than 30 seconds to execute -> optimize or parallelize

How to simplify

Before (complex):

Webhook -> HTTP -> Decision -> HTTP -> Decision -> HTTP -> Decision
  -> SendMail -> DataStore -> HTTP -> Slack -> End

After (simple):

Workflow "Receive order":
  Webhook -> Decision (valid?) -> DataStore -> SubWorkflow("Process")

Workflow "Process order":
  Start -> HTTP (stock) -> Decision -> SubWorkflow("Notify")

Workflow "Notify result":
  Start -> SendMail -> Slack -> End

Simplicity principles

1. Descriptive name: If you can’t name the workflow in 3-4 words, it is too broad
2. One trigger, one purpose: Each workflow responds to ONE event and produces ONE result
3. Maximum depth: No more than 2 levels of nested Decisions. If you need more, use Switch
4. Reuse before duplicating: If you copy nodes between workflows, create a SubWorkflow
5. Clean data: Use DataTransform or MapFunction at the beginning to normalize the data

---

7. Common beginner mistakes

Mistake	Problem	Solution
Not validating input data	The workflow fails with unexpected data	Add Decision or Validate after the trigger
Ignoring the false branch	The workflow stops if the condition fails	Always connect both Decision branches
Not using Merge after Decision	Parallel branches never rejoin	Add Merge to reunite the paths
Putting credentials in text fields	Credentials are exposed in logs	Always use the credentials_id field
Giant workflow without SubWorkflows	Impossible to maintain and debug	Split into workflows of 5-10 nodes
Not naming nodes	Variables {{@Node.field}} don’t work well	Use descriptive labels: “Check Stock”, “Send Email”
Not testing the error branch	Fails in production without notice	Test every possible path in development
Iterator without Merge	Data is lost after iterating	Always close Iterator with Merge or MergeIterator
Ambiguous {{field}} variables	Confuses data from different nodes	Use {{@NodeName.field}} to be explicit
Unnecessary schedule every minute	System and API overload	Use the minimum interval actually needed

---

8. Checklist before activating a workflow

Before putting a workflow into production, verify:

• The workflow has a descriptive name
• All nodes have clear labels
• Credentials are configured (not hardcoded)
• The false branch of each Decision is connected
• Each Iterator has its corresponding Merge
• It was tested with real data using the development URL
• All possible paths were tested (true, false, errors)
• Critical nodes have error handling (continueOnError or error branch)
• There is some notification if the workflow fails (email, Slack, etc.)
• The schedule (if any) has a reasonable interval
• Dynamic variables resolve correctly
• The workflow does not exceed 15 nodes (if it does, consider SubWorkflow)

---

Summary

1. Analyze: What comes in? What goes out? What decisions are there?
2. Sketch: Draft on paper with the logical sequence
3. Split: One workflow = one purpose. Use SubWorkflow for the rest
4. Build: Nodes in order, descriptive names, secure credentials
5. Test: Development URL, both branches, real data
6. Simplify: If it's complex, split it. If it repeats, reuse it.