Automations & Monitoring

Automations is Aptli's integration layer — the way your deployment reacts to what happens inside it and connects to systems outside it. It covers four things: automations that run actions when events occur, connections that link Aptli to systems outside it in either direction, ingestion that brings sensor and event data in, and monitoring that turns that incoming data into readings, alarms, and outcomes.

Automations is included in every plan. What's metered is the number of connections and API keys you have — see The connection allowance below.

The pages at a glance

Automations lives in its own Integrations navigation group:

Alarms don't have a page of their own — they're ambient: a bell notification, a card on your home dashboard, and pins on the map, with a direct link into the full alarm ledger when you need it.

Automations — WHEN / IF / THEN, grouped by connection

An automation is a rule in the full trigger → conditions → actions shape, shown as a plain-language sentence: WHEN something happens, IF its conditions hold, THEN one or more actions run. Start a new one from the What should happen automatically? recipe gallery, or drop into the full editor.

The list groups your automations by the connection the first outbound action in each one uses — so everything wired to a particular webhook or database sits together — plus an Internal group for automations whose actions never leave Aptli (set a field, create a record, send a notification). Switch between a card view and a table, bulk enable, disable, or delete, and every edit stages in the version buffer like any other change until you submit it.

Triggers

Triggers are grouped by the part of Aptli they come from. A selection:

• Work — workOrder.created, workOrder.statusChanged, workOrder.reassigned, report.created, report.submitted, report.completed, report.validated, report.rejected, validation.statusChanged
• Projects & jobs — project.created, project.statusChanged, project.deleted, job.created, job.removed
• Inventory — inventory.created, stock.adjusted, stock.consumed, stock.consolidated, stock.droppedOff
• Imports & versions — geo.import.completed, geo.import.failed, version.submittedForReview, version.committed
• Users, files, help requests — user.invited, file.uploaded, file.quarantine_failed, helpRequest.created, helpRequest.statusChanged
• Public submissions — portalSubmission.created, fired when someone files a request through a Service Portal. Outbound-only — see Public and sensor triggers below.
• Sensor & event ingestion — sensor.reading (a numeric reading came in) and ingest.event (an external happening came in, deduplicated by its own external id) — the bridge from ingestion to automation. Both outbound-only.
• Alarms — alarm.raised and alarm.resolved. Unlike the ingestion triggers above, these are internally raised and trusted, so they carry the full action palette — a breach can create a work order, update a field, or notify someone, not just call out.
• Scheduled — schedule.daily, schedule.weekly, schedule.monthly
• SLA timers — timer.threshold, timer.expired, timer.escalated (emitted by running lifecycle timers)

Public and sensor triggers are outbound-only

portalSubmission.created, sensor.reading, and ingest.event all originate outside a login — a member of the public, a sensor, or a polled feed. Automations on these triggers may only notify someone or call out (webhook, database write, file delivery); they can never create or change an internal record directly. This keeps an unauthenticated source from ever writing to your data, even by accident.

Conditions

Conditions narrow when a trigger fires, evaluated against the event context and ANDed together (all must pass):

• workOrder.status == 'completed' — only on completion
• actor.email endsWith '@myorg.com' — only internal users
• job.featureCount > 1000 — only large imports

Actions

Every automation has a built-in Test run panel — one button that fires it against a synthesised sample context for its trigger. Two things to know before you use it: it skips the conditions (it runs the actions directly), and it is not a dry run — outbound actions (webhook, Postgres, artifact delivery) execute for real against your configured destinations, just flagged with a test badge in Activity. Emails are checked but not sent, and record-mutating actions (create/update) are skipped. So point a test at a safe destination; it's for confirming wiring, not a no-op preview.

Run automation, right now, for one record

Some automations can also be fired manually against a single record, from that record's own menu — a supervisor's judgment call instead of waiting for the trigger to occur naturally. It's available on work orders, reports, stock items, and Service Portal submissions, for automations whose full context can be read straight off the record as it stands. It's gated on your right to update that record, not on automations administration, since running it is simply using a rule someone already vetted — with a short cooldown per record so the same rule can't be re-fired back to back by accident.

Connections — every link to the outside world

The Connections page lists every link between Aptli and something outside it, split into data coming in and data going out. Each one shows its direction, how it moves (a plain-language transport label), and a health line — when it last ran and whether that run succeeded.

Set one up with the Connect wizard: pick a direction, pick how it moves, then fill in the details and test it live before saving.

• Inbound, pushed — the sender POSTs to Aptli. Saving mints an API key, shown once — copy it then.
• Inbound, polled — Aptli checks a vendor on a schedule. Pick a vendor (a generic JSON source, a traffic-events feed, or a generic RSS/Atom feed for article- or announcement-style content) and fill in its connection details; a Manage sources panel is where you go back and edit those settings later.
• Outbound, webhook — give it a destination URL and test it with a real signed request before saving.

Devices and Credentials are reached from this page rather than being nav destinations of their own.

Devices

A device is a registered sensor or gateway with its own record — distinct from a map feature — showing a live map overlay and an at-a-glance fleet-health state: ok, stale, no data, or alarm. Readings key either to the device's own id, or to a sender-controlled code when a device reports under its own naming.

Credentials

An escape hatch for admins: the secrets outbound actions authenticate with (bearer / basic / API-key HTTP, S3, Postgres), created once and referenced by name. Secrets are encrypted at rest and never shown again after saving; non-secret configuration stays readable.

The connection allowance

The commercial meter is the number of connections and API keys, not the feature itself. Each live connection (either direction) and each standalone API key consumes one unit from a shared pool — a key attached to a push connection rides that connection's unit; the automations themselves are unmetered. The default allowance is 3; when you hit it, creating another prompts you to remove an unused one or contact support to add more. Connections you already have keep running if the allowance later shrinks.

Ingestion — bringing sensor and event data in

Ingested data flows through two lanes:

• Readings — a numeric time series (a sensor's value at a point in time). Every batch fires the sensor.reading trigger and feeds the alarm engine described below.
• Events — an external happening with its own identity, and often a location and a time window (an article being published, a traffic incident). Each one fires the ingest.event trigger, deduplicated by its own external id so re-polling the same source never creates duplicates.

Both lanes accept data pushed to Aptli or pulled from a vendor on a schedule, and both funnel through the same pipeline: store it, update the connection's health, log the activity, and check it against alarms.

Monitoring & Alarms

Ingestion gets sensor data in; monitoring is what you see and are warned about.

Readings

Once readings are flowing for a connection, its record — or the device's record — shows the latest value and unit for each metric, plus a 7-day sparkline.

Alarms

Alarm rules live on the connection. Turn on Raise alarms and set:

• Alarm when value is — above or below a threshold
• Clear margin — how far back past the threshold a reading must go before the alarm auto-clears (hysteresis, so a value hovering on the line doesn't flap)
• Silence alarm after (minutes) — raise a silence alarm if no data arrives for this long (push connections only — a poll connection's own health line already shows when a check fails)
• Alarm recipients — who gets notified
• Escalate if unacknowledged after (minutes) + Escalation recipients — a second tier if no one acknowledges in time

Every signed-in user can see the live alarm ledger — watching alarms is an operations task, not a configuration one — but acknowledging or resolving an alarm requires automations administration rights. Each alarm is Active, Acknowledged, or Resolved (alarms also auto-clear when the reading recovers past the clear margin); it carries its value, threshold, and peak, who acknowledged it, and — if it escalated — an "Escalated {date}" line with a delivery-status badge. A home-dashboard card and map pins surface active alarms so they don't sit unseen.

Two-way ticket loop

A Call webhook action can carry a write-back capability: your external ticketing system POSTs a status change back to acknowledge or resolve the alarm using a one-time token, and the ticket's reference shows on the alarm as a link. This closes the loop when alarms are handled in another tool.

Outcomes and share links

On a project, the Outcomes tab charts monitored metric series against completed-work milestones — see Projects. You can publish a read-only, tokenized share link of those charts for outsiders, and revoke it any time. Readings are shown for context alongside work dates; Aptli makes no causal claim and the page is explicitly not certified measurement data.

Activity — the combined log

The Activity page is a single, filterable feed of every outbound attempt and inbound pull: date, automation or connection, outcome (Success / Failed / Retrying / Dead letter), attempt count, duration, and any error. Test runs are badged. Failed items get a one-click Retry, and you can deep-link straight into one connection's history.

Quick Connect

For common integrations, the Quick connect wizard walks you through a recipe instead of the raw editor — e.g. "Send new portal submissions to my system," "Alert my system when stock runs low," "Create a ticket when an alarm is raised," or "Receive readings from my sensors or gateway." It wires the connection and automation for you.

Permissions

Automations doesn't use the global admin-rights grid. The Automations and Connections pages — and acknowledging or resolving alarms — are gated by a viewers / modifiers allow-list in the automations settings, so you grant access explicitly. Viewing the alarm ledger is intentionally open to any signed-in user — watching alarms is an operations task, not a configuration one. Holders of the application-settings right always have a recovery path if the lists are empty.