Skip to main content
Overview Trigger conditions let you control which trigger templates execute based on the status of a sensor’s dependencies in Argo Events. A sensor can declare multiple dependencies and multiple triggers; each trigger may include a boolean expression that references dependency names to determine when it should run. This guide explains how condition expressions work, shows examples, and walks through a practical sensor that uses a MinIO event and a webhook to drive two triggers: one that submits an Argo Workflow and another that sends an HTTP request. Relevant links and references Trigger conditions explained
  • Conditions are boolean expressions referencing dependency names defined in the sensor’s dependencies list.
  • Supported operators: && (AND), || (OR). Parentheses are supported for grouping.
  • If a trigger template omits conditions, it defaults to requiring all dependencies (implicit AND across all declared dependencies).
Operators summary
OperatorMeaningExample
&&ANDdepA && depB
OR`depAdepB`
( )Grouping`(depAdepB) && depC`
Simple example: sensor with three dependencies and three triggers 
apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: example
spec:
  dependencies:
    - name: dep01
      eventSourceName: webhook-a
      eventName: example01
    - name: dep02
      eventSourceName: webhook-a
      eventName: example02
    - name: dep03
      eventSourceName: webhook-b
      eventName: example03
  triggers:
    - template:
        name: trigger01
        conditions: "dep02"
        http:
          url: http://abc.com/hello1
          method: GET
    - template:
        name: trigger02
        conditions: "dep02 && dep03"
        http:
          url: http://abc.com/hello2
          method: GET
    - template:
        name: trigger03
        conditions: "(dep01 || dep02) && dep03"
        http:
          url: http://abc.com/hello3
          method: GET
Example evaluations
  • conditions: "dep02" — trigger runs when dependency dep02 is satisfied.
  • conditions: "dep02 && dep03" — trigger runs when both dep02 and dep03 are satisfied.
  • conditions: "(dep01 || dep02) && dep03" — trigger runs when dep03 is satisfied and at least one of dep01 or dep02 is satisfied.
Practical multi-dependency sensor (MinIO + webhook) Below is a real-world sensor manifest that demonstrates two dependencies and two triggers:
  • hello-workflow-trigger submits an Argo Workflow and only fires when the MinIO dependency is satisfied.
  • http-trigger posts to an external HTTP endpoint and fires when either dependency is satisfied.
apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: multi-dependency-sensor-2
  namespace: argo-events
spec:
  dependencies:
    - name: test-dep
      eventSourceName: minio
      eventName: example
    - name: my-webhook-dep
      eventSourceName: webhook
      eventName: my-webhook
  triggers:
    - template:
        name: hello-workflow-trigger
        # Use a service account that has permission to create Workflows in the 'argo' namespace
        serviceAccountName: workflow-trigger-sa
        conditions: "test-dep"
        argoWorkflow:
          source:
            resource:
              apiVersion: argoproj.io/v1alpha1
              kind: Workflow
              metadata:
                generateName: hello-kodekloud-
                namespace: argo
              spec:
                entrypoint: whalesay
                templates:
                  - name: whalesay
                    container:
                      image: rancher/cowsay
                      command: ["cowsay"]
                      args: ["Triggering workflow from Argo Events"]
    - template:
        name: http-trigger
        conditions: "test-dep || my-webhook-dep"
        http:
          url: https://httpdump.app/inspect/ee487aa0-994f-4b9f-83dd-a65e668ccfc8
          method: POST
          payload: |
            {
              "bucket": "{{dependency.test-dep.data.notification.0.s3.bucket.name}}",
              "type": "{{dependency.test-dep.context.type}}"
            }
        retryStrategy:
          steps: 3
          duration: 3s
Notes about the workflow trigger and RBAC
  • The workflow trigger sets serviceAccountName: workflow-trigger-sa. That service account must have RBAC permissions (Role/ClusterRole and corresponding RoleBinding/ClusterRoleBinding) that allow creating Workflows in the argo namespace.
  • If the trigger uses the default service account (or a service account lacking permissions), the Workflow creation will fail with a permission error.
Testing the configuration
  1. Expose the webhook event source locally (port-forward) and send a test event:
kubectl -n argo-events port-forward svc/webhook-eventsource-svc 13000:13000
# In another terminal:
curl -d '{"message":"hello"}' -H "Content-Type: application/json" -X POST http://localhost:13000/push
# Expected response:
# success
  1. Create a MinIO credentials secret in the argo-events namespace:
kubectl -n argo-events create secret generic minio-creds \
  --from-literal=accesskey=admin \
  --from-literal=secretkey=password
# Output:
# secret/minio-creds created
  1. Trigger the external HTTP endpoint used by the HTTP trigger (example using httpdump):
curl --header "Content-Type: application/json" \
  --request POST \
  --data '{"username":"Marcel","password":"supersecret","this is a":"test"}' \
  https://httpdump.app/dumps/6758c612-9d34-486f-b82a-63c0a7dc4054
Sensor logs and troubleshooting When triggers run or fail, inspect sensor logs to diagnose behavior:
  • Successful HTTP trigger logs (example):
namespace=argo-events, sensorName=multi-dependency-sensor-2, triggerName=http-trigger, level=info, time=2025-10-25T11:41:03Z, msg=Making a http request...
namespace=argo-events, sensorName=multi-dependency-sensor-2, level=info, time=2025-10-25T11:45:16Z, msg=Successfully processed trigger 'http-trigger'
  • RBAC/permission error for Workflow trigger (example):
time="2025-10-25T11:43:28.979Z" level=error msg="Create request failed" error="workflows.argoproj.io is forbidden: User \"system:serviceaccount:argo-events:default\" cannot create resource \"workflows\" in API group \"argoproj.io\" in the namespace \"argo\""
Error: Failed to submit workflow: rpc error: code = PermissionDenied desc = "workflows.argoproj.io is forbidden: User \"system:serviceaccount:argo-events:default\" cannot create resource \"workflows\" in API group \"argoproj.io\" in the namespace \"argo\""
Fixes:
  • Ensure the trigger template includes serviceAccountName (as shown in the sensor YAML).
  • Grant that service account the necessary RBAC roles to create Workflows in the target namespace.
Event flow and UI A visual graph helps map how event sources, sensors, dependencies, conditions, and triggers relate. The UI shows nodes for event sources, sensors, each dependency, and the triggers that fire when conditions are met.
A screenshot of the Argo Events "Event Flow" web UI showing a visual node graph of event sources, sensors, conditions, and workflow triggers. Visible nodes include labels like "example", "my-webhook", "minio", "webhook-sensor", "multi-dependency-sensor-2", "test-dep", and "hello-workflow-trigger".
When everything is configured and RBAC is correct, triggers will execute and generate expected outputs — for example, HTTP dumps and Argo Workflows. After updating the sensor to include the proper service account, a new workflow should appear in the Argo Workflows list.
A screenshot of the Argo Workflows web UI showing a list of workflow entries with names, namespaces, start/finish times, durations and progress. A left sidebar shows filters and a workflow summary, and the top has buttons to submit new or view completed workflows.
Summary
  • Use dependency names inside conditions expressions to control trigger execution.
  • Use && and || to combine dependency conditions; parentheses support grouping.
  • If conditions is omitted, all sensor dependencies must be satisfied (implicit AND).
  • For Argo Workflow triggers, set serviceAccountName and ensure the service account has RBAC permissions to create Workflows in the target namespace.
Tip: When testing triggers, inspect sensor logs (kubectl -n <ns> logs <sensor-pod>) to see why a trigger did or didn’t execute. Permission errors and missing dependency events are common causes for trigger failures.

Watch Video

Practice Lab