CORES HAN is a real, substantial public-health alerting product with a full help center, but the docs are riddled with reused boilerplate from other Juvare tools, a role/permissions model that contradicts itself across five pages, multiple half-rendered pages, and an authoritative permissions matrix whose per-role indicators render as blank cells. The result is a doc set where the single most important question — "who can do what" — has a different answer depending on which page you open.
1. The Publisher role page omits the one capability that defines a Publisher (critical)
Location: /cores_han/cores/publisher.htm
Problem: The Publishers role page lists only view capabilities: "View the Contact Us and home page / View and update your own profile / View the Accounts page / View account profiles (name and email address only)." It never states that Publishers can send notifications. Yet about-permissions.htm says "a user is assigned the Publisher role... This means the user can send notifications in both organizations," the Quick Start Guide says "Confirm you have Publisher permissions to create and send notifications," about-groups.htm defines shared group access as "permissions... that correspond to the default Publisher role," and the landing card describes Publisher tasks as "viewing and publishing notifications."
Consequence: A reader who lands on the canonical Publisher page concludes a Publisher is a read-only viewer and cannot send alerts — the exact opposite of the role's purpose in an emergency-notification system. This is the page an admin would consult to decide whether to grant someone publishing rights.
The fix: Add the defining capabilities to publisher.htm — Publishers can create, draft, template, and send notifications — and reconcile it against the Solution Permissions matrix so all four pages agree.
2. The authoritative Solution Permissions matrix renders its per-role indicators as blank cells (critical)
Location: /cores_han/cores/permissions-matrix.htm
Problem: The matrix is repeatedly cited as the source of truth ("For a list of all actions... refer to the Solution Permissions page"), but every per-role indicator cell renders blank in the extracted text — the Yes/No-style indicators are icon/image-only with no text equivalent. Only a handful of footnote qualifiers render as text (e.g., "(name and email address only)", "(within their organization)", "(only those created by them)", "(only for their organization)"), and those sit in otherwise-blank rows. So for actions like "Send notifications," "Manage notifications," and "View reports," the grid conveys nothing about which roles are allowed. The table also contains a duplicate "View reports" row at the very bottom, and its columns mix system roles (Client Admin, Local Admin) with organization roles (Administrator, Publisher, Recipient) in one header.
Code verification
Runtime snippet checks
Run the public examples from this audit in an isolated sandbox and attach the pass, fixed, skipped, and failed counts to the report.
Consequence: Any AI coding/support agent parsing the page sees rows of empty cells — the single most important reference in the docs is unindexable, and a reader can't tell an "allowed" cell from a "denied" cell from a footnoted exception. If the indicator icons also lack alt text, screen-reader users get nothing at all from the matrix.
The fix: Add text or alt equivalents to every indicator cell (e.g., "Yes / No / Conditional"), remove the duplicate View reports row, and clarify in the header that columns combine system and organization roles.
3. The role taxonomy is incompatible across the System Roles page, the role pages, and the matrix (critical)
Problem: The canonical System Roles table defines five system roles: Contact, Regular User, Local Admin, Client Admin, Juvare System Admin — and says "Juvare System Admin... is only for Juvare Staff... and should appear as Inactive." But the role-specific pages document Publisher, Recipient, Organization Admin, and System Admin — none of which appear in the System Roles table. about-permissions.htm then reclassifies Publisher and Organization Admin as organization roles, while the matrix columns list both "Local Admin" (system) and "Administrator/Publisher/Recipient" (org) side by side. The system-admin.htm page is titled "System Administrator" and nav-labeled "Help for System Admins (Client and Local)," even though System Roles reserves "System Admin" for inactive Juvare staff.
Consequence: There is no consistent vocabulary for roles. An admin trying to map "the Publisher I created" to a permission set cannot, because Publisher isn't in the system-role table and "System Admin" means a customer admin on one page and a Juvare-staff-only inactive account on another. This is the core access-control model of an emergency product.
The fix: Pick one canonical taxonomy, define system vs. organization roles in one table, and make every role page and the matrix use those exact labels (e.g., stop using "System Admin" to mean both a customer role and the reserved Juvare-staff role).
4. Home/navigation docs describe "missions" and "volunteers" that don't exist in this product (significant)
Problem: The Navigate page's Home row reads: "The homepage provides quick access to your missions and announcements. As a volunteer, your homepage allows you to join missions. As an administrator, your homepage allows you to manage missions." But key-concepts.htm describes Home purely as "read announcements, access your notifications, and navigate to other pages" — no missions, no volunteers. The landing page's System Admins card likewise advertises "managing missions and time tracking," and key-concepts even ends with notifications "to plan for and respond to missions." None of "missions," "volunteers," or "time tracking" is a documented CORES HAN feature anywhere else.
Consequence: Two pages give contradictory descriptions of the same home page. A new user reads "join missions"/"manage missions"/"time tracking" and goes hunting for features that don't exist in this notification product — clearly boilerplate leaked from another Juvare solution. It erodes trust in the entire doc set.
The fix: Purge the missions/volunteers/time-tracking boilerplate from navigating-cores-han.htm, the landing System Admins card, and key-concepts.htm, and replace it with the notifications/announcements language the rest of the docs use.
5. Product name renders as a fused string "CORES HANJuvare Alerts" (significant)
Location: /cores_han/cores/how-do-i.htm
Problem: The intro reads: "Commonly referenced topics in the CORES HANJuvare Alerts Help Center." Two product names are concatenated with no space — a hallmark of an unresolved template variable or snippet. The product is named "CORES HAN" everywhere else; "Juvare Alerts" appears nowhere else in the docs.
Consequence: Readers can't tell whether they're in the right help center, and it signals the page is rendering a broken variable. Agents indexing the page may treat "Juvare Alerts" as a distinct product.
The fix: Resolve the snippet to the single correct product name and audit the rest of the site for the same unrendered variable.
6. Browser-support requirements contradict each other across three pages (significant)
Problem: Troubleshooting tells users to use "the latest version of Chrome or Edge" (two browsers). The login/error wall says "Please use the latest version of Chrome, Firefox, Safari, or Edge" (four browsers). The Trademarks page registers Safari, Firefox, Chrome, and Internet Explorer as referenced browsers.
Consequence: A Firefox or Safari user reading Troubleshooting concludes their browser is unsupported and may switch unnecessarily; an IE reference implies legacy support that Troubleshooting contradicts. For an emergency tool, "is my browser supported?" needs one answer.
The fix: Publish one supported-browser list and reference it from Troubleshooting, the login wall, and any trademark/legal text; drop Internet Explorer if it's unsupported.
7. Multiple help pages end mid-content with dangling headings, missing media, and stray fragments (significant)
Problem: org-admin.htm ends with "Organization Admin workflow:" followed by nothing. system-admin.htm ends with "System Admin workflow:" and nothing. The auth page ends with "Next Steps... continue with the following pages in this section:" and lists no pages. whats-new-in-help-centers.htm promises "This video provides an overview..." and "This video demonstrates the steps below" but renders no video and no steps (and prints the two sentences twice). submit-product-feedback.htm ends with the stray, content-less fragment "Your search for returned result(s)." — an unrendered template artifact.
Consequence: Core onboarding and auth pages stop exactly where the actionable content should begin — readers see a promised workflow diagram, next-steps list, or video that never appears, with no way to know whether it's missing or just hasn't loaded.
The fix: Either supply the missing diagrams/links/videos or remove the orphaned headings and stray fragments so pages don't advertise content that isn't there.
8. The Support page contradicts its own landing card and contains no way to contact support (significant)
Problem: The landing "Juvare Support" card promises "Create a support ticket, send us an email, or call our team for technical assistance." The destination page contains no ticket link, no email address, and no phone number — just "If you need technical assistance, please contact your administrator or Juvare Support," printed verbatim twice.
Consequence: A user in an active incident clicks "Support" expecting a ticket form, email, or phone number and gets a circular sentence pointing back to "Juvare Support" with no contact mechanism. The page fails at its only job.
The fix: Add the actual ticket URL, support email, and phone number to the destination page, and de-duplicate the repeated sentence.
9. The "How Do I...?" hub has empty category prompts with no links (significant)
Location: /cores_han/cores/how-do-i.htm
Problem: The "How Do I...?" page is structured as category prompts, each followed by a list of links. Three of the six categories have a prompt but no links beneath them: "Find information about notifications and announcements?", "Find information about Organizations?", and "Find information about the File Library?" — while sibling categories (user accounts/permissions, Groups, configuration/settings) each list multiple working links.
Consequence: Notifications, Organizations, and the File Library are central CORES HAN features, yet the primary "how do I" navigation hub offers no path to any of them — a Publisher who lands here looking for how to send a notification finds an empty heading. This compounds the dead Delivery Statuses / CSV references (Findings 10/11): there is no route to notifications or File Library guidance from this hub either.
The fix: Populate the three empty categories with links to the relevant notifications, organizations, and File Library topics (or remove the empty prompts until the targets exist).
10. Quick Start cross-references and the CSV template are plain text, not links (significant)
Problem: The guide tells users to "refer to Delivery Statuses" to interpret "Created / In Progress / Delivered / Failed," but "Delivery Statuses" appears as plain text with no href, and no Delivery Statuses page is reachable in the docs. It also instructs "download the provided CSV template" with no download link, and references a "Template" that is never linked. The only working body link is "Notification." (This finding targets the broken links; Finding 11 targets the missing content behind them — they call for different fixes, not the same one twice.)
Consequence: A Publisher following the primary getting-started path hits a dead end: they're told to download a CSV template with no link and to consult a Delivery Statuses reference that has no link and may not exist. The external-recipient upload flow — central to reaching people without accounts — can't be completed from the docs.
The fix: Hyperlink "Delivery Statuses" to a real status-reference page (and create it if missing), attach the actual CSV template download, and link "Template."
11. No documented error codes or delivery-status reference for failed notifications (significant)
Problem: Troubleshooting is the only page covering delivery failures, and it lists causes in prose only ("Delivery may fail due to missing or incorrect contact information," "external email handling, invalid contact details, or blocked messages") with no specific error codes, status strings, or messages. The Quick Start references statuses "Created / In Progress / Delivered / Failed" and points to a "Delivery Statuses" topic that is never linked or documented. (Where Finding 10 asks for the link to be created, this finding asks for the underlying reference content to exist at all.)
Consequence: When an alert fails to reach recipients, a Publisher has no enumerated list of statuses or error conditions to diagnose against — only vague "may fail due to" prose. For a public-health alerting system, undiagnosable delivery failure is a serious operational gap.
The fix: Publish a Delivery Statuses reference enumerating every status and failure reason (with the exact strings the UI shows) and link it from Troubleshooting and the Quick Start.
12. Invalid/old help URLs surface as a login wall instead of a help-styled 404 (significant)
Location: /cores_han/cores/navigate.htm (redirects to /secure/cores_han/alert?type=PageNotFound)
Problem: The plausible path navigate.htm (the real page is navigating-cores-han.htm) does not 404 — it redirects to a "Secure Login" screen, as do guessed paths cores/system-roles.htm and cores/solution-permissions.htm. That login wall also advertises a different supported-browser list (four browsers) than the docs themselves.
Consequence: A user following an outdated link or bookmark is dumped onto a login screen with no indication the page moved — it looks like a permissions/auth problem, not a broken link. Search engines and agents indexing stale URLs hit a login wall instead of a redirect to the new page.
The fix: Return a proper help-center 404 (or a 301 to the renamed page) for unknown doc paths instead of redirecting public help content to a secure-login screen.
13. SSO and Ideas-Portal auth flows are missing question stems and password/SSO steps (significant)
Problem: Under "SSO Admin FAQs," answers appear with no questions — e.g., "Yes, SSO will only apply to your organization-specific email domain..." and "Juvare supports two authentication methods: OpenID Connect (OIDC) and SAML 2.0" float without the question they answer. In the Ideas Portal login steps, step 2 and step 4 both say "enter the email address associated with your Juvare Login Services account," with no password, SSO redirect, or MFA step shown between them.
Consequence: Admins evaluating SSO setup get disconnected answers with no questions to anchor them, and a user following the Ideas Portal steps enters their email twice and never sees where authentication actually happens — the documented flow is impossible to follow literally.
The fix: Restore the FAQ question stems, and rewrite the Ideas Portal login steps to show the real auth step (password/SSO/MFA) between the two email prompts.
14. Release notes skip version 6.5 while claiming two years of coverage (minor)
Problem: The index states releases cover "the past two years," then lists 6.13, 6.12, 6.11, 6.10, 6.9, 6.8, 6.7, 6.6 and jumps straight to 6.4, 6.3, 6.2, 6.1 — there is no 6.5 entry.
Consequence: A user tracking changes for a specific release can't find 6.5 and can't tell whether it was skipped in numbering, never released, or simply has a missing page.
The fix: Add the 6.5 release notes or add a one-line note explaining why 6.5 is absent.
15. Duplicated content and an orphan term ("Ad Hoc Alerts") across notification pages (minor)
Problem: The about-notifications body is nearly identical to the Notifications section of key-concepts.htm (same definition, same delivery-method list). The page's subtitle/meta calls these "Notifications or Ad Hoc Alerts," but "Ad Hoc Alerts" appears nowhere in the body or anywhere else in the docs.
Consequence: Readers re-read the same definition on two pages, and the orphan "Ad Hoc Alerts" term suggests a synonym the product may use, with no definition to confirm it.
The fix: Consolidate the duplicated definition into one canonical page and either define "Ad Hoc Alerts" or remove it.
16. Two training courses share identical bullet content with near-identical intros (minor)
Location: /cores_han/video-library.htm
Problem: "CORES HAN Local Administrator Training" and "CORES HAN Client Administrator Training" differ only by a single word in their intro sentence ("training local administrators" vs. "training client administrators"); the four content bullets beneath each are word-for-word identical ("Manage the registration process, as well as accounts, organizations, and groups. Send and manage notifications. Manage the File Library. Use Admin Reports.").
Consequence: A user can't tell how the two courses differ or which one fits their role — the very role distinction the courses are meant to teach — because the only difference is one word in the heading sentence.
The fix: Differentiate the bullet content to reflect what Client vs. Local Administrator training actually covers.
17. Branding inconsistencies: CORES™ vs CORES HAN, stale Twitter mark, and a typo (minor)
Problem: The trademark list registers "CORES™" (not "CORES HAN," the product name used throughout) and still lists "Twitter® and Tweet®" — stale branding given Twitter's rebrand to X. Get Started contains the typo "links to find our more" (should be "find out more").
Consequence: Minor, but the mismatched product mark and stale Twitter trademark make the legal/trademark page look unmaintained, and the typo appears on a high-traffic navigation hub.
The fix: Align the trademark entry with the "CORES HAN" product name, verify whether the live site still uses Twitter branding and update the mark accordingly, and fix the typo.
What they do well
The permissions concept page (about-permissions.htm) clearly explains the two-tier system-role/organization-role model with a concrete worked example, even though the role pages don't live up to it.
Key Concepts and the Groups page give clear, example-driven definitions (parent/child organizations, standard vs. filter-based groups, sharing permissions) that are genuinely useful.
Release notes are organized per-version with individual pages and a stated coverage window, giving users a real change history to reference.
Top 3 recommendations
Fix the access-control model first. Reconcile publisher.htm, the System Roles table, the role pages, and the Solution Permissions matrix into one consistent role taxonomy, and give the matrix text/alt equivalents so its per-role indicators are readable by agents and screen readers.
Purge cross-product boilerplate. Remove every "missions," "volunteers," and "time tracking" reference from this alerting product's pages so the home-page and System Admin descriptions match what CORES HAN actually does.
Finish the half-rendered pages and dead links. Supply the missing workflow diagrams, next-steps lists, support contacts, CSV template, Delivery Statuses reference, and the empty "How Do I...?" categories — and return proper 404s/redirects for stale doc URLs instead of a login wall.