Activity Notifications
Per-Application email subscriptions that turn runtime activity into operator alerts. Pick what to watch (every event, or only errors, or only specific Message types), pick how to be told (one email per match, or a digest on a fixed interval), pick who hears about it — and Art2link ESB takes it from there.
An Activity Notification is an email subscription that lives inside an Application. The Application is the scope: a notification only sees activity that runs inside it, and a notification defined in one Application is invisible to every other. Within that scope, the notification answers four questions — what activity to react to, when to deliver, what to include, and who to tell — and the runtime does the rest.
Where Tracking is the historical record you go to when you have a question, and Monitoring is the dashboard you keep an eye on, Activity Notifications are the push: the platform reaches out to the operator without them having to look.
A single form defines the whole notification. The two columns of the form mirror the two halves of the configuration: the left column is the delivery contract (name, mode, interval, payload), the right column is the subscription (which Application, which Message types, errors only or all, timezone). Recipients live at the bottom; the Enabled flag controls whether any of it runs.
| Field | Required | What it does |
|---|---|---|
| Name | Yes | Free-form label. Appears in the Activity Notifications list and in the email subject; useful to make it specific (e.g. Orders — errors only). |
| Application | Yes | The parent Application. Pre-filled when an Application is selected; locked once saved — a notification cannot be moved between Applications. |
| On Error Only | No | When on, the notification reacts only to failed runs. When off, every matching event qualifies. See Subscription model. |
| Mode | Yes | Either Batched (one digest email per interval) or On Event (one email per matched event). See Delivery mode. |
| Schedule Every (seconds) | Yes, when Batched | The size of the batching window. Only shown when Mode is Batched. Hidden and ignored for On Event. |
| Subscription | Yes | Either All (every Message type in the Application qualifies) or Specific Type (only the types you select). See Subscription model. |
| Message Types | Yes, when Specific Type | The Message types this notification subscribes to. Only shown when Subscription is Specific Type. |
| Include Body | No | When on, the email carries the message body for each matched event. Off by default. |
| Include Properties | No | When on, the email carries the message properties (the Variables attached to the run) for each matched event. Off by default. |
| Notification Timezone | No | Timezone applied to every timestamp rendered in the email. Defaults to the tenant timezone if left blank. |
| Recipients | Yes (at least one) | One or more Name + Email rows. Each row is an addressee on every email this notification sends. Add or remove rows with the + control. |
| Is Enabled | Yes | Master switch. Disabling stops delivery without losing the configuration; the notification can be re-enabled later as-is. |
Two independent filters decide whether a given runtime event qualifies for the notification:
| Filter | What it asks |
|---|---|
| Subscription | Which Message types qualify — every type in the Application (All) or only the types you list (Specific Type). |
| On Error Only | Which outcomes qualify — only failed runs (on) or every outcome including successes (off). |
Both filters apply at the same time. The four combinations give you the full reach of the feature:
Mode controls the rhythm of delivery, not what qualifies. Same subscription, two different rhythms:
| Mode | Rhythm | Best for |
|---|---|---|
| Batched | One email per Schedule Every (seconds) window, listing every event that matched during the window. Empty windows send nothing. | Steady or bursty traffic; ops summaries; anything where a per-event email would be noise. |
| On Event | One email per matched event, sent as soon after the event as the platform can dispatch it. | Rare, high-importance events — especially On Error Only on a narrow Subscription where each match is something a human needs to read now. |
Every email shares the same shape. The body of the message is the Event Summary: a small table with one row per matched event, three columns — Tracking ID, Event timestamp, and (for errors) the error message. The Art2link ESB header and the notification footer sit above and below it. Per-event payloads ride along as attachments, not inline content, so the table itself stays short whether the digest covers one event or several.
Three form knobs decide how much each event row carries and what rides along as attachments:
| Knob | Effect on the email | Trade-off |
|---|---|---|
| Include Body | Adds a Body_<TrackingID>.json attachment carrying the message body for each matched event. | Bodies vary wildly in size; one big payload per event in a Batched digest can produce a heavy email. Leave off for high-volume subscriptions. |
| Include Properties | Adds the message properties (the Variables attached to the run) alongside the body attachment for each event. | Small per event; usually safe to keep on. Useful for at-a-glance correlation without opening the body. |
| Notification Timezone | Sets the zone applied to every timestamp in the Event column (e.g. ET in the sample above). | Pick the operator’s zone, not the server’s. Leaving it blank falls back to the tenant default. |
Failed events automatically carry an Error_<TrackingID>.txt attachment with the full error text — this happens whenever an event lands in the email with an error, independent of the Include knobs. The ERROR column in the table is the short message; the attachment is the full stack and context.
Recipients are the same Name + Email rows you defined on the form; every row is To: on every email this notification sends. To split recipients into different lists, create separate notifications with the same Subscription and different Recipients.
In Batched mode the Event Summary table grows by one row per matched event in the window, and the attachments grow with them — one Body and (where applicable) one Error file per event. In On Event mode the table is always a single row and you get exactly two attachments at most. The header, divider, and footer stay the same in both modes.
Is Enabled is the master switch. Disabling a notification stops delivery immediately and clears any pending Batched window without emitting it. The configuration is preserved — recipients, subscription, mode, all of it — and re-enabling resumes from the next window or the next event with no further edits required.
Every other field on the form can be edited after the notification is saved. The exception is Application: a notification is bound to its Application at creation time and cannot be moved — if the audience belongs to a different Application, re-create the notification there.
Activity Notifications are themselves auditable: creates, edits, enables and disables all land in Logs under the audit stream. The Activity Notifications list itself shows last-fired time, recipient count, and current state at a glance, so a quiet notification is easy to tell apart from a misconfigured one.
That’s Activity Notifications
Per-Application email subscriptions: pick what to react to, how often to send, how much to include, and who hears about it. Tracking and Monitoring are where you go to look; Activity Notifications are how the platform comes to you.