Notification groups
A notification group is a named, reusable list of recipients. Rules reference groups by name rather than by individual addresses, so you manage who gets alerted in one place instead of rebuilding contact lists in every rule. This page covers what is specific to running groups as a partner: scope, tier limits, deliverability, and how the feature looks to your customers.
Where to find it: Sidebar -> Administration -> Notification Groups.
The day-to-day how-to (create a group, add email and SMS members, the Disabled state, delete rules, using a group in a workflow) is documented once, in the end-user guide, and applies to you exactly as written: Notification groups (end-user guide). This page does not repeat it.
How groups fit together
When a rule's Send email or Send SMS action fires, ioX-Pulse looks up every active member of the groups that action references and queues a message to each one. Because the rule points at the group and not at individual people, you can:
- Add or remove a recipient once and have every rule that uses the group pick up the change.
- Reuse the same group across many rules (one "Maintenance Team" group, twenty rules).
- Keep recipient management separate from rule authoring, so a Sub-account Admin can adjust who gets paged without touching the workflow graph.
Members of a notification group are people (email and SMS recipients), not devices. If you are looking to fan a downlink out to a set of devices, see Multi-casting (Beta) instead.
Scope: partner-level vs sub-account
A group is created at one of two scopes:
| Scope | Who can use it | Who sees it |
|---|---|---|
| Partner-level | Workflows you author at partner level (partner-wide, profile, and device workflows you own). | Partner Admins only. Never surfaced to sub-account users. |
| Sub-account | Workflows owned by that sub-account, whether built by their own admin or by you while acting as that account. | That sub-account, plus Partner Admins looking across the workspace. |
A Partner Admin sees partner-level groups and every sub-account's groups. A Sub-account Admin sees and manages only their own sub-account's groups, and the workflow builder's group picker follows the same rule: when you (or a customer admin) build a workflow inside a sub-account, the picker offers that sub-account's groups only. The scope is decided when you create the group, based on where you are in the workspace at the time.
The Account user picker in the member drawer respects the same boundary: a partner-level group offers only partner-level users, and a sub-account group offers only that sub-account's users, so a partner group never pulls in sub-account users and one sub-account never sees another's. On the partner-level list, an extra Scope column shows which account each group belongs to.
How it looks for your customers
Sub-account Admins get the same Administration -> Notification Groups page and the same drawer, limited to their own account. They create their own groups, add their own colleagues and outside addresses (SMS members too, if their tier includes allowSmsNotifications), and pick those groups in the workflow builder without involving you. Their guide for this is the end-user page linked above; if you write your own customer-facing help, link to it rather than to this page, which uses partner terminology.
Two things about the customer view are worth knowing when you support them:
- Workflows you manage on their behalf use your partner-level groups. Customers can see those workflows and mute them, but they can't see or edit the recipient list, so "add me to the leak alert" requests for a partner-managed workflow land with you.
- Suspending a member from a sub-account's Members list scrubs that member's email from the sub-account's groups; suspending them at partner level scrubs across every workspace. Reinstating does not restore group memberships, and the customer guide says so.
Per-tier limits
The number of notification groups a scope can create is set by the notificationGroups.maxPerScope tier key. Check Settings -> Plan for your current limit. If a scope hits its cap, the Create group button shows "Limit reached" with the number; delete unused groups, or contact your account manager about an upgrade. SMS members additionally require the allowSmsNotifications tier feature; without it the channel selector is email-only for that scope. See SMS credits for how texts are paid for.
Frequently asked
A group member says they are not receiving alerts. Where do I look?
Start with the checklist in the end-user page: Disabled state (an SMS STOP), the recipient's own notification switches, then the rule's Email deliveries tab or run history for the per-recipient outcome. If nothing at all is being delivered from any group, see the next question.
Why isn't any email being sent at all?
Email delivery depends on your workspace having an email sender configured. If it has not been set up yet, alerts are queued and skipped rather than sent; see Email deliverability. Contact ioX-Connect support if the sender is configured and no rule emails are arriving from any group.
Can one rule email several groups at once?
Yes. The Send email and Send SMS actions accept more than one group. Every active member across all selected groups is notified once.
What's the difference between a notification group and a multicast group?
A notification group is a list of people who receive alerts. A multicast group is a list of devices that receive a downlink. They share a similar name but do completely different things.