Low Code Automation | The Garnet Wiki

Low code automation enables engineers and operators to design, deploy, and maintain workflows with minimal hand-coding, using visual tools and declarative configuration. It matters when teams need to rapidly adapt to changing business logic—such as onboarding new vendors, handling incident escalations, or synchronizing customer data across services—without requiring full-stack developers or deep knowledge of orchestration frameworks. The sweet spot is workflows that are complex enough to benefit from branching, loops, and error handling, but not so specialized that writing code from scratch is justified.

Defining a Low Code Automation Flow

A low code automation flow is a sequence of steps executed in response to an event or trigger. Each step performs an action—such as querying a database, sending an HTTP request, or updating a ticket—using a visual interface or a configuration file. The flow is defined using a declarative format that describes:

Triggers: how the automation starts (e.g., a new row in a database, a webhook, a timer).
Actions: side-effecting operations (e.g., send-email, create-ticket, run-python-script).
Conditions: branching logic based on data (e.g., if status == "failed" then send-alert).
Variables: data storage and transformation across steps.
Error handling: how the flow responds to failed actions.

Flows are typically versioned, deployed, and monitored as atomic units. The input to a flow is a JSON object, and the output is a JSON object or a set of side effects (e.g., updated records, sent messages, triggered jobs).

Example Flow Definition

{
  "name": "New Vendor Onboarding",
  "description": "Automatically provision a new vendor across systems.",
  "version": "1.2",
  "trigger": {
    "type": "webhook",
    "path": "/webhook/vendor-onboard"
  },
  "steps": [
    {
      "id": "1",
      "type": "action",
      "name": "Create Vendor Record",
      "action": "create-vendor",
      "input": {
        "name": "{{ payload.name }}",
        "contact_email": "{{ payload.email }}",
        "category": "{{ payload.category }}"
      }
    },
    {
      "id": "2",
      "type": "condition",
      "condition": "{{ data.vendor.category == 'premium' }}",
      "true_branch": [
        {
          "id": "2a",
          "type": "action",
          "name": "Send Premium Welcome Email",
          "action": "send-email",
          "input": {
            "to": "{{ data.vendor.contact_email }}",
            "subject": "Welcome to Premium Vendor Program",
            "body": "Thank you for joining..."
          }
        }
      ],
      "false_branch": [
        {
          "id": "2b",
          "type": "action",
          "name": "Send Standard Welcome Email",
          "action": "send-email",
          "input": {
            "to": "{{ data.vendor.contact_email }}",
            "subject": "Welcome to Vendor Program",
            "body": "Thanks for signing up!"
          }
        }
      ]
    },
    {
      "id": "3",
      "type": "action",
      "name": "Update CRM",
      "action": "update-crm",
      "input": {
        "vendor_id": "{{ data.vendor.id }}",
        "status": "active"
      }
    }
  ],
  "error_handling": {
    "strategy": "retry",
    "max_retries": 3,
    "retry_delay_seconds": 30,
    "on_failure": {
      "send_alert": {
        "channel": "slack",
        "message": "Vendor onboarding failed: {{ error.message }}"
      }
    }
  }
}

This flow is triggered by a POST request to /webhook/vendor-onboard. The payload contains name, email, and category. The flow creates a vendor record, branches based on category, and sends a tailored email. It updates a CRM and handles errors by retrying up to three times, with a 30-second delay between retries, and sends an alert on failure.

Executing a Flow

When a trigger fires, the automation engine:

Validates the input payload against a schema defined in the flow.
Instantiates a new execution context with a data object initialized from the input.
Runs steps sequentially, resolving expressions (e.g., {{ data.vendor.id }}) at runtime.
Tracks state of each execution, including timestamps, outputs, and logs.

The engine supports expression language for dynamic values, using a syntax similar to mustache or Jinja. Expressions are evaluated in the context of the current data object and any available variables.

Common Expression Patterns

{{ payload.email }} — access root input.
{{ data.vendor.name }} — access data from a previous step.
{{ now() }} — current timestamp.
{{ format_date( now(), "YYYY-MM-DD" ) }} — formatted date.
{{ join( data.tags, ", " ) }} — join array of strings.

Expressions are evaluated immediately before each step and after every action. This allows a step to use the output of a previous action as its input.

Execution Logs and Debugging

Each flow execution is logged with:

Step start and end timestamps.
Input and output data per step.
Error messages with full stack traces.
Variable snapshots at key points.

On failure, the engine logs:

{
  "execution_id": "exec-12345",
  "flow_name": "New Vendor Onboarding",
  "status": "failed",
  "error": {
    "message": "Failed to send email: 500 Internal Server Error",
    "code": "email_send_failed",
    "details": {
      "request": {
        "url": "https://api.email.com/send",
        "method": "POST",
        "body": {
          "to": "[email protected]",
          "subject": "Welcome to Premium Vendor Program"
        }
      },
      "response": {
        "status": 500,
        "body": "Internal server error: database connection failed"
      }
    },
    "step_id": "2a"
  }
}

Logs are accessible via a standard API:

GET /api/executions/exec-12345/logs

Response:

[
  {
    "step_id": "1",
    "start_time": "2023-10-05T14:23:11Z",
    "end_time": "2023-10-05T14:23:13Z",
    "input": { "name": "Acme Inc", "email": "[email protected]", "category": "premium" },
    "output": { "id": 456, "status": "created" },
    "status": "success"
  },
  {
    "step_id": "2a",
    "start_time": "2023-10-05T14:23:13Z",
    "end_time": "2023-10-05T14:23:15Z",
    "input": { "to": "[email protected]", "subject": "Welcome to Premium Vendor Program", "body": "Thank you for joining..." },
    "error": {
      "message": "Failed to send email: 500 Internal Server Error",
      "details": { "response": { "status": 500, "body": "Internal server error: database connection failed" } }
    },
    "status": "failed"
  }
]

Managing Flow Versions and Deployments

Flows are versioned using semantic versioning (1.0, 1.1, 2.0). Each version is immutable and can be deployed independently.

Deployment Process

Create a new version by editing the flow in a visual editor or modifying the JSON.
Test the version by simulating input payloads.
Deploy the version to a target environment (e.g., staging, production).
Promote the version using a change request or CI/CD pipeline.

Deployment is atomic: when a version is promoted, all new triggers use the new definition, and existing executions continue using the version they were started with.

Versioning and Backward Compatibility

When a flow is updated, the engine maintains backward compatibility:

New fields in the input schema are optional.
Missing fields in the input are treated as null.
The engine can resolve expressions using both old and new data structures.

If a new step expects a field data.vendor.onboarding_date that did not exist in version 1.0, the engine fills it as null unless explicitly provided.

Promoting a Version

curl -X POST https://api.automation.example.com/flows/new-vendor-onboarding/deploy \
  -H "Content-Type: application/json" \
  -d '{
    "version": "1.3",
    "environment": "production",
    "description": "Add support for vendor contracts.",
    "inputs": {
      "name": "Acme Inc",
      "email": "[email protected]",
      "category": "premium"
    }
  }'

The engine responds:

{
  "deployment_id": "deploy-789",
  "flow_name": "New Vendor Onboarding",
  "version": "1.3",
  "environment": "production",
  "status": "started",
  "triggered_by": "user:alice",
  "execution_id": "exec-12346"
}

The deployment runs the flow with the provided input and returns the execution ID. The flow is now active in production.

Error Handling and Recovery

Low code flows are resilient but not foolproof. The most common failure modes include:

Missing or malformed input data.
Transient failures in external APIs (e.g., HTTP 503, timeout).
Invalid expressions (e.g., {{ data.vendor.abc }} when data.vendor is missing).
Step-specific errors (e.g., database constraint violation).

The engine supports retry strategies:

Immediate retry: retry on failure, no delay.
Exponential backoff: delay increases with each retry.
Fixed delay: constant interval between retries.

Retry Configuration

"error_handling": {
  "strategy": "exponential",
  "max_retries": 5,
  "base_delay_seconds": 10,
  "max_delay_seconds": 300,
  "on_failure": {
    "send_alert": {
      "channel": "slack",
      "message": "Flow failed after {{ retries }} attempts: {{ error.message }}"
    },
    "mark_as_failed": true
  }
}

On failure, the engine:

Retries the step up to max_retries times.
Applies a delay based on the strategy.
Updates the flow state with retry count and last error.
Executes the on_failure actions after all retries.

On recovery, the flow resumes from the failed step.

Integrating with External Systems

Low code flows interact with external systems via actions—predefined or custom functions that can be invoked.

Built-in Actions

send-email: sends an email using SMTP or a cloud service.
create-ticket: creates a ticket in a service desk.
run-python-script: executes a Python script with input data.
query-database: runs a SQL query and returns results.
call-webhook: makes an HTTP request to an external endpoint.

Each action has a signature defined by input parameters and output schema.

Custom Action Registration

Actions are registered via a standard API:

POST /api/actions

Request body:

{
  "name": "send-invoice",
  "description": "Sends an invoice PDF via email.",
  "input_schema": {
    "type": "object",
    "properties": {
      "invoice_id": { "type": "string" },
      "to": { "type": "string" },
      "cc": { "type": "array", "items": { "type": "string" } }
    },
    "required": [ "invoice_id", "to" ]
  },
  "output_schema": {
    "type": "object",
    "properties": {
      "sent": { "type": "boolean" },
      "message_id": { "type": "string" }
    }
  },
  "code": "def send_invoice(input_data): ...",
  "runtime": "python3.11"
}

The engine validates input against input_schema, runs the code, and returns output_schema.

Action Execution

When a flow calls an action, the engine:

Validates input against the action’s schema.
Serializes input to JSON.
Invokes the action via HTTP or in-process.
Processes output and updates the data object.

On failure, the engine logs the input and output of the action, and the full error stack.

Best Practices and Common Pitfalls

Use variables to store intermediate results across steps. Avoid repeating expressions.
Define input schemas for all flows to catch malformed payloads early.
Avoid deep nesting in conditions; prefer flat, readable step sequences.
Use error logs to debug failures—the execution_id is the key to tracking down issues.
Version actions independently of flows; a change to send-email affects all flows using it.
Monitor execution duration—a slow flow may indicate bottlenecks in actions or network calls.
Use data object to pass context between steps, rather than relying on global state.

The most silent failure: a flow runs, but a step is never triggered because an expression evaluates to false due to a typo in a field name (data.vendor.category vs. data.vendor.categories).

Another subtle issue: the engine evaluates expressions only at step start, so if a step takes 10 seconds, and a database record is updated during that time, the step sees the old state.

Finally, deployment without testing leads to silent failures: a new flow version is deployed, but a required input field is missing, causing the flow to fail on every trigger.

This page was rewritten on 18 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.