Verentis

Triggers & schedules

Triggers & schedules

Run your engine automatically — on a cron schedule, or in response to file changes in the workspace.

Engines don't only run when a user clicks Run. With the scheduled and event-driven execution modes, your engine runs automatically.

Enabling automatic runs

Declare the modes your engine supports:

spec:
  execution-modes:
    - request-response
    - scheduled
    - event-driven

The schedule and trigger definitions themselves live as manifests in the workspace VFS (the same install-by-file model used everywhere). Adding the manifest creates the rule; removing it deletes it.

Schedules (cron)

A schedule runs your engine on a cron expression — for example a nightly report or an hourly sync.

api-version: verentis.io/v1
kind: ExecutionSchedule

metadata:
  id: nightly-report
spec:
  engine: python
  target: /scripts/report.py
  cron: "0 2 * * *"          # 02:00 every day
  run-as:
    service: reporting-bot   # the workspace service the run acts as
cronstring

Standard cron expression for when to run.

engine / target

Which engine to run and the file it operates on.

run-as.service

The workspace service the run acts as. Automated runs use a service principal, not a user.

Triggers (file changes)

A trigger runs your engine when files change in the workspace — for example, process every CSV dropped into a folder.

api-version: verentis.io/v1
kind: ExecutionTrigger

metadata:
  id: process-uploads
spec:
  engine: python
  on:
    - path: /incoming/**
      events: [created, updated]
  run-as:
    service: ingest-bot
on[].path

A path or glob to watch in the VFS.

on[].events

Which change events fire the trigger (e.g. created, updated).

run-as.service

The service the triggered run acts as.

Triggers can fire more than once per change

A single upload can produce multiple change events (for example a create plus a head update). Make your engine idempotent: running it twice for the same input should be safe and produce the same result.

Triggers (webhooks)

A trigger can also run when an app's webhook receiver accepts a delivery from an external system.

spec:
  on:
    - event: webhook-received
      receiver: sugarcrm-changes   # the WebhookReceiver's metadata.id
      event-type: "Accounts.*"     # optional glob (* and ?), case-insensitive
  execute:
    engine: python
    file: /scripts/sync-changed.py
    arguments: ["--id", "{webhook.resourceId}"]

The arguments support {webhook.eventId}, {webhook.eventType}, {webhook.resourceType}, {webhook.resourceId} and {webhook.source}. Webhook triggers run execute targets only.

run-as and identity

Scheduled and triggered runs have no signed-in user, so they act as a service principal — a workspace service you reference by name. The platform resolves that name to a stable service identity and mints a scoped token for the run. Give automated work a dedicated service with only the scopes it needs.

Per-user agent schedules

A schedule that runs an agent can use run-as: { user: subscribers } instead. It then runs once for each user who subscribed to it in the workspace, as that user, so the agent sees each person's own files. Users opt in, and approvals go to them.

Derived service identity

A workspace service has a deterministic identity derived from the workspace and the service name, so the platform can resolve run-as.service without a lookup. Keep service names stable.

Next

Testing your engine

Test your logic, container and manifest before you publish.

Platform APIs & auth

Authenticate and call the Verentis API.