Bubble.io Notifications: Email, In-App, and Push Explained
Notifications keep users connected to your app between sessions. Five notification types, the complete in-app notification data model and display pattern, and the email deliverability rules that determine whether your onboarding emails reach inboxes or spam folders.
How to Keep Users Informed Without Overwhelming Them
Notifications are how your app maintains a relationship with users between sessions. The right notification at the right moment brings a user back to take an important action. The wrong notification — too frequent, too generic, or irrelevant — drives them to your unsubscribe link. This guide covers every notification type available in Bubble, how to implement each one, and the principles that make notifications useful rather than annoying.
Email, In-App, and Push
| Type | Delivery | When to Use | Bubble Implementation |
|---|---|---|---|
| Transactional Email | User’s email inbox | After specific actions: signup, payment, status change, invitation | SendGrid/Postmark via API Connector; Bubble’s built-in email for simple cases |
| Marketing/Digest Email | User’s email inbox | Scheduled digests, feature announcements, re-engagement campaigns | SendGrid or Customer.io via API Connector; user preference managed in app |
| In-App Notification | Inside the application | Real-time alerts: task assigned, comment received, approval needed | Notification data type in Bubble; unread count in nav; notification panel |
| Web Push | Browser notification (outside app) | Urgent alerts when user is not in the app: payment failed, deadline today | OneSignal plugin for Bubble; requires user opt-in |
| SMS | Text message | High-urgency: booking confirmation, verification code, critical alert | Twilio API via API Connector |
The Data Model and Display Pattern
recipient
-> User
workspace
-> Workspace
type
-> option set (Task_Assigned, Comment, Payment_Failed…)
title
-> text (e.g. ‘James assigned you a task’)
body
-> text (brief description)
link_url
-> text (where to go when clicked)
is_read
-> yes/no (default: no)
created_at
-> date
Badge text
: Search for Notifications [
recipient = Current User,
is_read = no,
workspace = Current User’s current_workspace
]:count
Badge visible when
: above count > 0
A group that slides in from the right when the bell icon is clicked. Contains a Repeating Group of Notifications sorted by created_at descending, limited to 20 most recent. Each notification row shows the title, time since, and a read/unread indicator.
Step 1
: Update Notification: is_read = yes
Step 2
: Navigate to Notification’s link_url
// Mark all as read button
Step 1
: Search for Notifications [recipient=Current User, is_read=no]
Bulk update: is_read = yes
What Every Bubble Email Must Do
Send from a verified domain
Never send transactional email from a Gmail or free email address. Configure your domain in SendGrid with SPF, DKIM, and DMARC records. Emails from unverified domains hit spam folders. Spam-foldered onboarding emails are conversion killers.
Test deliverability before launch
Use mail-tester.com to score your email deliverability before going live. Aim for 9/10 or above. Anything below 7 means a significant portion of your onboarding emails are landing in spam.
Respect unsubscribe preferences
Every marketing email must have an unsubscribe link. Store email preferences on the User record: email_marketing_opt_in (yes/no). Check this before every non-transactional send. Sending marketing emails to opted-out users violates GDPR and CAN-SPAM.
Don’t send too many
Three onboarding emails in week one is fine. Three onboarding emails in day one is not. Map out every automated email your app sends and review the aggregate from the user’s perspective before launch. If it feels like too much, it is.
Build Your Bubble.io App With Expert Help
Pakistan’s leading Bubble.io development team. Multi-tenant SaaS architecture, Stripe billing, and full product builds done right from day one.
