Notifications

Configure and manage push notifications for smarttable submissions and approvals.

How Notifications Work

  1. A user submits an entry
  2. Notifications are sent to configured recipients (via Firebase Cloud Messaging)
  3. Recipients see a push notification and an in-app notification
  4. If action buttons are configured, recipients can approve/reject directly from the notification

Delivery Mechanics

Push delivery is registered per device, per user — installing PersivApps on a phone and also using it in a desktop browser registers two separate device tokens against the same account, and both receive the notification. Actual delivery to Firebase happens on a background thread, not inline in the request that triggered the notification — so a slow or temporarily unreachable Firebase endpoint never adds latency to the save/submit/approval action that caused the notification in the first place. If push delivery fails for any reason, the in-app notification (bell icon) is unaffected — they're delivered independently, not one derived from the other.

Notification Settings

Configure in SmartTable Settings → Notifications section:

Notification Settings
SettingDescription
Users to notify on Submit Select users who receive a notification whenever an entry is submitted. These are in addition to the shift incharge selected during entry.
Enable comments in notifications When enabled, notification action buttons include a comment field for the recipient to add notes.
Notification Action Buttons Configure buttons that appear on notifications (e.g., Approve/Reject). System Admin

Configuring Action Buttons

Each button has three properties:

PropertyDescriptionExample
Label Text displayed on the button Approve, Reject, Review
Value Internal value sent to the API when clicked approve, reject, review
Color Button color theme Blue, Green, Red, Yellow, Gray
💡 Common Setup A typical approval workflow uses two buttons: "Approve" (green, value: approve) and "Reject" (red, value: reject).

When a recipient taps an action button with a comment field enabled, a signature can also be attached to that action — drawn on the spot or uploaded — and is stored the same way regardless of whether it arrived as a base64 string or a real uploaded file, so every place that later displays that signature (approval history, the entry's own record) reads it identically no matter which path the recipient's device used.

Deleting the underlying thing a notification is about — e.g. editing an approval step's list of approvers — automatically clears out any notifications tied to the old configuration that were never actioned, rather than leaving a stale "Approve/Reject" prompt sitting in someone's inbox for a decision that no longer applies.

Notification History

View all notifications sent for a specific entry:

  1. Click the ⋮ (more actions) icon on an entry row
  2. Select Notification History

A red dot on the ⋮ icon indicates pending (unactioned) notifications for that entry.

In-App Notification Panel

The notification bell icon in the app header shows:

  • Unread notification count badge
  • List of recent notifications with read/unread status
  • Action buttons (if configured) for quick approve/reject
  • Auto-polls for new notifications every 30 seconds