Run a job board, a course site, an events calendar and a badge system on the same community and you get four places that want to tell your members something. A new application, a lesson reminder, a waitlist spot, a badge: each plugin has its own idea of where that message should go. Members do not check four inboxes, so it is easy for those messages to go unread.
BuddyNext’s answer is one inbox. The plugins keep doing their own work, and the alerts that matter to a member land in the same notification bell as everything else. This post covers how that works, what reaches the bell, and the controls members and owners get.
How it works
Each plugin already fires its own notification event when something happens. Under the shared notification contract, it passes one standard bundle of information along with that event: who the notification is for, what kind it is, the message and a link. BuddyNext reads that bundle and creates a row in the bell, using the plugin’s own words, link and icon.
Two things stay with the plugin. It keeps sending its own emails, and it keeps writing its own messages. BuddyNext does not email these notifications, so a member does not get two emails for one event. They may still get an email from the plugin and a bell row from BuddyNext, which is the point: the bell is where they look, the email is the nudge.
The receiving side is in the free BuddyNext plugin. For a given plugin to appear, it needs to be a release that has adopted the contract, so keep both sides up to date.
What reaches the bell
Each plugin gets its own section in the bell and in the settings.
- Jobs, from Career Board. Applications received, status changes, withdrawals, deadline reminders, job approvals, expiries and rejections.
- Courses, from Learnomy. Learning, community, payment and instructor notifications.
- Events, from Eventonomy. Registrations, waitlist changes, reminders, event changes and cancellations, and refunds.
- Achievements, from WB Gamification. Badges, level-ups, kudos, challenges, rewards and expired credentials.
A few examples make the range clear. A recruiter sees “New application received” and an applicant sees “Application status updated”. An attendee hears when a spot opens up on a waitlist, or when the date, time or venue of an event they registered for changes. An organizer sees when a moderator approves their event or asks for changes, and attendees can receive messages from organizers about events they registered for.
Because the rows join the same list as BuddyNext’s own notifications, there is one place to check and one place to clear. A member does not have to learn that jobs live in one inbox and courses in another.
What members can control
Every notification type has its own switch on the member’s notification settings, grouped under the plugin’s name. A recruiter can keep “New application received” and switch off “Saved job deadline approaching”. An attendee can keep reminders and mute “Marked as maybe”. Defaults are set by each plugin, and they are on unless the plugin says otherwise.
None of these switches offers email. That is deliberate: the plugin owns its email, and BuddyNext only governs the bell.
Every type in detail
The list above is a summary. Here is what each plugin declares, so you know exactly which switches members will see.
Career Board declares eight types: a new application received, an application status update, a candidate withdrawing, a saved job’s deadline approaching, a job approved, a job rejected, a job listing expiring soon and a job listing that has expired.
Eventonomy declares thirteen: registration confirmed, registration cancelled, added to the waitlist, marked as maybe, off the waitlist, event reminders, event details changed, event cancelled, your event approved, your event needs changes, messages from organizers, a free ticket received, and an order refunded or cancelled.
WB Gamification declares six: badges earned, level-ups, kudos, challenges completed, rewards ready and expired credentials.
Learnomy builds its list from its own email groups, covering learning, community, payment and instructor notifications, so a switch in the bell matches a type you already know from its emails.
Each of these is a separate switch. That is the real control a member has: not “notifications on or off”, but exactly which of those they want.
There is also a benefit for you as the owner. Because each plugin declares its own types, a new type appears in the settings by itself when a plugin adds one, and you never maintain a list of what exists. Defaults are the plugin’s choice, so look at the settings page once as if you were a new member before you announce the bell.
Rules that keep the bell trustworthy
A notification centre is only useful if it does not lie. A few rules are built in:
- No self-notifications. If the person who caused an event is the one who would be told, the row is dropped.
- Blocks are respected. If either member has blocked the other, no row is created.
- The owner’s switch wins. If you switch an integration’s navigation off in BuddyNext’s integration settings, its notifications stop reaching the bell.
- Rows disappear with their subject. When the plugin permanently deletes the thing a notification is about, the bell rows about it are removed.
- Rows can be hidden after the fact. BuddyNext asks the plugin whether the member may still see each row. In Learnomy’s case, a course notification is shown only while the member can read the course and is enrolled, so it vanishes if their enrollment is revoked or the course is trashed.
Similar events can also be grouped into one row, and when a plugin hides some of the events in a group, the names and the count follow the ones that remain.
When a notification is missing
If a member says they did not get a notification, work down this list.
- Is the plugin on a recent release? A plugin only sends through the shared contract once it has adopted it.
- Is the integration’s switch on? If you turned its navigation off in BuddyNext’s integration settings, its rows stop.
- Did the member switch that type off? Check their notification settings under the plugin’s section.
- Did they cause the event themselves? Self-notifications are dropped by design.
- Is there a block between the two members? Either direction suppresses the row.
- Can they still see the thing? A course row, for example, disappears if their enrollment was revoked or the course was trashed.
Each item on that list is a deliberate rule, not a fault, which makes the problem quick to find.
What is not in the bell
Not every plugin sends to it. Listora keeps its own notification centre and does not send to the bell, so a member of a Listora directory still sees those alerts in Listora’s own places. Anything a plugin sends only by email stays email: Learnomy Pro’s space notifications, for instance, go out by email alone.
If you want the full picture for a site, check each plugin you run against the table above and tell your members which alerts live where.
Setting it up and testing
There is little to configure, which is the point, but a short check saves surprises.
- Update BuddyNext and each plugin you run to a current release, because a plugin only appears once it has adopted the contract.
- In BuddyNext’s integration settings, confirm the integrations you want are switched on.
- Open the member notification settings as a test member and look for one section per plugin, each with its own switches.
- Trigger a real event for each plugin you run. Register for an event, apply for a job, earn a badge. Check that a row appears with the right wording and that its link goes to the right place.
- Look at your plugins’ own email settings. Because the plugin still sends its own email, a member can receive both an email and a bell row for one event, so decide whether that suits you.
A worked example
Picture an attendee on a site that runs all four plugins. They register for a workshop, and the bell shows “Registration confirmed” in the Events section. A week later the organizer changes the venue, and a second row says the details changed. That evening they earn a badge, and the Achievements section gets a row as well. Everything sits in one list with the plugin’s own icon, so the member scans one place instead of looking in each plugin.
For developers
The contract is open. Another plugin can join by adding itself to the list of notification sources, declaring its notification types so they appear in the settings, and firing its own hook with the standard bundle. It can also answer the visibility question for its own rows and tell BuddyNext when an object is deleted. That is the same path the plugins above use, so a custom integration gets the same section, switches and cleanup.
Where to go next
If you want the other two views of the same integration, one community feed for jobs, events, courses and listings shows what the plugins post into the feed, and member profiles that show jobs, courses and events shows what appears on a profile. The integration pages go through each plugin: Career Board, Learnomy and Eventonomy. The pricing page shows what BuddyNext Pro adds.