Core Concepts

This page explains the core entities you will work with when building automations. Understanding these concepts makes the UI and configuration straightforward.

Events

An Event is a single unit of work. It is created when a Source fires and carries:

An Event Type — what kind of task should run
A payload — a JSON document of data passed to the executing module
A state — tracks where the event is in its lifecycle

Event States

State	Meaning
`QUEUED`	Waiting for an available Sink
`RUNNING`	A Sink is currently executing the task
`SUCCESS`	Completed successfully
`WARNING`	Completed with warnings
`ERROR`	Failed

Events are never deleted automatically. They accumulate as an audit trail and can be queried and filtered on the Events screen.

Event Types

An Event Type is a named definition that describes:

Which Sink Type should execute the task (e.g. a Python sink, a PowerShell sink)
Which Source Type is allowed to fire it
Which Action to run when the event dispatches

Think of an Event Type as a template. One Event Type can be triggered by many individual events over time.

Each Event Type can have Parameters — key/value pairs that are injected into the task at runtime. Parameter types:

Type	Behaviour
`STATIC`	A fixed value baked into the Event Type definition
`DATA`	A key name that is read from the event payload at runtime
`SECRET`	A secret key resolved from the Secrets store at runtime

Actions

An Action defines the code that executes when an Event Type fires, and controls what happens after execution.

An Action has:

A module — the Python import path of the code to run (e.g. my_module.runner)
On Success — optionally chain to another Event Type when the task succeeds
On Failure — optionally chain to another Event Type when the task fails
Parameters — additional data/secret params injected at runtime

Actions are reusable — the same Action can be linked to many Event Types. This makes it easy to share common tasks (e.g. a notification module) across different triggers.

Chaining

When an Action has an On Success or On Failure target set, the Hub automatically creates a follow-on event when the task completes. The result data from the first task becomes the payload of the follow-on event.

This allows you to build multi-step pipelines:

flowchart TD W["Webhook fires"] S1["Step 1: transform data"] S2["Step 2: write to database"] S3["Step 3: send notification"] W --> S1 S1 -->|On Success| S2 S2 -->|On Success| S3

Sources

A Source is a registered instance of a source client — for example, a specific webhook endpoint or a running EventGrid consumer.

Sources are associated with a Source Type, which defines what kind of source it is (webhook, scheduler, EventGrid, or custom).

Sinks

A Sink is a registered agent process running in your infrastructure. It connects outbound to the Hub and waits for tasks.

Sinks are associated with a Sink Type, which defines what code the agent can run (Python, PowerShell, custom).

When you deploy a sink agent, it registers itself with the Hub and appears on the Sinks screen. From there you can see its status, last seen time, and send control signals.

Schedules

A Schedule is a cron expression linked to an Event Type. The Scheduler source evaluates all active schedules and fires the corresponding Event Type at the configured time.

Cron expressions follow standard 5-field format:

┌───── minute (0-59)
│ ┌──── hour (0-23)
│ │ ┌─── day of month (1-31)
│ │ │ ┌── month (1-12)
│ │ │ │ ┌─ day of week (0-6, Sunday=0)
* * * * *

Examples:

Expression	Meaning
`0 9 * * 1-5`	Every weekday at 09:00
`/15 * * *`	Every 15 minutes
`0 0 1 * *`	First day of every month at midnight

Schedules can optionally be pinned to a specific Sink so the task always runs on a particular agent.

Secrets

Secrets are tenant-scoped key/value pairs stored securely in Nexomatic. Values are write-only — they cannot be retrieved through the UI after creation.

Sink modules access secrets at runtime via the Hub. This means credentials never need to be embedded in code or passed in event payloads.

Reference a secret in an Action or Event Type parameter by setting the parameter type to SECRET and the value to the secret’s key name.

Logs

Every task execution produces a Log — structured records written by the module during execution, plus a raw log file containing full stdout output.

Logs are retained for a configurable period. Older logs are transparently archived to blob storage and remain queryable from the Logs screen.