Skip to content
Journeybee Help Center home
InboxAsk a human

Notifications

Notifications are how your team and your partners find out that something happened: a lead arrived, a deal moved stage, someone was mentioned in a note. Journeybee ships with twelve built-in notifications, and you can build your own rules on top.

Every rule answers four questions: what happened, does it qualify, who hears about it, and how they hear about it.

Where to find it: Go to Settings, then Notifications.

Who can use this: Admins and Partnerships team members.


The two lists

The page is split in two.

  • Built-in: the twelve notifications Journeybee provides. You can turn them on or off and adjust who they reach, but you cannot delete them.

  • Your notifications: rules you have created yourself. These are fully editable and deletable.

Each row shows the notification's name, delivery channels and status.


Built-in notifications

All twelve are switched on when your workspace is created:

  • New lead: a new lead is created. Email, both sides.

  • Lead status update: a lead's status changes. Email, both sides.

  • Lead assigned to you: someone is assigned to a lead. In-app and email.

  • Project assigned to you: someone is assigned to a project. In-app and email.

  • Task assigned to you: someone is assigned to a task. In-app and email.

  • Deal stage changed: a deal moves stage, notifying that deal's assignees on both sides. In-app and email.

  • New deal registered: a partner registers a new deal, notifying that deal's assignees on both sides. In-app and email.

  • Deal expired: a deal expires. Email to the partner.

  • You were mentioned: someone mentions you in a note, comment or message. In-app and email, both sides.

  • Lead needs review: a new lead was held because Salesforce has an open opportunity for it, or the check could not run. Reaches the lead's assigned users and partner managers, your team only. In-app and email. Only used when Auto-approve leads with no open Salesforce opportunity is turned on in the Salesforce Integration.

  • Partner invitation: the invitation email a new partner receives.

  • User invitation: the invitation email a new portal user receives.

What you can change on a built-in

Click a built-in notification to open its settings panel:

  • Enabled: turn the whole notification on or off for your company.

  • Notify: your team, partners, or both.

  • Channels: which channels are used. Partners always receive email; in-app reaches your team only.

  • Disabled for partnerships: search for specific partners and switch this notification off for them alone. Everyone else still receives it.

The two invitation notifications are transactional. Their audience and channels are fixed, because they carry a portal sign-in link and can only go to the partner by email. You can still disable them per partnership.

The per-partnership switch is the useful one in practice: a partner who has asked for less email can be quietened without changing anything for the rest of your network.


Create your own notification

Click New notification. The builder has two steps.

Step 1: Name and events

Give the rule a name, then tick the events that should fire it. Events are grouped by record type, and a rule can watch several at once. Available events:

  • Lead: created, updated (any field), deleted, status changed, assigned, unassigned.

  • Deal: created, updated, deleted, stage changed, value changed, expired.

  • Partner: created, updated, deleted, stage changed, tier changed, category changed, assigned, unassigned.

  • Collaboration card: created, updated, deleted, stage changed, assigned, unassigned.

  • Task: created, updated, deleted, status changed, assigned, unassigned.

  • Note: added, updated, deleted, mentioned.

  • Card comment: mentioned.

  • Message: sent, edited, mentioned.

  • Resource access: granted, revoked.

  • Certification access: granted, revoked.

  • Certification: created, updated, deleted.

  • Payment: created, processing, completed.

  • Room: room goal completed, all room goals completed, room form submitted. The goal events fire when a partner ticks off goals in a Goals block in a portal room — one notification is sent per save even if several goals were ticked at once. Room form submitted fires when a partner submits a Form block. The variables include {{room_name}}, {{block_title}}, {{goal_titles}}, {{completed_count}}, {{total_count}}, {{form_title}} and {{submission_summary}}, alongside the partner variables.

Picking an event prefills a sensible title and body for you, which you can then edit.

To alert your team on every form submission without building a rule, use the Notify on submission setting on the Form block itself — see Custom Portal Rooms.

Step 2: Everything else

Step two is a set of collapsible sections.


Conditions

Conditions narrow when the rule fires. With none, it fires on every matching event.

Build filters against the record's fields, your partner taxonomy (type, tier, category, stage) and your custom fields. Operators cover equals, does not equal, greater than, less than, is one of, is not one of, contains, is empty and is not empty.

All conditions must be met. They combine with AND, not OR. If you need either of two situations to fire the rule, build two rules.

Setting a Partner type also filters the tiers, categories, stages and custom fields offered in the condition rows to that type, which makes the picker far easier to use.


Recipients

Two settings decide who hears about it.

Which side gets notified?

  • Your team

  • Partners

  • Your team and partners

Recipients

  • Assigned or tagged users: the people assigned to the record.

  • The person who created the record.

One rule you cannot work around: partners are notified by email only. In-app notifications and Slack delivery reach your own team. Selecting Partners as the audience greys out the other channels.


Delivery

Tick one or more channels.

  • In-app notification: the bell in Journeybee. Your team only.

  • Email: works for both sides.

  • Slack channel: posts into a Slack channel. Your team only.

Slack delivery

Slack delivery needs the Slack integration connected. Once it is, choose a channel from the list and use Send test to confirm it works before saving.

For a private channel, invite the Journeybee app to the channel in Slack first, then send the test. If a delivery fails later, the rule shows the error and you can re-select the channel or reconnect Slack and test again.


Message

Write the Title and Body the recipient sees. Both accept {{variable}} placeholders, and the builder gives you an Insert row of the variables available for the events you selected. Typical ones are {{first_name}}, {{lead_name}}, {{company_name}}, {{partner_name}}, {{stage_name}} and {{deal_value}}.

Email settings

An optional section that only affects the email version:

  • Header and Footer: extra text around the message. Both accept variables.

  • Button label and Button links to: the call to action. Pick the object type (lead, deal, partner, card or task) and Journeybee generates the correct link at send time, pointing your team at the app and partners at the portal.

  • Show branding: your company logo and brand colour on the email. On by default.

Do not try to hand-write the button URL. Because the same rule can notify both sides, the destination differs per recipient, and only the generated link gets that right.


Preview and test

Preview renders the email as the recipient will see it, with your branding and variables filled in from sample data.

Test dry-runs the rule: it evaluates your conditions and renders your templates against sample data and tells you whether the rule would have fired. Nothing is sent to anybody.

Use the test before you activate a rule with conditions on it. "Conditions did not match" at this point is far cheaper than silence for a fortnight.


Troubleshooting

A notification is not arriving

Check in this order: the rule is Active; the partner is not on its Disabled for partnerships list; the audience includes the side you expect; the channel is ticked; and the conditions actually match. Run test answers the last one directly.

Partners are not getting in-app notifications

By design. Partners receive email only. In-app and Slack are for your own team.

The rule fires too often

An updated (any field) event fires on every edit to that record. Use a narrower event such as status changed or stage changed, or add conditions.

Slack delivery failed

The rule shows the last error. For a private channel, the Journeybee app has to be invited to it in Slack. Re-select the channel or reconnect Slack, then send a test.

One partner is getting too much email

Open the notification and add them under Disabled for partnerships. That switches it off for them only.

I need "either this or that" logic

Conditions on a rule all have to be met. Build two rules instead.


Good to know

  • Built-in notifications can be switched off but never deleted, so you can always turn one back on.

  • Partner notifications only reach live partnerships. An offline partner receives nothing.

  • The email button link is generated per recipient, so the same rule sends your team into the app and partners into the portal.

  • A mention email links straight to where it happened: a note opens its lead, deal or partner, and a message opens the conversation itself. Partner links open their portal.

  • Set your notification rules before you invite real partners. A partner who submits a lead and hears nothing assumes it never arrived.

  • Submitting a deal together with a new lead in the partner portal sends one email — the new-deal one — rather than one for each record.

  • A bulk CRM import sends no notifications: imported partners, contacts, leads and deals simply appear. They can still trigger workflows and CRM sync as usual.

  • Updating a partner's per-partner settings (deal expiration, the partner-edit permissions, the visibility limit or auto-create users) sends no partner-updated notification.