TechAppForce

Notifications

Email, SMS, webhook and in-app notifications from events, approvals and workflows.

  • Channels: email through SMTP or Brevo, SMS through Twilio, webhooks with retries, and in-app notifications over a WebSocket.
  • Templates use Liquid, with the record's data and the results of saved queries.
  • Recipients can be addresses, the record's creator, everyone in a role, or users from a query, with To, Cc and Bcc and a personalised message per recipient.
  • Preferences: each user can opt in or out of each channel.
  • History: every delivery is logged, with status and history APIs.
Coming soon

Push notification delivery and automatic resending of failed email and SMS are coming soon.

How a notification works

An event fires. The platform resolves who should hear about it, renders what it says from a template filled with the record's data, sends it on the configured channels, and tracks each delivery. For example: an expense claim reaches its approver, who gets an email and an in-app notification reading “Priya submitted a 4,200 expense for your approval”, with a link to the request.

Channels

ChannelUse it for
EmailRendered messages, optionally with attachments such as a report.
In-appA notice in the user’s bell inside the app, delivered live.
SMSShort, urgent messages to a phone number.
PushAlerts to a user’s device. Coming soon: push delivery is not available yet.
WebhookAn HTTP callback to another system.
Multi-channelThe same notification on several channels at once.

The providers that deliver email, SMS and push are configured per app by an administrator (in TAF Studio, TAF: Notification Providers). Your notifications do not change when a provider does.

What sends it

  • Record events. Attach the notification to a trigger (created, edited or deleted, with criteria) and it is sent directly when a save matches. No workflow is needed.
  • Schedules. A trigger with a schedule sends on the clock, for reminders and digests.
  • Lifecycle transitions. A workflow in a transition's After phase sends the notification when a record changes status.
  • Workflow steps. The email, SMS, push, in-app, webhook, multi-channel and configured-notification actions send from any workflow.
  • Approvals and reports. Approval steps reach approvers through their inbox, and a sent or scheduled report is delivered through a notification.
  • Mentions. Mentioning someone in a record's comments notifies them, with no configuration.
Important

Attach a notification either to the trigger itself or to a workflow on that trigger, not both, or recipients receive two copies.

Recipients

Recipients are resolved when the notification is sent, never hard-coded to a person, so they stay correct as people change roles. A recipient source can be fixed email addresses, the creator of the record, or the people a DSQ returns: the query's user fields give the recipients, which covers owners, managers, watchers and approvers.

Recipient sources
[
  { "type": "createdby" },
  { "type": "email", "emails": ["finance-team@example.com"] },
  { "type": "query", "queryId": "<DSQ id>", "fields": ["ApproverId"] }
]

Each recipient's email address and phone number come from their user account. A person listed by more than one source gets one notification.

Important

In a recipient DSQ, mark the parameter that picks the record as mandatory. An optional parameter that arrives empty drops its filter, and the notification would go to every user the query can return. Recipient fields must be user fields on the query's own entity.

Content and templates

A notification's subject and body come from a template: HTML or text with placeholders the platform fills in for each record. In-app notifications can carry action buttons. Keep shared layouts, such as an order confirmation, as reusable templates so they are maintained in one place.

Template body
Hello {{FirstName}},
Your order {{OrderNo}} has been updated. Status: {{Status}}

Placeholder values come from the DSQs attached to the notification. For a notification sent after a lifecycle transition, put the names and details the message needs into a DSQ filtered on the moved record, rather than relying on values passed with the event.

Create a notification

  1. Make sure the trigger exists (see Workflows and jobs), or decide which workflow step will send it.
  2. In TAF Studio, run TAF: New Notification. Set when it is sent (the trigger), who gets it (the recipient sources) and what it says (subject, body and the DSQs that fill the placeholders).
  3. Choose the channels: email, in-app, SMS or several.
  4. Publish it, then make a matching change as a test user and check the recipient's bell or inbox.

Delivery and the in-app bell

  • Each send is recorded with its delivery attempts and status, from created to delivered or failed. Webhook deliveries are retried with back-off; automatic resending of failed email and SMS is coming soon.
  • One failed notification never blocks others sent for the same event.
  • In-app notifications are pushed live to users who are signed in. The bell shows an unread count and history, and users can mark notifications read or clear them.
  • A user's bell shows only their own in-app notifications in the current app, so test by signing in as the recipient.