Skip to main content
Autoflux gives you a visual canvas where you assemble workflows by connecting nodes — each node representing a trigger, an action, or a decision point. Because everything is drag-and-drop, you can map out even sophisticated multi-step processes without writing a single line of code. This page walks you through building a workflow from scratch, wiring up dynamic data between steps, responding to failures gracefully, and keeping your workflows healthy over time.

​
Creating Your First Workflow

Follow these steps to go from a blank canvas to a running, end-to-end workflow.
1

Open the Workflow Builder

In the Qvista sidebar, navigate to Autoflux → Workflows and click New Workflow. Give the workflow a descriptive name and, optionally, a brief description. The builder canvas opens with a single empty trigger node at the top.
2

Add a Trigger

Click the trigger node and choose how the workflow should start. Your options include:
  • Schedule — run on a recurring time interval or a cron expression
  • Event — fire when a specific thing happens, such as a new row added to a Google Sheet, a webhook payload arriving, or a form being submitted
  • Manual — start the workflow on demand from the Autoflux dashboard
Configure the trigger’s required settings (for example, select the specific Google Sheet and sheet tab for a New Row trigger) and save.
3

Add Action Steps

Click the + button below the trigger to append the first action step. Search the connector library and select the app or service you want to act on — for example, Salesforce, Slack, or Qvista Dashboard. Each action step prompts you to authenticate the connected app (if not already done) and fill in the required fields.Continue appending steps to build the full sequence. Steps execute in order from top to bottom unless you introduce a branch.
4

Configure Conditions and Branches

Insert a Condition node between any two steps to introduce branching logic. Define your rule using the visual rule builder — for example, Deal Value is greater than 10000. Autoflux creates two outgoing paths: True and False. Add different downstream actions to each path to handle both scenarios.You can nest multiple condition nodes to build decision trees of any depth.
5

Map Data Between Steps

Every step produces output fields that subsequent steps can reference. Use the Dynamic Data panel when configuring a field to select outputs from any upstream step. For example, map the Email field from your Google Sheets trigger directly into the Contact Email field of a CRM action without retyping anything.
6

Test and Activate

Click Test Workflow to run a dry-run against sample or live data. Review the step-by-step execution results in the Run Log panel to confirm each step behaves as expected. When you are satisfied, toggle the workflow status to Active.

​
Worked Example: Sheet → CRM → Slack → Dashboard

The following scenario illustrates a complete multi-step workflow that many sales and ops teams use daily. Goal: When a new row is added to a Google Sheet (for example, a new lead captured from a web form), automatically create a contact in the CRM, notify the sales team on Slack, and update a Qvista dashboard counter.
  1. Trigger — Google Sheets: New Row — The workflow fires whenever a row is appended to the designated sheet.
  2. Action — CRM: Create or Update Contact — Map the Name, Email, and Company columns from the sheet row into the CRM contact fields.
  3. Condition — Lead Score ≥ 80 — Route high-quality leads to an immediate notification; route lower-scored leads to a nurture sequence instead.
  4. Action (True path) — Slack: Send Message — Post a formatted message to #sales-alerts with the contact name, company, and CRM link pulled from the previous step’s output.
  5. Action — Qvista Dashboard: Increment Counter — Bump the New Leads This Week KPI tile by one.
Because each step’s output feeds into the next through dynamic data mapping, no manual copy-pasting is ever required.

​
Multi-Step Workflows and Dynamic Data Mapping

Autoflux is built for multi-step orchestration. As your workflow grows, the Dynamic Data panel becomes your primary tool for keeping steps connected. Every output field — IDs returned by an API, values read from a database, or text extracted by an AI model — is available as a variable you can inject anywhere downstream. Use the search bar in the Dynamic Data panel to locate specific fields quickly in long workflows. Fields are namespaced by their step name, so Step 3 — CRM / Contact ID is always unambiguous even in a 20-step flow.

​
Error Handling

When an action step fails due to a transient error — a momentary network timeout, a rate-limited API response, or a brief service outage — Autoflux automatically retries the step using an exponential back-off strategy. You configure the maximum number of retry attempts and the initial delay in the step’s Error Handling settings. If all retries are exhausted without success, Autoflux marks the run as failed and moves to the fallback path if one is defined.
Add a Fallback branch to any step by clicking the error-state connector on that node. Actions on the fallback path execute only when the primary step fails after all retries. Use fallback paths to send an alert to an admin Slack channel, log the failure to a Qvista Datatable for review, or trigger a simplified alternative action — ensuring the workflow degrades gracefully rather than stopping silently.
Enable Failure Alerts in the workflow’s settings to receive an email or in-app notification whenever a run fails. The notification includes the workflow name, the step that failed, the error message returned by the downstream service, and a direct link to the run log. For critical workflows, you can also route failure alerts into a Slack channel or a Qvista dashboard panel using a nested notification workflow.
Every failed run is captured in the Error Log, accessible from the workflow’s Logs tab. Each entry records the exact timestamp, the offending step, the full request payload sent to the external service, and the response received. Use the error log to diagnose root causes before adjusting your workflow configuration.

​
Monitoring and Debugging

Open any workflow and click the Logs tab to see the complete execution history. Each row in the history represents a single run and displays its start time, duration, trigger type, and final status (Success, Failed, or Skipped). Click into an individual run to view the Step-by-Step Execution Breakdown — a visual replay of the workflow canvas that highlights each step in sequence, shows the exact data it received, what it sent to the downstream service, and the response it got back. This granular view makes it straightforward to identify exactly where and why a run deviated from the expected path.
Use the Test Workflow button during development to run the workflow against a specific sample payload without waiting for a live trigger. You can inspect the full step-by-step breakdown in the same logs view before activating the workflow.

​
Versioning and Audit Trail

Autoflux maintains a version history for every workflow. Each time you save a change to a workflow’s structure or configuration, Autoflux creates a new version snapshot. To review or restore a previous version, open the Version History panel from the workflow header. The Audit Trail records who made each change, when, and what was modified — individual node configurations, renamed steps, and status toggles are all captured. The audit trail is read-only and cannot be edited, making it a reliable record for compliance, change management, and incident investigation.
Restoring a previous workflow version replaces the current configuration immediately. The existing version is preserved in the history so you can switch back, but any unsaved edits in progress will be lost. Save or discard pending changes before performing a restore.