Designer workspace
The workflow designer is for authorized builders. It combines the node palette, canvas, connector routing, node settings, custom tables, report templates, template gallery, simulation tools, save, publish, version history, active/passive controls, and import/export.
Canvas
Place nodes on the canvas and connect outputs to define the path a process can take. Keep naming clear because task users see many node titles in task and history contexts.
Node settings
Select a node to configure assignment, timing, variables, forms, service details, outputs, notifications, or data mappings depending on node type.
Version controls
Use version history to understand what changed. Keep inactive or draft versions separate from the published version that users can run.
Node palette
The palette provides the building blocks for starts, human work, routing, automation, data access, notifications, reporting, and termination.
Start nodes
Manual starts are launched by permitted users. Webhook, Timer, and Email starts are used when a process should begin from an external event, schedule, or message pattern configured for the tenant.
FormTask
Use FormTask for new human work. It presents a form, assigns ownership, applies deadlines or SLA rules, and exposes submit or custom buttons.
Legacy UserTask
UserTask exists for older workflows. Do not choose it for new designs unless you are maintaining a legacy process that already depends on it.
Gateway
Use gateways to branch by condition. Each outgoing path should have understandable labels and a fallback route when a value may be empty or unexpected.
ForEach
Use ForEach to repeat a branch for items in a collection. Define the item variable clearly so downstream tasks and scripts know which item they are processing.
TimerEvent
Use timers for waiting, reminders, delays, or time-based escalation. Make the expected delay visible in task instructions when users are affected.
ServiceTask and ScriptTask
Use service tasks for external calls and script tasks for controlled logic. Keep secrets out of visible fields and document failure handling for users.
DbFetch and DbExecute
Use database nodes for approved data reads or writes. Limit fields to what the process needs and avoid using them as informal permission bypasses.
ReportTask
Use ReportTask when the workflow should generate or expose report output as part of the process.
SendMail, SendMessage, and AppNotification
Use notification nodes to inform the right people at the right time. Keep messages short, factual, and tied to the process record.
Agent
Use agent nodes only where the tenant supports them and the outcome is reviewed appropriately. Do not rely on an agent for decisions that require human approval unless the workflow also captures that approval.
End and Delete
End closes a path. Delete events should be used carefully and only where the process owner understands the record and audit implications.
FormTask configuration
FormTask is the default human task node for new workflow design.
Assignment
Assign by user, department, variable, manager relationship, or another supported rule. If assignment can resolve to no one, add a safe fallback path or admin handling.
Task content
Configure title, description, notes, priority, due dates, planned dates, SLA, owner/co-owner/watchers, web notifications, and mobile notifications.
Buttons and outputs
Buttons such as submit, approve, reject, cancel, next, back, custom, save, or report should map to clear outputs. Button names should describe the user decision, not internal logic.
Draft behavior
Save draft stores form input without advancing the workflow. Submit or a custom process button may advance the workflow when the output is connected and allowed.
Run behavior
When the process reaches a FormTask, Flow creates a human task, applies assignment and timing settings, renders the configured form, and waits until an allowed action completes or routes the task.
Gateways, loops, timers, and endings
Routing nodes decide how work moves through the process.
Gateways
Use explicit conditions for approval decisions, thresholds, missing data, or policy branches. Avoid ambiguous labels such as yes/no when a business phrase would be clearer.
ForEach
Use ForEach for repeated approvals, item checks, or per-row processing. Confirm whether the loop should run sequentially or in parallel if the tenant exposes that choice.
Timers
Use TimerEvent for waits, reminders, and escalations. Document the timing in nearby task text so users understand why a task may pause.
End
Use End when a route is complete. Multiple End nodes are acceptable when each route has a clear business outcome.
Delete
Use Delete only for intentionally removing or cancelling records where that behavior is expected, permitted, and understood by the process owner.
Automation, data, and messages
Automation nodes should make the process easier to operate without hiding responsibility or creating undocumented side effects.
ServiceTask
Configure endpoint, method, payload, headers, and response mapping only for approved integrations. Store credentials with safe secret handling, not as plain text in node fields.
ScriptTask
Use scripts for small, controlled transformations or decisions. Keep scripts readable and map outputs to named variables for later nodes.
DbFetch
Fetch only the columns or records the workflow needs. Treat returned data as process context that still must respect user permissions in forms and reports.
DbExecute
Use writes carefully, especially for approvals, financial records, customer data, or operational status changes. Make failure paths visible to admins.
ReportTask
Generate report output from configured datasets, parameters, and templates. Do not describe it as guaranteed workflow advancement unless connected to an advancing output.
SendMail and SendMessage
Send concise messages with links or identifiers that help recipients find the task or process. Avoid sensitive data in message bodies where your policy disallows it.
AppNotification
Use app notifications for timely in-product prompts. Keep them actionable and avoid notifying broad groups without a reason.
Agent
Use only where enabled and reviewed. Capture human confirmation for decisions that require accountability.
Variables and forms
Variables carry process context. Forms decide how users read, enter, validate, and submit that context.
Variable names
Use stable, descriptive names for amounts, customers, items, due dates, approval reasons, and output values. Avoid temporary names that become unclear in reports.
Mappings
Map node outputs into variables deliberately. When a value is optional, make downstream logic handle empty states.
Form layout
Build web and mobile layouts with sections, rows, wizard steps, card modes, field logic, watchers, and reusable components from the library.
Field settings
The field inspector commonly includes general settings, style, defaults, options, data binding, table settings, actions, kanban behavior, and mapping.
Field types
Typical fields include text, number, checkbox, switch, slider, select, multiselect, autocomplete, radio, tags, color, datagrid lookup, date/time, rating, signature, JSON, HTML, file/image, table, repeatable group, subform, and kanban.
Validation
Use required fields and clear labels for information that later routing, reports, or approvals depend on.
Reports and custom tables
Reports and custom tables should expose useful operational data without over-claiming what the workflow does automatically.
Report designer
Authorized users can configure datasets, parameters, calculated fields, preview behavior, and PDF output where supported.
Report buttons
A form report button should be described as opening or generating report output. It should not be documented as always advancing the workflow.
Dashboard builder
Authorized users can create dashboards, choose a datasource, add widgets, map fields, define filters, and assign or share dashboards.
Custom tables
Use custom tables for structured data the process needs repeatedly. Name fields for business meaning and avoid storing secrets in table rows.
Permissions
Share reports, dashboards, and tables only with users or roles that should see the underlying data.
Save, publish, testing, and safety
Publishing changes who can run a design. Treat it as a release step, not a draft save.
Save
Save records the current design draft. It is useful for ongoing builder work and should not be treated as production release.
Publish
Publish makes a version available for running work according to the tenant's permissions and active/passive settings.
Simulation
Use simulation to test routing, variable values, form outputs, gateway conditions, loops, and timer expectations before publishing.
History
Review version history before and after publishing so admins can explain what changed if users report different behavior.
Permissions
Restrict who can design, publish, start processes, view dashboards, run reports, edit tables, or manage secrets.
Safe secrets
Never paste API keys, passwords, tokens, or private credentials into visible labels, form defaults, report text, custom tables, comments, or node descriptions. Use the platform's secret handling for credentials.