Groups and Roles
People in groups, roles on groups, a default group for new people, and an approval flag for the sensitive ones. One change fixes everyone.
Security & Access Control: Everyone Sees Exactly What They Should. Nothing More.
Decide who can open which screens and whose benefits records they can see. Put people in groups, give groups roles, ask for approval before anyone joins a sensitive group, set an end date on access — and keep every decision on record.
Benefits data is personal: health elections, dependents, pay deductions, account balances. Security & Access Control answers two questions separately for every person — can they open this screen, and can they see this record — so an outside broker sees dental elections and nothing else, an HR partner sees one division, and a payroll fix at 6 pm gets two hours of access that ends by itself. People sign in once, with the login they already use for SAP SuccessFactors or your company's identity provider; when someone leaves, their access ends the same day.
Groups → roles → screens + recordsApproval before joiningAccess with an end dateEvery yes and no on recordOne login · SuccessFactors or any provider
Two Questions, Answered Separately, Recorded Every Time
"Think of access as two rooms. The first is the building directory and the keycard for each door: can this person open this screen? The second is the lock on the filing cabinet inside the room: can this person see this employee, this plan, this record? Most systems answer only the first question. Benefits Reimagined answers both — through groups and roles a security administrator designs once — and writes down every answer it gives, so an auditor can ask about any person on any day."
Groups & RolesPeople get groups; groups get rolesWhich ScreensOpen, closed, or not mentionedWhose RecordsPlans, divisions, actionsApproval & Time LimitsAsk · approve · expireHistoryEvery change, every yes, every no
2questions answered separately for every person — which screens they may open, and whose records they may see or change
1login — the one people already use for SAP SuccessFactors or your company's identity provider; no second password
0access left behind when someone leaves — groups end the day the HR record closes, and emergency access ends on its own
100%of permission changes and allow-or-block decisions written down, permanently, with who, what and when
Working Flow — Who Clicks What, in Order
From an empty map to an employee signing in and seeing exactly what they should: the ten steps a consultant, an administrator, an approver and every BR screen take, with the one thing the platform insists on at each step.
| # | Who · where | What happens | The rule at this step |
|---|---|---|---|
| 1 | Consultant Resources | Loads the map of each BR application — module, then page, then section, then button. | Only a screen on the map can be opened or hidden. |
| 2 | Consultant Roles | Creates the roles — HR Operations, Benefits Administrator, Auditor, Payroll — with a name and a plain description. | A role is a bundle of doors and locks. It is never given to a person directly. |
| 3 | Consultant Role Permissions | Grants the application first, then opens or hides its pages, sections and buttons for the role. | No application grant means the application is closed. Inside a granted application, a screen shows unless it is hidden. |
| 4 | Consultant Scopes | Says which records the role may touch — benefit areas, plan categories, plan types, departments, locations — and which actions: view, create, edit, delete. | A role with no scope sees no records in the protected screens; a scope that lists no actions is view-only; "all records" is a master key and is used sparingly. |
| 5 | Consultant Role › Scope and Group › Role | Attaches scopes to roles, then roles to groups. | People get groups, groups get roles, roles get doors and locks. |
| 6 | Consultant Groups | Creates the groups, marks one as the default for new starters, and marks sensitive groups as approval-required. | Approval-required needs a Workflow template in place first; only one group can be the default. |
| 7 | Administrator User Assignments | Adds an employee to groups with a type — direct, override or emergency — a start and end date, and a requester when approval is required. | A pending membership opens nothing; emergency access ends on its date. |
| 8 | Approver Workflow | Approves or rejects the join request — one request per assignment. | Approval makes the membership count. Rejection removes it. |
| 9 | Employee Any BR application | Signs in once. The application asks which screens this person may open; every protected list asks which records they may see. | Two questions, always both, and every decision written down. |
| 10 | Administrator App Permissions check | Picks an employee and an application to see exactly what they get, and reads the decision history when someone asks "why can't I see this?" | The check reads the same map the applications read, so it is never a guess. |
One Person, Five Stages of Access
Follow Maria, an HR partner in Texas, from the group she is placed in to the record of what she opened — including the sensitive group she asked to join and the emergency access a colleague needed at 6 pm.
People get groups. Groups get roles.
Nobody is given a screen or a record directly. Maria is placed in the HR Operations group; the group carries the HR Operations role; the role says which screens open and whose records show. Change the role and every person in the group changes with it — no hunting through individual accounts. One group can be the default for new people. A group that holds sensitive information can be marked as needing approval before anyone joins. Outside brokers, carrier representatives and payroll reviewers are groups too, with roles as narrow as you like.
What the model holds
- Groups — named containers of people, with a default group and an approval flag
- Roles — bundles of screens and record permissions, attached to groups
- Membership with dates — direct, override or emergency, valid from and until
- Outside people as first-class groups — a broker, a carrier representative, an auditor
Why it matters
One change to a role fixes access for everyone in the group, in one place.
Maria's group membership comes with her HR record: when SuccessFactors moves her to Finance, her groups change with her, and nothing is left behind.
Which screens a role may open.
A security administrator paints a role's screens as a tree: apps, then screens inside them, then sections and buttons. Each can be open or closed. The rule is simple: open the app first, then close the screens this role should not have; a screen nobody mentioned is shown. An app that was never opened stays hidden entirely, whatever is said about its screens. Every other part of Benefits Reimagined — Employee Management, plan setup, reports, Document Center — reads this map when a person signs in and hides what is closed.
How the switches work
- Open the app, then close individual screens, sections or buttons
- Not mentioned means shown — hide by closing, not by forgetting
- A troubleshooting screen shows exactly what any person sees in any app
- Screens you may open are separate from records you may see — the next stage
Why it matters
An administrator can answer "why can't she see that?" in a minute, from one screen.
Employee-facing screens — Employee Home, enrollment, My Requests — use the same map, so an employee's view is set by the same roles.
Whose records a role may see — and change.
Opening a screen is not the same as seeing a record. A role also carries record permissions: which plans (medical, dental, spending accounts), which parts of the company (division, department, location, state, country), and which actions (look, add, change, remove). A role with no record permissions can open a screen and still see nothing in it — the safe default. An HR partner sees one division; a dental broker sees dental elections and nothing else; a payroll reviewer sees deductions for everyone but never health details. The master key that sees everything exists, and is meant to be rare.
The dials on a record permission
- Plans — benefit area, category, plan type, specific plan
- People — division, department, location, state, country
- Actions — look only, or add, change and remove
- The master key — sees everything; use sparingly and record its use
Why it matters
The outside broker never sees an HSA balance, even if someone opened the wrong screen for them.
Every allow or block on a record is written down as it happens — the next-but-one stage.
Some groups need a yes first. Some access ends by itself.
Groups that hold sensitive data can require approval. Adding Maria to Privileged Admins creates a request, with the person who asked on record; it goes to the approver through Workflow like any other approval; until they say yes, nothing opens. Yes puts her in; no removes the request; both are recorded. Access can also carry an end date: a broker gets open-enrollment access until December 15 and it ends by itself. And emergency access — a payroll fix at 6 pm — can be granted for two hours, marked as emergency, with every screen opened recorded.
What can be set
- Approval required on a group — the request goes through Workflow, with a named requester
- Direct, override or emergency membership, each with a valid-from and valid-until date
- Emergency access that expires on its own, marked and recorded
- Declined requests are removed; approved ones start the day the yes lands
Why it matters
Nobody joins a sensitive group by accident, and nobody keeps emergency access by accident.
Approval-required groups need an access-request template in Workflow first; the platform will not create a pending membership without one.
Every change, every yes, every no — written down.
Two kinds of record are kept. Changes to groups, roles and permissions — who was added, what was opened or closed, who approved — are written down permanently and cannot be edited. And every time the platform lets someone in, or keeps them out of a record, that decision is written down too: Maria opened employee 10422, allowed; the broker tried to open HSA balances, blocked. An auditor, a regulator or a curious HR director can ask about any person on any day and get a list, not a memory.
What the history holds
- Permission changes — create, assign, approve, close — with who and when, permanently
- Access decisions — allowed or blocked — on records, as they happen
- Join requests — asked, approved or declined, with the approver's name
- Expiries — emergency and dated access that ended on its own
Why it matters
"Who could see this employee's record in March?" has an answer in minutes.
Sign-in activity is kept separately by your identity provider; the two records together tell the whole story.
Rules of Access Control — What the Platform Enforces
The guarantees behind the screens. Each one exists to keep access exact, temporary when it should be, and always explainable — on a platform where every record keeps its history.
| Rule | How it works | Why it is there |
|---|---|---|
| People get groups, groups get roles | Access is never attached to a person. It is attached to a role, the role sits in a group, and the person joins the group. | A leaver, a mover or an audit is handled at the group, not one person at a time. |
| Grant the application, then hide | A role must be granted the application before any page inside it can open. Within a granted application, screens show unless hidden. | One switch closes a whole application; fine control stays simple. |
| Doors and locks are separate | Opening a screen does not open its records. A role with no scope sees an empty list; a scope with no actions listed is view-only. | Seeing a page never means seeing everyone's data. |
| "All records" is a master key | A scope marked all records removes every filter for that role. | Used deliberately, for a few named roles, and visible in the history. |
| Approval-required means Workflow first | A group cannot be marked approval-required until a Workflow template for join requests exists. | No join request can be sent into a queue nobody watches. |
| Pending membership opens nothing | Until the approver says yes, the membership is invisible to every screen and every list. | No access before the approval that justifies it. |
| Every assignment has dates | Direct, override and emergency memberships all carry a start and an end; emergency access is short by design. | Weekend access ends on Monday without anyone remembering to remove it. |
| One default group | Exactly one group is the default for new starters. | Every new employee lands somewhere safe on day one. |
| Every decision is written down | Each screen decision and each record decision is stored with the person, the time and the answer. | "Why can't she see this?" is answered from the record, not from memory. |
What Security & Access Control Gives You
Built for benefits data — plans, dependents, deductions, balances — and for the outside people who need a narrow view of it.
Which Screens
A painted tree of apps, screens, sections and buttons per role — open, closed or not mentioned — read by every part of the platform at sign-in.
Whose Records
Plans, parts of the company and actions, set separately from screens, with a safe default of nothing and a rare master key.
Approval Before Joining
Sensitive groups require a yes through Workflow before anyone is in; the requester, approver and answer are on record.
Access With an End Date
Direct, override or emergency membership with valid-from and valid-until dates; emergency access marked and expiring on its own.
History You Can Show
Permission changes written permanently; every allow-or-block on a record written as it happens; a troubleshooting screen that shows what any person sees.
Typical Permissions vs. BR Security & Access Control
Most benefits platforms offer a handful of fixed user types and a single yes-or-no per screen. Here is what changes when screens and records are decided separately, and every decision is recorded.
| Moment | Typical permissions | BR Security & Access Control |
|---|---|---|
| A broker needs to see dental elections | Give them an admin login and hope. | A broker group that opens enrollment reports and sees dental elections only. |
| Someone opens a screen they shouldn't | They see everything on it. | Screens and records are separate — the screen opens, the records stay hidden. |
| Joining the privileged group | An admin ticks a box. | A request goes for approval; nothing opens until the yes lands, and the yes is on record. |
| A payroll fix at 6 pm | Grant admin and remember to remove it. | Emergency access until 8 pm, marked, recorded, expiring by itself. |
| Someone leaves | Access lingers until somebody notices. | Groups end the day the HR record closes — from SuccessFactors or any HR system. |
| An auditor asks who could see a record | Reconstruct it from memory. | A list — every change and every allow-or-block, with who and when. |
| "Why can't she see that screen?" | A support ticket. | One troubleshooting screen shows exactly what she sees, and why. |
Athena inside Security & Access Control
Ask Who Can See What — and Why
Security administrators and auditors ask the same questions in different words: why can't she open that screen, who could see this employee last month, who is still in the privileged group, what did the emergency user touch. Athena answers from the groups, roles, memberships and history — and drafts the change for an administrator to apply.
- "Why can't Jane see the QMCSO screen?" — the app was never opened for her role — and the one change that fixes it
- "Who could see employee 10422 in March?" — every group and role with that record in scope, on those dates
- "Who is in Privileged Admins, and who approved them?" — the members, the requester and approver for each, and any pending request
- "What did the emergency user open last night?" — every screen and record, allowed or blocked, until the access expired
- "Draft a broker role that sees dental only" — a role prepared with screens and records, not yet applied
Who could see employee 10422's record on March 3, and did anyone outside HR open it?
Athena · from groups, roles and the historyOn March 3, employee 10422 was in the HR division, so three groups had the record in scope: HR Operations (38 people), Benefits Analysts (9) and Privileged Admins (4). The history shows two people opened it that day — Maria (HR Operations) at 10:40 and D. Patel (Privileged Admins) at 15:12 — both allowed. One attempt from the dental broker group at 14:03 was blocked, because that role sees dental elections only. Nobody outside those groups could reach it.
Export for the auditorOpen the broker role
Export it for the auditor, and tell me if the broker attempt needs following up.
AthenaExported: a one-page list of who had the record in scope, who opened it and the blocked attempt, with times. The broker attempt was blocked as designed — the role has no permission on that record — and the broker was on an open-enrollment report at the time, so it looks like a mis-click rather than a probe. I have not changed anything.
Download the exportFlag for review anyway
Ask about any person, group, role or record…
Why Security and HR Leaders Choose BR Access Control
Groups, Not Exceptions
People get groups, groups get roles — one change fixes everyone, and nobody carries a one-off permission that outlives its reason.
Screens and Records, Separately
Opening a screen never means seeing a record; the safe default is nothing, and the master key is rare and recorded.
A Yes Before the Sensitive
Groups that hold sensitive data require approval through Workflow, with the requester and approver on record.
Access That Ends Itself
Dated and emergency access expire on their own; leavers lose everything the day their HR record closes.
History You Can Show
Every permission change and every allow-or-block, written permanently — the answer to any audit question is a list.
One Login, Any HR System
Sign in once with SAP SuccessFactors or your company's identity provider; groups follow the HR record whether it comes from SAP, Workday, UKG or ADP.
Four Access Requests, End to End — How the Screens Fit Together
The screens are one path. The map is loaded, roles and scopes are built, groups carry them, people join groups — and from then on every BR screen — Employee Management, Business Rules, reports — asks the same two questions. Four stories show the path in use, and a fifth shows membership following an HR record that did not come from SAP.
- HR Operations opens Employee Management — the consultant grants the application and its pages to the HR Operations role, limits its scope to the HR department and one benefit area with view and edit, hangs the role on the HR Operations group and adds the team — they sign in and see only their own department
- The Privileged Admins group — marked approval-required, so the administrator's assignment sits pending; the security lead approves in Workflow and only then can the new admin open Security — a rejection would have removed the request
- Emergency weekend access — a payroll analyst is added with the emergency type and an end date of Monday; access is immediate because the group needs no approval, ends on its date, and the change is flagged in the history
- "Why can't she see QMCSO?" — the administrator opens the App Permissions check for the employee and the QMCSO application, sees that her role was never granted that application, adds the grant — and reads back the decision that had said no
- The leaver from Workday — a termination arrives through the Workday connection; the membership ends on the leaving date through HRIS Sync and every screen closes at once
Everyone Sees Exactly What They Should. Nothing More.
Bring three real roles — an HR partner, a benefits analyst and an outside broker. We'll build them as groups and roles, show what each one sees on the same screen, ask one of them to join a sensitive group, and read the history back at the end.
Screens and records decided separatelyApproval before joiningAccess with an end dateHistory you can showOne login · SuccessFactors or any provider
Security & Access Control FAQs
Only what their role allows. A manager role typically sees the manager's own team and the records the role names — elections, say, but not health details or pay deductions. Screens and records are decided separately, so a manager can open a screen and still see only their team's records in it.
Their group memberships end the day the HR record closes — whether that record lives in SAP SuccessFactors, Workday, UKG or ADP — so no screen and no record stays open. The closure is written to the history with the date.
Yes. They are placed in their own groups with roles as narrow as you like — a dental broker who sees dental elections only, an auditor who reads but never changes. Their access can carry an end date, and every record they open or are blocked from is written down.
Yes. Membership can be direct, an override or an emergency grant, each with a valid-from and valid-until date. Emergency access is marked as such and expires on its own; every screen opened during it is recorded.
Only people whose own role opens Security & Access Control. Groups that hold sensitive access can require an approval before anyone joins, so even an administrator cannot add someone to the privileged group without a second person saying yes.
Yes. People sign in once with the login they already use — SAP SuccessFactors, or your company's identity provider — and the roles they have there become their BR roles. There is no second username or password to manage.
Yes, permanently. Every change to groups, roles and permissions is written down with who and when and cannot be edited. Every time the platform allows or blocks someone from a record, that decision is written down as it happens.
Because screens and records are two separate permissions. Opening the screen comes from the role's screen map; seeing the records on it comes from the role's record permissions. A role with no record permissions sees an empty screen — the safe default — until an administrator adds the records it should see.
Who Sees What, Decided Once and Recorded Always.
Groups and roles designed once, screens and records decided separately, approvals before the sensitive, access that ends itself, and a history you can show — for your SAP SuccessFactors workforce and every part of the company on another HR system.