All outbound messages in xMatix — whatever sends them and whatever carries them — travel one pipeline: content is rendered once, a durable outbox row is written per channel and recipient, a delivery worker sends and retries, and every row's fate is visible in the message log. This page is the administrator's reference for the channels, the statuses, the protections, and the log.
The channels
| Channel | Carrier | Recipient addressing |
|---|---|---|
| Your organization's email sending service | Email address | |
| In-app | Delivered inside xMatix itself | User |
| Push | Mobile push notifications to the xMatix app | User |
| SMS | Your organization's messaging provider | Phone number |
| Connector-backed | Any service reachable through a configured connector | Provider-specific target |
Messages come from the platform's own senders — business rules, workflows, automation scripts, and report or dashboard subscriptions — with content supplied inline or rendered from your organization's templates. Attachments (report subscriptions, typically) are supported on the email channel only, and attachment sends are still recorded in the log.
Channel configuration
Channels that need provider credentials — SMS and connector-backed ones — are configured per organization under Setup → Feature Hub → Service → Messaging Channels. Each configuration carries:
| Field | Meaning |
|---|---|
| Label / name | How the channel appears; the name is its stable key |
| Channel | Which channel kind this configures |
| Provider | The provider integration that carries it |
| From | Sender number or address |
| Secret name | The logical name of the provider credential — the secret value itself is held in the platform's secure secret store and is never stored or displayed in the configuration |
| Settings | Provider-specific settings, including optional per-channel rate limits and quiet hours |
| Enabled | Disabled channels are skipped with a diagnostic rather than erroring |
Every configuration row has a Test send action that queues a real message to an address you supply and shows the submission diagnostics — the two-minute proof that credentials and sender identity work before a rule depends on them.
Delivery statuses
Each outbox row moves through explicit states, all filterable in the log:
| Status | Meaning |
|---|---|
| Queued | Written and waiting for the delivery worker (possibly deferred by rate limits or quiet hours) |
| Sending | A delivery attempt is in flight |
| Sent | Handed to the provider |
| Delivered | The provider confirmed delivery — on channels that report receipts, a provider callback upgrades Sent to Delivered |
| Failed | Attempts exhausted or the provider reported failure; the row keeps its last error text |
| Skipped | Not attempted — for example, the recipient could not be resolved |
| Held | Quarantined by the flood guard, awaiting an administrator's review |
Rows stuck mid-flight (a crashed worker, a lost enqueue) are found by a recovery sweep and re-driven automatically after a grace period — delivery is at-least-once with idempotent re-drives, not fire-and-forget.
Protections
The pipeline assumes that one day a rule will misfire in a loop, and is built to make that day boring:
- Tenant-wide circuit breaker — past an hourly send cap for the whole organization, every new message is Held rather than sent, and administrators are alerted with instructions to review the log, fix the source, and release.
- Per-recipient caps — hourly and daily limits per recipient and channel hold further sends to one inbox even when the organization-wide breaker hasn't tripped.
- Rate limits and quiet hours — per-channel settings defer a message's first attempt to the allowed window instead of dropping it.
- Opt-outs — user preferences are enforced at submit time for the user-addressed channels (in-app and push); opted-out recipients are skipped and counted in diagnostics.
Held is a quarantine, not a failure: held rows sit out of the send window (so they cannot re-trip the guard) until released.
The message log
Setup → Platform Operations → Monitoring → Message Log lists every outbound message across all channels — created time, channel, status, recipient, subject, attempt count, category and the last error — filterable by channel, status, recipient and date range. Two operations live here: Resend re-queues a failed row, and Release (per row, or Release held for everything at once) returns quarantined rows to the queue. Viewing the log is its own permission, so operations staff can watch delivery without holding wider setup rights.
Common questions
Why is a message Held, and what should I do?
The flood guard held it — either the organization crossed its hourly send cap or that recipient hit a per-recipient limit. Before releasing, find what generated the volume (the category and source columns point at the origin) and fix it; releasing without fixing re-runs the flood with your fingerprints on it. Then filter the log to status Held and release.
Why does a message sit at Sent and never reach Delivered?
Delivered requires a provider receipt, and not every channel reports one. Absence of Delivered on such channels is normal and does not mean the message failed — failure is explicit, with status Failed and an error. Judge each channel by the statuses it can actually reach.
Where do templates fit?
A message request can name a template instead of carrying inline content; the pipeline renders it once at submit time — with the record model the sender supplied — and every channel and recipient of that submission shares the rendered result. Senders that support templates (business rules, workflows) let you pick the template where you author the rule.
Related topics
- Business rules
- Workflows
- Activities
- Telephony & Messaging — product overview