In-app Notification Settings
Members choose which notifications reach their list and their phone, per notification type.
Before you start
Section titled “Before you start”| Plugin | None — Memberside raises these itself |
| Endpoint group | Notifications |
| Plan | Every plan |
What this is
Section titled “What this is”The In-app Notification tab from Settings, placed as a screen of its own so you can put it on a navigation bar, in a sidebar, or behind a button.
It is the same screen, not a copy. Placing it does not remove the tab from Settings, and a member who changes a switch in one place sees it changed in the other.
Choosing which notifications reach the app and the phone
record → src/assets/media/app-notification-settings.mp4
What a member sees
Section titled “What a member sees”One section per plugin, one row per notification type, and two switches on each row: In-app and Push.
Switching In-app off switches the whole notification off for that member. There is nothing left for the push to point at, so none is sent — which is worth knowing before you read a support message about it.
Email is the Email Notification Settings screen. The two are separate because the questions are different in kind: an inbox is not a lock screen.
It covers every plugin, and respects the ones with their own
Section titled “It covers every plugin, and respects the ones with their own”The list is not Ultimate Member’s, or any one plugin’s. Every notification your site can raise appears here, grouped by the plugin that raises it — forum replies, friend requests, group activity, reviews, job outcomes, purchases. Install another integration and its notifications appear in this list without you doing anything.
Two plugins ship notification settings of their own, and neither is overruled:
- BuddyPress has its own email settings screen. A member who answered “No, do not send email” there stays opted out for any event you hand over, so moving one across never starts emailing somebody who already said no. See Notifications.
- Ultimate Member - Real-time Notifications keeps its own preferences until a type is moved across, and a member who opted out there stays opted out.
Where a plugin still owns an event, this screen leaves it alone. Handing events over is a decision you make one at a time in Memberside → Notifications, and this screen follows it rather than forcing it.
Push needs more than a switch
Section titled “Push needs more than a switch”A switch here is a member saying yes. It is not enough on its own:
- The app must be built with Push configured, or there is nothing to deliver with.
- The member must have allowed notifications at the OS level. A member who declined sees these switches do nothing, and re-enables it in their phone’s own settings.
In-app works regardless — it is the list inside your app, and needs no permission.
When it does not work
Section titled “When it does not work”| Symptom | Cause | Fix |
|---|---|---|
| The screen is empty | The Notifications endpoint group is off | Placing this feature switches it on — save the app again in the builder |
| Push switches do nothing | Push is not configured, or the member declined the OS permission | Push; the member re-enables it in their phone’s settings |
| Turning off In-app stopped push too | That is what In-app off means | Expected — the notification itself is off |
| A switch is greyed out | You locked that channel | Turn the lock off if that was not intended |