Skip to content
Weik.ioDocs
2026.1
Try Weik.io

This page describes Weik.io 2026.1, and the current release is 2026.2. Weik.io 2026.2 docs

Actions

Weik.io 2026.1

Create reusable automation units that respond to triggers.

On this page

Actions are reusable units of automation. Write an Action once and trigger it from multiple places, instead of duplicating the same logic across several scheduled tasks.

Why use Actions?#

An Action is a self-contained piece of code that does one thing. It expects input parameters, runs its logic, and returns a success or failure result.

Because they are self-contained, you can:

  • Trigger them from an event (for example, when a new order arrives)
  • Run them on a schedule (for example, a nightly cleanup)
  • Execute them manually from the dashboard for one-off tasks
  • Call them directly via API

Writing Action code#

You write Actions in C# or Python. They receive an ActionContext that contains the parameters passed in by the trigger.

C# example

public class SendEmailAction
{
    public async Task<ActionResult> Execute(ActionContext context)
    {
        // Read the parameters passed by the trigger
        var to = context.Parameters["to"];
        var subject = context.Parameters["subject"];
        var body = context.Parameters["body"];

        await emailService.SendAsync(to, subject, body);

        // Return an ActionResult so the platform knows whether the Action succeeded
        return ActionResult.Success($"Email sent to {to}");
    }
}

Python example

async def execute(context):
    api_url = context.parameters['api_url']
    data = context.parameters['data']

    response = await http.post(api_url, json=data)

    return {
        'success': response.status_code == 200,
        'response': response.json()
    }

Defining parameters#

You define the parameters your Action expects using a YAML spec. The platform validates inputs against this spec before the code runs.

apiVersion: weik.io/v1alpha1
kind: Action
metadata:
  name: process-order
spec:
  parameters:
    - name: orderId
      type: string
      required: true
      description: Order identifier

    - name: processType
      type: string
      required: false
      default: "standard"
      values: ["standard", "express", "priority"]

Triggering an Action#

Actions run only when a trigger invokes them.

Event triggers#

You can configure an Action to run in response to specific platform events:

apiVersion: weik.io/v1alpha1
kind: EventTrigger
metadata:
  name: order-created-trigger
spec:
  eventSource: orders
  eventType: order.created
  action: process-order
  parameters:
    # Map the event data into the Action's expected parameters
    orderId: "{{event.data.orderId}}"
    processType: "{{event.data.priority}}"

Schedule triggers#

Run the Action on a cron schedule:

apiVersion: weik.io/v1alpha1
kind: ScheduleTrigger
metadata:
  name: daily-cleanup
spec:
  schedule: "0 2 * * *"  # 2 AM daily
  action: cleanup-temp-files

Direct API calls#

An external system can start a workflow by calling the Action directly:

POST /api/actions/process-order/execute
{
  "orderId": "12345",
  "processType": "express"
}

Handling failures#

Actions can fail for many reasons, such as API timeouts or locked database resources. You can handle errors manually in your code, or let the platform handle retries.

Platform retries#

You can configure Weik.io to automatically retry the Action if it throws an exception:

apiVersion: weik.io/v1alpha1
kind: Action
metadata:
  name: resilient-action
spec:
  retry:
    maxAttempts: 3
    backoff: exponential
    initialDelay: 1s
    maxDelay: 30s

Manual error handling#

Some failures should not be retried. For example, retrying does not help when a user passes an invalid email address.

public async Task<ActionResult> Execute(ActionContext context)
{
    try
    {
        var result = await ProcessData(context.Parameters);
        return ActionResult.Success(result);
    }
    catch (ValidationException ex)
    {
        // A validation error is a permanent failure. Return failure instead of throwing.
        return ActionResult.Failure($"Validation failed: {ex.Message}");
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "Network timeout during processing");

        // Throwing the exception tells the platform to use the Retry policy
        if (context.RetryCount < 3)
        {
            throw; 
        }

        return ActionResult.Failure($"Action failed after 3 retries: {ex.Message}");
    }
}

Best practices#

Make Actions idempotent If an Action fails partway through and the platform retries it, side effects such as payments can run twice. Design your Actions so that running them twice with the same parameters produces the same result as running them once.

Validate input early Check required parameters at the start of your function so the Action fails fast when input is missing or invalid.

Keep Actions small An Action should do one thing. Instead of a single Action such as ProcessOrderAndSendEmailAndSyncCRM, split it into three Actions and connect them with an Integration Flow.

Next steps#