Screen-Aware Help
The page, screen, tab and form travel with every question; this screen's approved help is retrieved first, then related help for the same form, then the creation screen for a "how do I set up" question.
The administrator's assistant inside every module: approved help, real checks, read-only lookups, no changes.
An administrator asks a question on the screen they are configuring. Athena retrieves the approved help for that screen, runs a configuration or compliance check when the question calls for one, looks up employee facts read-only when the administrator opts in, and explains the result in plain language with a link to the screen where the next step happens. It never saves, creates, re-runs or transmits anything — and never says it did.
"Administrators do not need a chatbot that knows everything. They need one that knows this screen: what the field means, what the rule is, whether the setup is complete, and — when they ask — which employees a rule caught. Athena for Admins is built from the approved help text behind every 'i' button, a set of deterministic checks, and a guarded read-only lookup. It explains. It links. It changes nothing."
The assistant as it runs today in the ACA module and the configuration console — who does what, in order, and the rule the platform enforces at each step.
| # | Who | What they do | What the platform enforces |
|---|---|---|---|
| 1 | Administrator | Opens the module — ACA, the configuration console — and works on a screen; the floating Athena panel is on every page. | The panel knows the current page, route, screen and, in the configuration console, the current tab and form. |
| 2 | Administrator | Types a question, or picks one of the suggested questions for this page; optionally pins the source (auto, help only, employer documents) and, in ACA, ticks Include employee data. | An empty question is refused; about the last eight turns travel with it so "that field" still makes sense; a short follow-up is searched together with the previous question. |
| 3 | Athena | Retrieves the approved help for this screen: the screen's own rows first, then a meaning-based search, then a keyword search with synonyms, ranked. | Only active help rows are used; matched screen ids become in-app links resolved from the module's own tab registry. |
| 4 | Athena | Decides the kind of answer: employee lookup (box ticked), configuration check, compliance check, or help only — with the source pin able to force help only. | A named risk question ("who is full-time with no offer?") runs the compliance analyzer, not a free query, so the names match the health-check counts. |
| 5 | Athena | Runs the deterministic check when there is one — configuration domains taken from the question, tax year from the question when present — and builds the buttons for it in code. | Checks run from the question alone; the employee-data box is not required for them. |
| 6 | Athena | For a lookup with the box ticked: resolves a named person to a record, writes one read-only statement against allow-listed tables and columns, capped at 200 rows, repairing up to three times. | Anything but a single read is rejected; a question that cannot be answered as a query is answered from help text instead. |
| 7 | Model | Writes the answer in plain language from those facts only — help passages, check findings, rows — and says which source it used. | It must not print table names, the query, a full Social Security number or a secret; it must not claim it re-ran, corrected, approved or transmitted anything. |
| 8 | Administrator | Reads the answer, follows a link to the screen, does the work there. | Navigation is a suggestion; the change is made on the screen with its own validation and audit. |
| 9 | Administrator (configuration console) | Uploads, searches, views or deletes employer configuration documents in the Documents library — the assistant's secondary source. | Extracted text is cached for about thirty minutes; a change is visible to the assistant after that. |
Follow an ACA administrator and a configuration consultant through the same panel — and see which source, which check and which guard applies to each question.
The ACA administrator is on the Measurement & Stability screen. The panel's welcome tells her that approved help is the default source and that Include employee data is needed only for live employee counts. Suggested questions change with the route — dashboard, execute, executed reports, penalties, employees, wages and time — and a question bank feeds the search. She asks "what's the difference between look-back and monthly measurement?" The panel sends the question, the page context and the last few turns; nothing about her identity changes hands beyond her own login.
Help that knows where you are is help you don't have to search for.
The administrator's own login is the only identity; the question cannot name another user as its subject.
Every "i" button on every screen has approved help text behind it — title, content, the screen and control it belongs to. Athena loads the rows for the current screen directly, then searches all help by meaning and by keyword (with synonyms: "set up" also finds create and configure; benefit-area and plan-type terms are boosted), ranks the passages, and answers from the best five. In the configuration console it adds related help for the same form, and for a "how do I create…" question it also pulls the help for the creation screen. The screens it matched come back as links, resolved in the browser from the module's own tab registry.
The answer is the benefits team's own words, not the internet's.
Improving an answer means editing the help text behind the "i" — no model work, no deploy.
"Is our configuration healthy?" runs the configuration health check: the domains to check come from the words in the question — or all domains when none is named — and the tax year from the question when it is there. "Are we compliant for 2026?" runs the compliance health check for that year and execution, and the buttons under the answer are built in code, not invented by the model. A question that names a known risk — full-time employees with no offer, missing payroll, affordability, conflicting line codes, incomplete identity, corrections — goes to the same analyzer the health check uses, so the names in the answer match the counts on the dashboard. Filing and printing status are answered per execution, not as an employee list.
The same finding, the same count, in the chat and on the dashboard.
Athena reports the check; the administrator opens the screen and makes the change with its own validation.
With Include employee data ticked and the source not pinned to help, a data question that is not a named risk becomes a guarded query. The model sees only a curated description of the allowed tables — employee, monthly ACA facts, measurement, coverage, penalties, audit rows, covered individuals, report runs and forms, payroll wages and hours, line codes — and must write one read-only statement. Every table and column is checked against that list; rows are capped at 200; the statement is repaired up to three times if it fails; a person named in the question is resolved to a record before anything is written. A question that cannot be answered as a query is answered from help text instead. The answer never shows the query or the physical names.
Live facts without a report, and no way to reach beyond the list.
Named-risk questions never reach this path — they use the analyzer so the counts stay consistent.
In the configuration console the assistant has a second source: the employer configuration documents a consultant uploaded to the Documents library — benefit guides, rate sheets, plan summaries, the client's blueprint. On auto, help text answers first and the documents are the secondary extract. Pinned to employer documents, the extracted documents become the answer source and help text is added only from a stricter search, to define terms without drowning the document. Extracted text is cached for about thirty minutes, so a new upload or a deletion reaches the assistant after that. The same library is what AI-Powered Configuration reads when it proposes configuration rows.
"What did the client say about waiting periods?" is answered from the client's own document.
The library is shared with AI-Powered Configuration — upload once, use for both.
What an administrator can rely on and what an auditor can check — from the assistant as it runs, not from a policy page.
| Rule | How it behaves | Why it matters |
|---|---|---|
| Reads, checks, explains — never changes | No saved screen, no created plan, no re-run execution, no transmitted form, no approval, no correction — and the assistant is instructed never to claim any of these. | A next step is always a link to the screen where a person does it. |
| Approved help is the default source | Answers come from the help text behind the screens' "i" buttons — this screen's rows first, then meaning and keyword search — with matched screens linked. | Improving an answer is editing the help, not tuning a model. |
| Checks run from the question | Configuration and compliance health checks need no checkbox; their domains and tax year are read from the words of the question; their buttons are built in code. | The counts in the chat are the counts on the dashboard. |
| Named risks use the analyzer | Full-time with no offer, missing payroll, affordability, conflicting line codes, incomplete identity, corrections — these never become a free query. | One definition of each risk, everywhere. |
| Lookups are opt-in and guarded | Include employee data must be ticked; one read-only statement; allow-listed tables and columns; at most 200 rows; a named person resolved first. | Live facts without a way to reach beyond the list. |
| Nothing internal in the answer | No table or column names, no query, no full Social Security number, no certificate, token or secret — only that a secret is configured. | Safe to read over a shoulder. |
| Your login is the only identity | The question cannot name another user as its subject; a name in the question is a data filter inside the allow-list, never a login switch. | No impersonation by prompt. |
| Documents are yours to manage | The employer-document source reads the library you maintain; extracted text refreshes within about thirty minutes of a change. | What the assistant quotes is what you uploaded. |
| Different from the employee chatbot | Different panel, different sources, different rules — it cannot act as an employee and does not read an employee's chat. | Two assistants, each scoped to its user. |
Six pieces that turn every "i" button, every check and every allowed lookup into an answer with a link.
The page, screen, tab and form travel with every question; this screen's approved help is retrieved first, then related help for the same form, then the creation screen for a "how do I set up" question.
A deterministic check of the module's configuration by domain — measurement, affordability, filing identity and more — run from the words of the question, with findings and the screens that fix them.
For a tax year and execution: the same analyzer as the dashboard, so named risks — no offer, missing payroll, line-code conflicts, identity gaps — carry the same counts in the chat as on the screen.
Opt-in per question; one read-only statement against allow-listed tables and columns, capped at 200 rows, with a named person resolved to a record first — and nothing internal in the answer.
In the configuration console, pin the assistant to the uploaded benefit guides, rate sheets and memos in the Documents library — the same library AI-Powered Configuration reads.
Each screen offers the questions administrators actually ask there — dashboard, execute, reports, penalties, employees, wages and time — from a maintained question bank, plus a searchable dropdown.
Most administrator copilots are a chat window over a vendor's knowledge base. This one is built from your screens, your checks and your documents — and is fenced accordingly.
| The question | Generic admin copilot | Athena for Admins |
|---|---|---|
| "What does this field mean?" | A general article about the concept. | The approved help behind this screen's "i" button, with the screen linked. |
| "Is my configuration healthy?" | A checklist to read. | A deterministic check run for your tax year, findings listed, fix screens linked. |
| "Who is full-time with no offer?" | Whatever query the model writes. | The same analyzer as the dashboard — same names, same counts. |
| "Was this employee offered coverage in April?" | Depends on what the integration user can see. | Only with the box ticked, one read-only statement, allow-listed tables, 200 rows at most. |
| "Fix it for me." | Sometimes does — via broad integration rights. | Never. Reads, checks, explains; the change is yours to make on the screen. |
| "What did the client's guide say?" | Not available. | Answered from your uploaded documents, with help text only to define terms. |
| "Show me the query." | Often will. | Won't — no query, no table names, no full identifiers, no secrets. |
Benefits Reimagined has three assistants that share a name and a rule — explain, never change — and share nothing else. Athena for Employees answers an employee about their own benefits. Athena for Admins answers an administrator about the screen they are on. AI-Powered Configuration proposes configuration rows from documents for a consultant to approve and commit. Other modules carry their own in-module assistant in the same help-plus-optional-data shape.
The approved "i" text for the page you are on, found by meaning and keyword, with the matched screens linked — no manual, no ticket.
Configuration and compliance health checks are deterministic and shared with the dashboard, so the chat never disagrees with the screen.
Employee lookups are opt-in, read-only, allow-listed and capped — the fastest way to a fact and no way to a change.
In the configuration console the client's own guides and memos become the answer source, with help text added only to define terms.
The assistant never saves, creates, re-runs, transmits or approves — and never says it did. Every change is made on a screen with its own validation and audit.
Built from the platform's own screens and help, so it behaves the same whether the workforce arrives from SAP SuccessFactors or any other HRIS Benefits Reimagined syncs with.
Athena for Admins is a floating panel, not a page. In the ACA module it is on every screen with the checks and the guarded lookup. In the configuration console it is on every screen with the help and the employer-document source, and the Athena Admin menu adds the Documents library it reads and the blueprint where AI-Powered Configuration works. Other modules mount their own assistant in the same shape.
Four questions traced through the flow above — one per kind of answer, each ending on a screen the administrator opens.
An ACA administrator on the measurement screen asks the difference between look-back and monthly measurement. Athena retrieves the approved help for that screen and two related passages, answers in four sentences, and links Employee classes because the method is set per class. No check, no data, no change.
"Is our configuration healthy for 2026?" runs the configuration check across all domains; "Are we compliant for Q3?" runs the compliance check for that execution. Both come back with findings, counts that match the dashboard, and code-built buttons to the screens — with the employee-data box untouched.
With the box ticked, "was Jane Doe offered coverage every month?" resolves Jane to a record, writes one read-only statement against the allow-listed monthly facts, and answers with ten of twelve months and the reason for the gap — no query shown, no identifier printed, and a link to her monthly detail to fix it.
A consultant in the configuration console pins the source to employer documents and asks what the client said about waiting periods. Athena quotes the benefits guide and the eligibility memo from the Documents library, adds the help-text definition of the field, and links the form. The consultant enters the rule herself.
Bring three questions your administrators ask every quarter — a "what does this mean", an "is this configured right", a "which employees". We'll answer them on the screen, run the checks in front of you, and show the guard that keeps a lookup read-only.
Approved help, real checks, guarded lookups and your own documents — explained in plain language, linked to the screen, and never a change you didn't make yourself.