Forms - Data Capture

What are Forms

The form system allows creating data capture forms that can trigger workflows or be presented within a workflow execution. It is composed of two main modules:

• FormTrigger: Starts a workflow from a form submission.
• FormRender: Generates and displays forms within a running workflow.

---

Organizing Forms with Folders and Tags

Forms support the same folder and tag system as workflows, making it easy to keep large collections organized.

Folders

Create a hierarchical folder structure in the left sidebar to group related forms:

• Click + New Folder in the sidebar to create a root folder or subfolder
• Drag and drop any form card onto a folder to move it
• Click a folder to filter the list and show only its forms
• Folders display the count of forms they contain

Auto-assign on create: If a folder is selected when you click New Form, the new form is automatically placed inside that folder.

Tags

Tags are free-form labels attached to one or more forms for cross-cutting classification:

• Add tags when creating or editing a form
• Click a tag chip in the sidebar to filter forms by that tag
• Multiple tags can be active simultaneously (AND logic)

Global Organization Settings

The Settings → Organization page provides a centralized view of all folders and tags shared across Workflows, Forms, and Dashboards. From there you can rename, delete, or review usage counts per module.

---

Form Trigger - Start Workflow from Form

A trigger that starts the workflow when a form is submitted. Works similarly to the webhook, but includes additional form metadata.

The received data includes:

{
  "campo1": "valor",
  "_request": { "method": "POST", "timestamp": "...", "source": "form" },
  "_form": { "form_id": "1", "form_name": "Registro", "form_fields": [...] }
}

Supports OTP (One-Time Password) flow for user identity verification before processing the submission.

---

Form Render - Display Forms in the Flow

Generates a form pre-populated with workflow data. It has three output modes:

• url: Returns a URL to access the form (default mode).
• html: Returns embeddable HTML directly in a page or email.
• redirect: Redirects the user to the form automatically.

Uses temporary sessions with a 24-hour duration to pre-fill form fields. The form_prefill_sessions table stores this temporary data until expiration.

---

Field Mapping (field_mapping)

Allows pre-filling form fields with data from the workflow. Dynamic variables are used to reference values from previous nodes or workflow variables:

{
  "email": "{{@Webhook.email}}",
  "nombre": "{{@HTTP_Request.data.name}}",
  "empresa": "{{var.empresa_nombre}}"
}

When the user accesses the form, the indicated fields already contain the corresponding values.

---

Form Render Configuration

Parameter	Type	Description
form_id	text	ID of the form to render
field_mapping	json	Field mapping with dynamic variables
output_type	select	url, html, redirect
redirect_after_submit	boolean	Redirect after submission
custom_title	text	Custom title (supports variables)
custom_description	textarea	Custom description

---

Images and Dynamic Options

Images and logo

The Image field and the Form logo (in Settings) are picked from the Resources library with Choose from library. The logo is shown above the title on the public form. For it to be visible without signing in, the image must be public; the picker offers to make it so if it is not.

Select options from the DataStore

On a select field, turn on Load dynamic options and choose the source:

• External endpoint (URL): the browser loads the options from an address that returns a list.
• Floogos DataStore: choose the group, the field shown and the field stored (or the Record key). Test shows how many options come out and a preview.

With the DataStore, Floogos serves the options to the public form under the same access restrictions as the form itself (published, security group, authentication). Only the two chosen fields are sent, up to 500 options. Anyone who opens the form will see them, so do not choose fields with private data.

---

Multi-step forms (wizard)

A long form can be shown step by step. The appointment booking form uses it: pick a slot, enter your details and confirm.

1. In the form editor, add a Step element (under “Layout elements”) before the fields of each step. Everything below a step, up to the next one, belongs to that step. Fields before the first step form an initial step.
2. In the form settings turn on Show in steps (wizard). You can change the text of the “Next” and “Back” buttons.
3. Publish the form.

Whoever fills it in sees a progress indicator and Next and Back buttons. Each step is validated before moving on: required fields, email format, selects and required files. The submit button only appears on the last step, and on submit every step is checked again. A completed step can be reopened from the progress indicator. Pressing Enter in a field moves to the next step instead of submitting a half-filled form.

The data of all steps is sent together to the workflow, like a normal form; steps are not fields and are not sent.

If you do not turn the wizard on, steps show as plain section titles. With a single step the form is shown as usual.

Forms Database

The main tables involved are:

Table	Key Columns
forms	id, name, description, form_json, settings, public_hash, folder_id, tags
form_prefill_sessions	session_hash, form_id, prefill_data, expires_at (24h)
form_submissions	Stores responses submitted by users

---

Example: Client Registration Flow

Webhook (receives partial data from CRM)
  -> HTTP (query additional data)
  -> FormRender (pre-fill registration form)
  -> [User completes the form]

FormTrigger (receives completed form)
  -> DataStore (save client)
  -> SendMail (send confirmation)
  -> End

Initial data from a CRM is enriched with an external HTTP query, and a pre-filled form is generated for the user. Once submitted, a second workflow stores the data and sends a confirmation email.

---

Example: Form with Approval

FormTrigger (vacation request)
  -> SetVariable (save request)
  -> SendMail (notify manager)
  -> FormRender (approval form for manager)
  -> [Manager approves/rejects]

FormTrigger (manager's response)
  -> Decision (approved?)
    -> true: SendMail (notify approval)
    -> false: SendMail (notify rejection)
  -> End

An employee submits a vacation request through a form. The system notifies the manager and presents them with an approval form. Based on the manager’s response, the employee is notified of the outcome.