Channels & Infrastructure
Email over SMTP, SMS through the provider path, and in-app notification into BR Inbox — configured once in BRConfig with credentials, active flags, and per-channel settings.
Employee & HR Experience · Communication Hub
Benefits Messages That Send From the Benefits Data
Programs, versioned templates, per-channel bodies, rule-based audiences, schedules, and a delivery log for every send.
Communication Hub is the outbound message factory inside Benefits Reimagined. Consultants stand up the channels once; benefits and communications teams then build programs and templates with a body per channel; and whenever something sends — a test, a schedule, an enrollment rule, or another module such as WorkFlow or Dependent Verification — the engine resolves the audience at send time, personalizes the text, delivers by email, SMS, and in-app notification, and writes a delivery-log row you can produce on demand.
Email · SMS · In-appRule-based audiencesWorkFlow-approved publishingDelivery log per recipient
Reimagining Benefits Communication
"Think of Communication Hub as three rooms. Infrastructure — channels, SMTP and SMS configuration, timing, categories, merge fields — is the post office and the stamps, set up once by consultants. Content and send — programs, templates, schedules, delivery audit — is the mailroom where benefits teams work. Receiving — email, SMS, and BR Inbox in the app — is the employee's mailbox. Nothing here writes an enrollment; this module only talks."
Programs & TemplatesVersioned, one body per channelAudience RulesPicker or rule, resolved at sendSend EnginePersonalize, deliver, logScheduleNamed sends at a date and timeDeliveriesThe outbound audit
3live channels — email, SMS, and in-app notification into BR Inbox — each rendered from its own body on the same template version
6enrollment audience rules — open enrollment or life-event offer not started, started-not-completed, or ending soon — evaluated at send time, never from a saved list
1delivery log row per recipient per channel, with the rendered text, trigger type, who or what triggered it, status, and read time
0campaign spreadsheets — a program is a bucket of templates, an audience is a picker or a rule, and a schedule is a named date and time
From Template to Proof of Delivery
Follow an Open Enrollment reminder through the five things Communication Hub controls: the program and template, the audience rule, the send engine, the schedule, and the delivery log.
A program is the cabinet; a template is the message
A program is a bucket of messages with a code, a display name, an owning category (enrollment offers, life events, dependent verification, workflow, document management, and more), an owner, and a status. Templates hang off it — each versioned, with a subject and body per channel, a language, an optional thumbnail, compliance flags such as ACA, HIPAA, COBRA, or ERISA, and a category for the in-app inbox. AI can optimize a body and score its quality; publishing can require approval through BR WorkFlow, during which the template is locked from editing.
What it delivers
- Program codes and categories that map to the module that owns the message
- Template versions with a body per channel — email, SMS, in-app — and a frequency (immediate, before, or after a trigger)
- Draft → In review → Active → Rejected status, with WorkFlow approval when the program or template requires it
- Send test from an Active template to a small group before any rule or schedule uses it
Why it matters
One message design, rendered correctly for every channel, with a version history behind it.
Two switches matter: the status controls what the UI lets you send; the engine's active flag controls what other modules can send. Keep them aligned.
Who receives it is decided when it sends
There is no audience table. A template's audience is either a manual picker — company, location, department, business unit, division, named employees, or everyone — or a business rule. Enrollment rules cover the six moments that matter: open enrollment or a life-event offer not started, started but not completed, or ending soon. The list is computed at send time from the enrollment data for the benefit area you pass, so a reminder goes to the people who still need it that morning, and "days left" is calculated then, not when the message was written.
What it delivers
- Manual picker with a headcount check on save — an empty audience warns before you continue
- Six enrollment rule types across open enrollment and life-event offers
- Send-time filters: benefit area, benefit group, benefit status, enrollment type, and the life-event reason for event rules
- Employee channel preferences honoured — one preferred channel when it intersects the template, otherwise every channel with a body
Why it matters
Nobody is reminded to do something they already did.
A life-event rule needs the event reason and the benefit area at send; the engine refuses to guess.
One pipeline for every send
Every send — a test from a template, a business rule firing from enrollment, a schedule coming due, an override, or another module such as WorkFlow, Dependent Verification, or the plan document library — runs the same pipeline. Require the program; load the latest active template version; resolve recipients from the list, picker, or rule; queue a bulk job when there are more than ten; then for each person and channel, personalize the merge fields, mask PII, deliver, and write the delivery log.
What it delivers
- Merge fields from a personalisation catalogue — first name, plan, dates — with PII masking on render
- Live delivery on email (SMTP), SMS (provider), and in-app notification into BR Inbox over WebSocket
- Bulk sends deferred to a background job so the UI never waits on thousands of rows
- Override sends recorded with reason, performer, and recipient count when a template allows them
Why it matters
The same engine serves the mailroom and every module that needs to talk to an employee.
Channels named WhatsApp, Slack, Teams, and Postal exist in configuration but log Failed today — plan on email, SMS, and in-app.
Timed sends that a job picks up
A schedule is a named send — a program, a template, a date, and a time. A background job runs every five minutes, finds due schedules, and sends each detail row on the channel it was evaluated for, marking rows Pending, In progress, Sent, Skipped, or Failed. Schedules are for "Monday 08:00"; large manual sends are not schedules — they become bulk jobs automatically, and enrollment reminders driven by rules fire from the enrollment events themselves.
What it delivers
- Create, update, and skip schedules — whole or a single detail row
- Per-recipient detail rows with the evaluated channel, sent time, status, and resolution log
- A five-minute pickup window with forced-immediate delivery on the detail channel
- Status you can trust on the schedule detail and in the delivery log
Why it matters
Timing becomes configuration a benefits team owns, not a calendar reminder for one person.
Read timing from the schedule detail and the delivery log — those rows are the truth for what went where.
Deliveries are the outbound audit
The Deliveries page is not an inbox — it is the record of what left the building. Every row carries the program, template and version, channel, recipient, rendered subject and body, trigger type (manual, scheduler, business rule, override), who or what triggered it, status (Pending, Sent, Failed, Read), delivery and read times, the in-app conversation reference, a failure reason when there is one, the calling module, and the business reference — a claim, an event, a workflow step. Filter, search, export, and watch it refresh live.
What it delivers
- Per-recipient, per-channel rows with the exact rendered text
- Trigger type and triggering user, rule, or module on every row
- Failure reasons for SMTP, provider, and unimplemented channels
- Business context — module id and reference — so a delivery ties back to the event that caused it
Why it matters
"Did we send it, to whom, and what did it say?" is a filter, not an investigation.
Live analytics actions exist over this log — delivery trends, channel performance, template engagement, trigger distribution — and feed BR Intelligence dashboards.
Core Capabilities of Communication Hub
The pipes, the mailroom, and the audit — configured in BRConfig, operated in BR Communication, delivered to email, SMS, and BR Inbox, and shared by every module that needs to reach an employee.
Programs & Versioned Templates
Programs by owning category; templates with a body per channel, language, frequency, compliance flags, AI quality scoring, and Draft → In review → Active status with WorkFlow approval.
Audiences at Send Time
Manual pickers over company, location, department, division, or named employees, or enrollment rules for offers not started, in progress, or ending soon — resolved when the message sends.
Personalisation & PII
A merge-field catalogue pointing at real table fields, rendered per recipient with PII masking; employee channel preferences respected.
Schedules & Bulk Jobs
Named sends at a date and time picked up by a five-minute job; large sends deferred to a bulk job automatically; per-row status and resolution logs.
Delivery Log & Analytics
One row per recipient per channel with rendered text, trigger, module, reference, status, and read time — the base for delivery trend, channel, template, and trigger analytics.
Athena inside Communication Hub
Explain the Audience, Then Draft the Send
Athena works from the same rules and delivery rows the engine uses. It explains why a rule selected 4,812 people this morning and not 5,100 last week, reads the delivery log for what failed and why, proposes the next template body from the approved one, and answers an employee's "what does this notice mean?" from their own enrollment — while approval, sending, and channel choice remain a person's decision.
- Audience explanations — which rule, which benefit area, which enrollment state — and who dropped out since the last send
- Delivery diagnostics — failed rows grouped by reason: SMTP rejections, missing SMS consent, unimplemented channels
- Template drafts — a next-wave body proposed from the active version, submitted through the same approval path
- Employee questions — a notice explained from the employee's own offer, dates, and plan — inside BR Inbox or Athena
- Coverage checks — which populations have no template with a body on their preferred channel
Why did the audience drop from 5,100 to 4,812 since last week?
AthenaRule O_OFFER_NOT_STARTED is re-evaluated at each send. Since 09/08, 288 employees in BAREA US started their open enrollment, so they no longer qualify; 191 of them have already submitted. Nobody was removed by hand — the rule simply reflects Monday morning's enrollment data.
Started since last send288 · removed by rule
Still not started4,812 · in this send
Show the 288Draft Wave 3 bodyCheck SMS consent
Why did 112 emails fail?
Athena98 were SMTP 550 rejections from one retired domain in Distribution — their in-app copy was read by 71 of them, so they were reached. 14 failed because the template's SMS body went to employees without consent; those rows are logged Failed with the reason. I can queue a corrected address list for HRIS Sync.
Ask Athena about this program…
What Communication Hub Changes
One message, every channel
A template is written once and rendered per channel from the same version.
Audiences from the data
Enrollment rules pick recipients at send time; reminders stop reaching people who already acted.
Publishing with approval
Programs and templates can route through WorkFlow before they go live, and lock while they wait.
Every module speaks through it
Enrollment offers, dependent verification, plan documents, and workflow steps all send from the same engine.
Proof on every row
Rendered text, trigger, module, status, and read time per recipient — the outbound audit.
Employees receive where they read
Email, SMS, and BR Inbox in the app, with their preferred channel honoured.
Where It Shows Up in the BR Experience
Communication Hub is three applications on one engine. Consultants configure channels, SMTP and SMS settings, frequency, template categories, and merge fields in BRConfig → ISD → Communication Hub. Communications and benefits teams work programs, templates, schedules, and deliveries in BR Communication on SAP BTP and AWS. Employees read in-app messages in BR Inbox, and in their email and SMS.
- Consultant: BRConfig pipes — channels with credentials and active flags, timing (immediate, before, after), inbox categories, and the personalisation attribute catalogue
- Ops: dashboard — approval, schedule, delivery, and high-risk KPI tiles, quick actions, Essential Insights, and recent deliveries
- Ops: programs, templates, schedule, deliveries — program cards by category and status, template library and per-program views with channel preview and send test, schedules with detail rows, and the filterable delivery log
- Employee: BR Inbox and channels — in-app conversations grouped by category, plus email and SMS on the channels they prefer
- Other modules: WorkFlow, Dependent Verification, plan documents, enrollment rules — all send through the same engine and appear in the same delivery log with their module and reference
Send one real reminder and read the log
Bring an OE date and a template you use today. We'll configure the channels, build the program and versions, resolve the audience from your enrollment data, send to a test group, and open the delivery log together.
Email · SMS · In-app liveSend-time audiencesWorkFlow approval
Communication Hub FAQs
Email through your SMTP configuration, SMS through the configured provider, and in-app notification into BR Inbox. Other channel names exist in configuration for future use but do not deliver today and are logged as failed if selected.
Either a manual picker over company, location, department, business unit, division, or named employees, or a business rule. Enrollment rules select employees whose open enrollment or life-event offer is not started, started but not completed, or ending soon — and they are evaluated when the message sends, so the list is always current.
Yes. A program or template that requires approval is submitted to BR WorkFlow, cannot be edited while in review, and becomes Active or Rejected when the last approver acts. Send from the UI requires an Active template.
More than ten recipients are handed to a background bulk job that runs within about a minute, so the screen never waits on thousands of rows. Named schedules are separate: a five-minute job picks up due schedules and sends each detail row on its evaluated channel.
Yes. Enrollment offer rules, BR WorkFlow step and reminder notices, Dependent Verification, and the plan document library all send through the same engine, and every one of those deliveries appears in the log with its module and business reference.
No — it is the outbound audit: one row per recipient per channel with the rendered subject and body, trigger type, triggering user or rule, status, and read time. Employees read their in-app messages in BR Inbox.
No. It only talks. Enrollment happens in BR Profile; tickets are worked in BR Resolve. Communication Hub tells people what to do and proves it told them.
Every Notice From the Data, Every Send on the Record
Channels configured once, templates versioned per channel, audiences resolved at send time, and a delivery log that answers the audit question before it is asked.