Three-Step Designer
Name the rule and its moment; write the if / otherwise-if / otherwise logic; review, test and turn it on. No developer, no release.
Business Rules: If This, Then That — Written in Plain Language, Tested Before It Goes Live
A rulebook the rest of the platform opens when something happens — written by a benefits person in three steps, tested on your whole workforce, and recorded every time it runs.
Who is eligible for which plan. Which response time a ticket gets. Which notice goes to whom. Whether a document needs a compliance flag. The decisions that used to live in a consultant's spreadsheet or a developer's queue become named rules anyone on the benefits team can read. And because rules look at employee details by plain names, the rule written for your SAP SuccessFactors employees works unchanged for the team on Workday or UKG.
If / otherwise if / otherwiseTest before you turn onEvery run recordedSame rule, any HR systemNo code
The Decision Book Behind Eligibility, Response Times, Notices and Compliance
"Think of Business Rules as a policy binder that the rest of Benefits Reimagined opens at the right moment. Plan setup opens it to decide who belongs in which group. BR Resolve opens it to choose a response time the second a ticket is created. Communication Hub opens it to pick a notice or build a mailing list. Document Center opens it to flag compliance. The binder decides; the module that opened it does the work — and every page it turned is on record."
Business AreaThe cover of the rulebookMomentsWhen the book opensWrite the LogicIf / otherwise if / otherwiseTest & Turn OnSee who changes, then switch it onRun & RecordThe module acts; the record proves
3steps to write a rule — name it, write the logic, review and turn it on — with no developer involved
11ways to compare — equals, is not, more than, less than, contains, is in a list, is between — with employee details picked from lists
0surprises when a rule goes live: every rule starts switched off and is tested on your full workforce before Turn On Now
100%of runs recorded — what went in, what came out, whether it worked, and when — ready for any audit question
Working Flow — Who Clicks What, in Order
From an empty binder to a rule answering live questions: the ten steps a consultant, an administrator and the modules that ask take, with the one thing the platform insists on at each step.
| # | Who · where | What happens | The rule at this step |
|---|---|---|---|
| 1 | Consultant Business Areas | Creates a business area for the module that will ask questions — plan setup, BR Resolve, Communication Hub, Workflow, Document Center — gives it a short code and says what kind of answer it returns: a value, or a calculation. | One area serves one module and returns one kind of answer. The short code is what the module calls, so it never changes once set. |
| 2 | Consultant Business Areas › Objects & fields | Lists the things a rule may look at (Employee, Document, Ticket) and the details on each — location, job code, union status, salary, hire date — delivered by HRIS Sync. | A rule can only see a detail listed here, and only if the module actually sends it. |
| 3 | Consultant Triggering Events | Adds the moment the question is asked: when a record is created, when it is saved, when a ticket opens, when a document lands. | The moment must be spelled exactly as the module sends it and switched on — or nothing runs. |
| 4 | Consultant Business Rules › Create New Rule · Step 1 | Names the rule, picks the area and the moment, sets a priority from 0 to 9 and, where the area allows it, limits the rule to one benefit area. | Every new rule starts switched off. |
| 5 | Consultant Step 2 · Build logic | Adds IF, OTHERWISE IF and OTHERWISE blocks, each with conditions on the fields and an action: set a value, or run a calculation. | Every chain ends with OTHERWISE unless it runs a calculation; no block may be empty; every block needs at least one action. |
| 6 | Consultant Step 2 · Explain | Opens the plain-words explanation of the logic written by the AI helper and reads it back to the business owner. | The explanation is a reading aid; it never changes the rule. |
| 7 | Consultant Step 3 · Review & test | Types sample values for an employee, runs the test and sees which branch answered and why. | The test uses exactly the shape of data the module will send in production; the first matching branch wins. |
| 8 | Consultant Step 3 · Activate | Chooses Turn On Now, or Save But Don't Activate. | Switching on is the publish step. There is no separate release and no second copy to deploy. |
| 9 | Plan setup · BR Resolve · Hub · Workflow At the moment | Sends the employee, ticket or document details with the moment; the engine finds every switched-on rule for that area and moment, judges each, and returns the actions. | All matching rules run and their actions are merged in their set order. The engine decides; the module acts — sends the notice, attaches the deadline, places the employee in the group. |
| 10 | Administrator Execution Logs | Reviews each run: what came in, which rules matched, what went back, and any calculation that failed. | Every run is written down — including the run where nothing matched. |
One Rule, Five Stages
Follow a union-aware eligibility rule from the area that holds it to the record that proves it ran — then see the same stages pick a ticket response time, a mailing list and a document flag.
A business area for every decision a module needs.
Every rule belongs to a business area: the module it serves, the employee details a rule may look at, and the kind of answer it gives back. Plan setup has areas for who may enroll and for cost, coverage, credit and contribution groups; BR Resolve has one for response times; Communication Hub for notices and mailing lists; Document Center for compliance. A consultant creates the area once, and the module's own setup screens show the same rule designer filtered to that area.
What an area defines
- The module it serves and a short name the module uses when it asks
- What the rule may look at — the employee, a document, a ticket — and which details, picked from lists
- The kind of answer: a value (a group, a response time, a notice) or a calculation (for example, a list of employees)
- Where the answer goes — the agreement between the rulebook and the module
Why it matters
The module never needs to know how a rule is built — only which rulebook to open.
Employee details have the same plain names whatever HR system they came from, so one rulebook serves every part of the company.
Moments say when — exactly.
A rule cannot exist without a moment: the point at which a module opens the binder. Something is created, saved, changed or removed; a ticket opens, a document is saved, an enrollment is confirmed, a dependent is taken off. The module names the moment when it asks, and only switched-on rules for that moment are read — so a draft never runs by accident, and a module asking at the wrong moment shows up in the run history before it shows up for an employee.
Moments in use today
- When a ticket is created — BR Resolve picks its response time; Workflow picks the notice for the first approver
- When a document or an enrollment is saved — Document Center flags compliance; enrollment looks up plan details
- When an employee record changes — eligibility and event groups are checked again
- When a dependent is removed — family eligibility responds
Why it matters
One moment, one binder, one place to see which rules opened.
Each moment can carry a note describing what details the module should send, so the people wiring a new module know what to pass.
If this, then that — written the way you would say it.
Step 2 is where the rule is written. Add an "if" block, add "otherwise if" blocks, close with "otherwise". Inside each block, conditions compare an employee detail with a value or with another detail — equals, more than, contains, is in a list, is between — joined by "and" or "or", and a block can hold another block for the exception inside the exception. Each block carries its answer: a group, a response time, a notice; or a calculation, such as every employee who has not started open enrollment. If the module already knows the answer, it can pass a simple yes or no instead.
What the designer enforces
- Every chain ends with an "otherwise" (unless a calculation closes it) — nobody falls through without an answer
- Every condition is complete and every block gives an answer before Continue lights up
- The left side is always an employee detail; the right side is a detail, a typed value, or a pick from a list
- Explain, on demand: a plain-English reading of the whole rule for a reviewer
Why it matters
A benefits person writes the policy; nobody has to translate it into code afterwards.
The whole rule is saved in one go, so it is always complete — never half-written.
Test it on your workforce, then flip one switch.
Step 3 reviews the rule and runs it as a test. You enter values for the details the rule uses — or point it at your live employee list — and see which branch wins, for whom, and how many people would move compared with the rule that is live today. A calculation can be tested for one chosen employee. Beside the diagram sits a plain-English explanation of how the rule works. Then you choose: Turn On Now, or Save But Don't Activate. New rules start switched off; turning it on is the publish step.
What you see before turning it on
- Employees per branch, and the difference against the rule that is live today
- One employee's path through the rule — which condition matched, which answer came back
- What a calculation returns for a chosen employee
- From the list: copy a rule for next plan year, switch one off, or open its diagram
Why it matters
The 37 employees who would change group are known before the rule is on — not after the first ticket.
A test never changes a record and never sends anything; only the module's real request does.
The rule decides; the module acts; the record remembers.
When a module asks, it names the rulebook, the moment and sends the details. The right rulebook opens, every switched-on rule is checked to its first matching branch, calculations run in a safe space, and the answers go back in order. BR Resolve applies the response time; Communication Hub sends the notice; Workflow picks the approver's message; plan setup applies the group. Then the run is recorded — what went in, what came out, whether it worked, and when — in a read-only history you can filter by rule, result and date.
What the record holds
- Which rule and version ran, on which moment, for which module
- The exact details received and the exact answers returned
- Worked, Failed or Skipped, with the reason — a failed calculation names what it was given
- Totals on the dashboard: rules switched on, success rate, runs per day, the trend
Why it matters
When an auditor asks why an employee was in that group on that date, the answer is a line in the history, not a memory.
Removing a rule from the list hides it; switching it off is what stops it running — the designer does both.
Rules of Business Rules — What the Platform Enforces
The guarantees behind the wizard. Each one exists to keep a decision predictable, auditable and impossible to publish by accident — and written only by a role that Security & Access Control allows.
| Rule | How it works | Why it is there |
|---|---|---|
| The engine decides; the module does | A rule returns the answer — set this value, run this calculation, pick this notice. The module that asked carries it out. | One decision layer, no hidden side effects, and every module free to act in its own way. |
| Only switched-on rules and moments run | A rule saved but not activated, or a moment that is switched off, is ignored at run time. | Nothing reaches an employee or a ticket by accident. |
| Every chain ends with OTHERWISE | Step 2 will not continue while an IF / OTHERWISE IF chain has no OTHERWISE — unless the chain runs a calculation. | Every employee gets an answer, including the unusual case nobody wrote a condition for. |
| All matching rules run, in set order | When several rules match, all of them answer and their actions are merged in the order set on the action. Priority is a label, not a tie-breaker. | The result is the same every time and can be read from the log. |
| Switch off, then delete | Deleting hides a rule from the list; it does not stop it. The platform expects it to be switched off first. | A hidden rule that is still on would keep answering. |
| Test with production-shaped data | Step 3 asks for the same details the module will send, and shows which branch answered. | What passes the test passes in production. |
| Editing a live rule keeps it live | Opening Step 1 of a switched-on rule does not switch it off; finish the wizard or switch it off first. | No half-finished logic answers a live question. |
| Every run is logged | Inputs, matched rules, answer, failures and the rule that answered are stored for every run. | An auditor can see which rule version decided, and when. |
What Business Rules Gives You
Built for benefits decisions — groups, response times, notices, mailing lists and flags — not a generic rules tool bolted on.
Conditions That Read Like Policy
And, or, nested exceptions, eleven ways to compare, and employee details picked from lists — enough to express union, location, hours and class policy exactly.
Values and Calculations
Give back a group, a response time, a notice or any value; or run a calculation — every employee who has not started enrollment, say — for mailing lists and totals.
Test Before You Turn On
Run the rule on the whole workforce or one employee, see who moves compared with today, read the plain-English explanation — then Turn On Now.
Every Run Recorded
What went in, what came out, whether it worked, and when — for every real run; totals and trends on the dashboard; filters by rule, result and date.
Inside the Module's Own Setup
The same designer opens inside plan setup — who may enroll, cost, coverage, credit, contribution, selection, event and family groups — showing only that area's rules.
Hidden Logic vs. BR Business Rules
Most benefits platforms keep their eligibility logic in tables a vendor maintains, or in code a developer owns. Here is what changes when the policy is a rule you can read.
| Moment | Vendor tables or code | BR Business Rules |
|---|---|---|
| A new bargaining unit joins | Ticket to the vendor; a release date. | Your consultant adds an "otherwise if" and tests it the same afternoon. |
| Testing the change | Try it in production on the first employee. | Test on the whole workforce — everyone who moves is listed before you turn it on. |
| A ticket needs a response time | One response time for everyone. | The rule picks it the moment the ticket opens, from company, category and employee details. |
| Choosing who gets a reminder | Export, filter in a spreadsheet, import. | A calculation returns the list — not started, started but not finished — to Communication Hub. |
| An auditor asks why | Read the code; ask whoever wrote it. | A line in the run history — details in, answer out, rule version, time. |
| An acquisition on another HR system | Rewrite the logic for the new field names. | Same rule — employee details keep the same plain names whatever system they came from. |
| Retiring a rule | Comment it out and hope. | Switch it off, keep the history, copy it next plan year. |
Athena inside Business Rules
Ask a Rule What It Would Do
Designers and auditors ask rules the same things in different words: what does this mean, who changes if I edit it, why did that employee land in that group. Athena explains a rule in plain English, narrates a test run, and reads the run history — and drafts the edit for a person to approve.
- "Explain this rule to me" — the logic in plain English, branch by branch, with the details it looks at
- "Who moves if I raise the hours threshold to 32?" — a test run and the list of affected employees
- "Why was Jane in Standard on March 3?" — the recorded run: details in, rule version, branch, answer
- "Which rules ran when this ticket was created?" — every run for that moment with its result
- "Draft the rule for the Local 42 exception" — a switched-off draft built from your words, ready to test
If I change the Salaried South threshold from 30 to 32 hours, who is affected?
Athena · tested on today's workforceTwenty-nine employees now in Salaried South work 30 or 31 hours and would fall to the "otherwise" branch, Standard. Nineteen are in Texas, ten in Oklahoma; none are in a bargaining unit, so the "otherwise if" does not catch them. Nobody moves the other way. The rule is still complete — it ends with an "otherwise" — and nothing has been changed.
Open the listDraft v4 with 32
Draft v4 but leave it switched off.
AthenaDrafted: v4 is saved switched off with the threshold at 32 hours and a note quoting your request. The test result is attached to Step 3 so a reviewer sees the 29 employees before choosing Turn On Now. v3 stays live.
Open Step 3Notify the benefits lead
Ask about any rule, test or run…
Why Benefits Teams Choose BR Business Rules
Plain Language, Real Logic
If, otherwise if, otherwise, with and / or, nested exceptions and eleven ways to compare — enough to express union, location, hours and class policy without a developer.
Tested, Not Hoped
Every rule runs on your workforce before it is on; the employees who change are a list, not a surprise in the first ticket.
Recorded Every Time
Details in, answer out, version, result and time for every run — the evidence an auditor, a regulator or a curious HR partner needs.
One Rulebook, Many Modules
Plan setup groups, Resolve response times, Communication Hub notices and mailing lists, Document Center flags, Workflow notices — one binder.
Works With Any HR System
Rules look at employee details by plain names; whether the record came from SAP SuccessFactors, Workday, UKG or ADP, the same rule gives the same answer.
Safe by Default
New rules start switched off, drafts never run, every chain must end in an "otherwise", and a test never changes anything.
Four Rules, End to End — How the Screens Fit Together
The screens are one path. An area is created, a moment is switched on, a rule is written, tested and turned on — and from then on the module that asked gets its answer the moment a record changes, on one version for every customer. Four stories show the path in use, and a fifth shows it running on records that did not come from SAP.
- The new bargaining unit — the consultant opens the eligibility rule, adds an OTHERWISE IF for the new union group, tests it on three sample employees and chooses Turn On Now — by the next morning, every save HR makes in SuccessFactors gets the right plan options
- The ticket with no deadline — a BR Resolve ticket opens without a response time; the administrator reads the Execution Log, sees that no branch matched, adds the missing OTHERWISE default and re-tests — the next ticket gets its deadline
- The open enrollment reminder list — Communication Hub asks the rule for everyone who has not started enrollment; the rule runs the calculation and returns the list; the Hub sends the notice and the run is on record
- The approval notice — Workflow asks which "your approval is waiting" message to send for an invoice, a life event and an access request; one rule with three branches answers all three
- The mixed-HRIS plant — the same eligibility rule answers for employees who arrived through the Paycom connection — the details carry the same plain names, so nothing is rewritten
Write the Policy Once. Let Every Module Read It.
Bring one eligibility policy you keep in a spreadsheet or a vendor ticket queue today. We'll write it as a rule in three steps, test it on a sample workforce, and show you the record a module would leave behind.
Test before you turn onEvery run recordedSame rule, any HR system
Business Rules FAQs
A written decision about who gets what: from an employee's details, which group, plan, response time, notice or flag applies. In Benefits Reimagined those decisions are Business Rules — written as if-then sentences, grouped by business area, run at a chosen moment, and recorded every time.
No. A benefits consultant or analyst writes a rule in three steps — name it, write the logic, review and turn it on. IT is involved only when a new module needs to use rules for the first time, or when a calculation is written.
Yes. Step 3 runs the rule on your whole workforce or one chosen employee, shows how many people land in each branch and who would change compared with today's rule, and explains the rule in plain English. Every new rule starts switched off; Turn On Now is the publish step.
Who may enroll and which cost, coverage, credit and contribution group applies; the response time for a BR Resolve ticket; which notice Communication Hub sends and to whom; which message Workflow sends an approver; whether a document gets a compliance flag; and plan details looked up during enrollment.
No — the rule decides and the module acts. A rule answers "use notice 14" or "response time 7" or "these 312 employees"; Communication Hub sends, BR Resolve applies, Workflow routes. That keeps every action with the module that owns it and every decision on record.
Every real run is recorded with the details received, the answer given, the rule and version, the result (worked, failed or skipped) and the time. The run history can be filtered by rule, result and date; the dashboard shows totals, success rate and runs per day.
Yes. Rules look at employee details by plain names, never by a vendor's field names. HRIS Sync fills those details from SAP SuccessFactors, Workday, UKG, ADP, Dayforce or Paycom, so one rulebook serves every part of the company.
All switched-on rules that match run, and their answers are kept in the order you set; inside one rule the first matching branch wins, and "otherwise" always applies when reached. Each business area has a short name so a module always opens the rulebook it meant to.
Turning It On Is the Publish Step.
Business rules for benefits, written in plain if-then sentences, tested on your people and recorded every time they run — on SAP SuccessFactors today and on whichever HR system arrives next.