NEQTOai
Start Free Trial

Platform Documentation

/

Actions

An Action is one outbound response: a single alert paired with a single place to push a payload. When a threshold alert fires and you have configured it to push data to an integration or a Device Endpoint, that pairing is an Action. The Actions page, under Alerts inside an application, lists every one of them — what fires it, where it would send, and whether it has been approved to send at all.

Approval and enablement are two separate decisions. Approving an Action says this payload, going to this destination, is correct. Enabling records the decision to send it on every firing once enforcement is switched on. They are recorded separately and revoked separately, and changing an Action’s configuration invalidates its approval so that somebody has to look again.
Enforcement is not switched on yet, so read the states as a review record. Today a payload goes out because a target is configured on an alert that fired — not because the Action reached a particular state on this page. An Action still reading Not approved is very likely still pushing on every firing. Approving and enabling are being recorded now so that the gate can be switched on later without cutting off deliveries that were already running; until that happens, this page tells you what has been reviewed, not what is allowed through.

Two things the approval does gate today, and the server enforces both for itself whatever this page shows. Enable is refused unless the Action carries a current approval. Test send is refused on the same basis, with one exception: a Sending unapproved Action can be tested without any approval on record, because it is already pushing to that destination on every firing.

Actions are not created here. An Action comes into being when you add a payload push target on an alert’s Payload Push tab. This page is where you review, approve, enable and test what those targets will do. To change what is sent, or to add and remove destinations, edit the alert on the Alerts page.

Seeing the list needs permission to view alerts. Approving needs the separate Approve outbound actions permission. Enabling needs permission to edit alerts. Dry run and test send need permission to edit alerts and to view both integrations and Device Endpoints; they do not require permission to approve an Action. Everyone who can see the list can see the buttons. If you lack a permission, the action fails when you use its button. Administration has the full permission table.

Quick Start

The path from a freshly configured push target to a reviewed, approved and enabled one.

  • 1
    Open Alerts > Actions inside your application. A newly configured target appears as Not approved.
  • 2
    Select Dry run on its row. Read the destination and the rendered payload. Nothing is sent.
  • 3
    Select Approve in that dialog. The state becomes Approved, off.
  • 4
    Optionally select Test send to put one real payload on the wire and confirm the destination receives it.
  • 5
    Select Enable and confirm. The state becomes Enabled, recording that this destination is reviewed and switched on.

The Actions List

One row per Action, covering both halves of the pairing: the alert that fires it and the target it pushes to.

Column What it shows
Trigger The alert that fires this Action, with a one-line summary of its conditions beneath the name.
Target The integration or Device Endpoint the payload goes to. The destination address is not shown here — open a dry run to see it.
Topic The topic the payload is published under. It is empty where the target’s own configured topic is used rather than an override. Two Actions sharing a target differ only by topic, so this column is what tells them apart.
Template A summary of the payload template. An em dash means this target has no template of its own and sends the alert type’s default body.
State One of the six states below.
Last outcome What the push queue last recorded for this target. See Last Outcome below.
Actions table with columns Trigger, Target, Topic, Template, State and Last outcome, holding two rows for the same alert. The first row reads Approved, off and its Last outcome reads Accepted by the queue, From a test send, with a date and time beneath; its Dry run, Test send and Enable buttons are all active. The second row reads Not approved, its Test send and Enable buttons are dimmed, and two grey notes beneath them read Approve this action before it can be enabled and Approve this action before it can send a test.
Two Actions on the same alert. The unapproved row’s controls are dimmed, and each says why.
Trigger inactive: an Action whose state says it would be sending — Enabled or Sending unapproved — shows a Trigger inactive note under its state badge when the alert behind it is disabled or deleted. Nothing is going to fire it, however green the badge reads. Rows in the other states show no such note, so a dead alert behind a Not approved row is not called out here.

The Six States

An Action’s state records its approval and enablement. It does not control automatic pushes yet; a configured target can still send when its alert fires, regardless of the state shown here.

State What it means Approved to send?
Not approved Nobody has reviewed this destination and payload yet. This is where every new push target starts. No
Approved, off Reviewed and approved, but the switch is off. This is the only state Enable is offered from. Yes, switched off
Enabled Approved and switched on. Yes
Config changed It was approved, and then the configuration moved underneath that approval — the template, the target or the topic changed. The approval no longer covers what would be sent, so it has to be re-approved. No, re-approval needed
Sending unapproved The legacy exemption. This push target predates the approval requirement and was grandfathered in, so it keeps sending even though nobody has reviewed the destination. Dry run it and approve it to bring it under the same gate as everything else. No, and sending anyway
Retired History. The alert or the target is gone, so there is nothing left to send. Retired rows are not listed. Cannot send

Dry Run

A dry run shows a sample of this Action’s payload without sending it.

Select Dry run on any row. The dialog shows the alert, the target’s name, its address, the transport and the topic, followed by the rendered payload. The address appears only here: it is deliberately kept out of the list so that the page does not hand every destination URL to anyone who can read alerts.

  • Sample: the alert event uses a labelled synthetic sample. The dialog names it so you can tell it apart from a real firing.
  • No template of its own: when the target has no payload template, the dialog says so and the rendering is the alert type’s default body.
  • Tokens resolve against live data: the sample reading is synthetic, but any {{tag.…}} or {{device.…}} token in your template is resolved to its real current value, so a token that cannot be resolved shows up here rather than on the first real firing.
Dry run dialog subtitled Nothing is sent. This only renders what the action would push. A list gives Alert, Target, Address, Transport and Topic, with em dashes against Address, Transport and Topic because this target is an endpoint that supplies none of them. Below it a line reads Sample: Synthetic sample reading, not a real firing, then the rendered payload sits in a grey box as a one-key JSON object. A Cancel button and an Approve button sit at the bottom of the dialog.
Where a target supplies no address, transport or topic, the dialog shows an em dash rather than guessing.
The dry run is the approval review. Approve is the primary button in the dry run dialog, not a separate control on the row. You approve the rendering you just read, and the system records which dry run you were looking at when you did. That record is the evidence behind the approval.

Test Send

Test send transmits one real payload to the real destination, right now, without waiting for an alert to fire.

This is the only way an Action sends outside a firing: everything else an Action does happens because its alert fired. The confirmation dialog names the target, and the topic where there is one, before anything leaves the platform.

Confirmation dialog with a warning icon, titled Send a real test payload? The body reads This sends one real payload to endpoint right now, outside any alert firing. A Cancel button and a Test send button sit side by side at the bottom.
The confirmation names the destination, and the topic where there is one, before anything leaves the platform.
Test send uses a new rendering. It sends one payload based on a synthetic alert event. If your template includes {{tag.…}} or {{device.…}}, those tokens use live values, which may include device readings. The sample time and live values can change between a dry run and a test send. Use the dry run to check the payload’s structure and destination, but do not expect the test send to contain identical bytes.
A test never changes the destination’s own state. A destination that rejects a test is not deactivated by it, and one that accepts a test is not thereby activated. Testing is safe to do against an integration you are still setting up.
It works while the trigger is switched off. A test send proves the destination, not the condition, so it is offered even when the alert behind the Action is disabled. That is on purpose: checking that your endpoint receives the payload before you switch the alert on is exactly when the check is worth most.

Test send is available from Enabled, Approved, off and Sending unapproved. It is refused from Not approved and Config changed, which ask you to approve or re-approve first, and from Retired, which can no longer send at all. The reason is shown beneath the button.

Sending under the legacy exemption: when you test a Sending unapproved Action, the confirmation warns you that nobody has approved that destination. The payload still goes out — the Action is already pushing on every firing — but you are told what you are relying on.

When a test send is refused

Two different refusals both mean “nothing was sent”, and they are not the same problem:

  • Your account’s push limit for this minute is used up. The account-wide push budget from your plan is exhausted. Other pushes across the account are competing for the same allowance.
  • Too many test sends in the last minute. This is the page’s own throttle, ten test sends per minute, and it is about your clicking rather than your plan. Dry runs have their own separate budget of ten per minute, so previewing does not spend your ability to test.

Last Outcome

What the push queue last recorded for this target, and the three different ways that can be blank.

Reading What it means
Accepted by the queue The delivery queue took the job. This is not a receipt from the destination — see the note below.
Failed The push was attempted and did not succeed.
Skipped — the target was not eligible The destination could not receive it, typically because the integration or endpoint was deleted or disabled. Recorded on every firing while that stays true.
Outcome unavailable The outcome store could not be read for this listing. The Action’s history still exists; this page just could not see it.
An em dash Several Actions share this target and differ only by topic, so a recorded outcome cannot be attributed to any one of them. Hover the cell for the explanation.
Empty Nothing has ever been pushed from this Action.
Accepted is not delivered. NEQTO.ai records that the queue accepted the job, and nothing beyond that. No provider receipt is stored anywhere, so an outcome reading Accepted by the queue does not prove the destination received the payload. To confirm that, check the receiving system.

The column shows whichever of the two is newer, a real firing or a test send, and a firing wins a tie. Each outcome is labelled with where it came from — From a real firing or From a test send — along with the time it happened, so a reassuring outcome from your own test is never mistaken for a successful production push. An outcome recorded before this labelling shipped carries no source and is treated as a real firing.

Actions and Data Push

Both send a payload to an endpoint. They differ in what starts the send.

An Action is event-driven: it sends because an alert fired, or because you pressed Test send. Data Push is on demand: you type a payload and send it yourself, from the Data Push screen or from a dashboard widget.

They share budgets, but not the same ones, and the difference matters when you are working out why something was refused:

  • The monthly payload push allowance is spent by every real firing, whether the target is an integration or a Device Endpoint, and by every Data Push you send yourself.
  • The per-minute push rate is shared with Data Push. On a real firing it is spent by Device Endpoint targets only; an integration target does not touch it, so a busy integration-only Action does not eat into what Data Push can send.
  • A test send always spends one point of the per-minute rate, whichever kind of target it goes to, and none of the monthly allowance.

Limits and Good to Know

Every number on this page, in one place.

Item Value
Push targets per alert 5
Test sends 10 per minute, per user
Dry runs 10 per minute, per user, budgeted separately from test sends
Monthly payload push allowance Your plan’s monthly allowance, spent by every real firing to either target kind
Per-minute push rate Your plan’s Data Push rate, account-wide. On a firing, spent by endpoint targets only; a test send always spends one, whichever kind of target it is
Rows per page 25
Retired Actions Not listed
  • Approving requires its own permission, so an administrator can let somebody edit alerts without letting them clear an approval.
  • A dry run resolves tag and device tokens to their real current values, so being able to preview a payload is a data-reading right, not just a formatting one.
  • If the list fails to refresh in the background, the rows stay on screen with a warning rather than disappearing, so an answer you were waiting for is not taken away.