> ## Documentation Index > Fetch the complete documentation index at: https://docs.fusioncore.us/llms.txt > Use this file to discover all available pages before exploring further. # Health Checker > Define and run configurable checks against your org's data and configuration, on demand or on a schedule. ## Overview "Health Checker" is also **two separate packages** installed together, the same pattern as [Transaction Generator](/end-user-guides/accelerators/transaction-generator): 1. **fusionSpan Health Checker** (the base package, managed, namespace `FSPHC`) is the generic engine. It defines the `Health Check Item` and `Health Check Result` objects and the logic that runs a check — a Salesforce report, a SOQL query, or a custom Apex class — and compares the row count against an expected value. It ships with **zero checks configured**. 2. **fusionCore Health Checker AddOn** (unmanaged, no namespace) is what makes it useful for a fusionCore org. It contributes 94 pre-built checks — 75 backed by bundled Reports, 12 backed by fusionCore-specific Apex classes, and 7 plain SOQL queries — covering Commerce, Subscriptions, Communities, and Stripe data. Without this add-on, the base package has nothing to run. Both packages need to be installed for a useful check library to exist. If your org only has the base package, confirm the add-on has also been installed — see [fusionCore's Pre-Built Checks (Add-On)](#fusioncores-pre-built-checks-add-on) below. ## Prerequisites * Assign the **Health Check** permission set to any admin who will configure or run checks. Neither package ships any other permission set — the add-on's checks, Reports, and Report Types rely on this same base permission set for access. ## How to Configure Go to **Setup → Custom Metadata Types → Health Check Item → Manage Records → New**. Choose a `Type` — **Report**, **SOQL Query**, or **Apex Class** — and fill in the matching source field (`Report_Name__c` must exactly match a report's Name; `SOQL_Query__c` for a query; `Apex_Class__c` for a class implementing the `iHealthCheckItem` interface). A validation rule blocks saving until the matching source field is filled in. Set `Rows_Expected__c` (the baseline count), then choose an `Error_Condition__c` and/or `Warning_Condition__c` (`=`, `>`, `<`, `>=`, `<=`) that the returned row count is compared against. The Error condition is checked first; if it doesn't match, the Warning condition is checked; if neither matches, the result is Success. Set `Sequence__c` to control run order among your checks, write a short `Guidance__c` note describing the ideal outcome, and check `Active__c` — only active checks run. Open the **Health Check** app. Its home page embeds a screen flow that runs all active checks and shows a pass/fail summary. A checkbox on that flow, "Check to delete all previous health check results," is checked by default — see Limitations before running it if you want to keep history. Open a **Health Check Result** record to see what a check actually found: `Status`, `Rows Returned` vs `Rows Expected`, the generated `Message`, and the `Guidance` text you wrote for that check. A Health Check Result record with Status, Rows Returned, and Message highlighted in a red box, showing an Error because a report returned 2 unexpected rows Schedule the packaged `HealthCheckScheduleable` class from **Setup → Apex Classes → Schedule Apex**. Neither package installs a scheduled job or recommends a run time — pick a frequency and time that suit your org (many teams choose an off-peak, low-traffic window). Whether a scheduled run also deletes prior results is controlled by the `Delete_results_scheduled__c` checkbox on the `Health_Check_Setting__mdt` settings record. ## fusionCore's Pre-Built Checks (Add-On) Installing the fusionCore Health Checker AddOn deploys 94 `Health Check Item` records, all active immediately, split across three check types: | Type | Count | What it looks for | | ---------- | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Report | 75 | A bundled Report (organized into four report folders — Commerce, Communities, Stripe, and Subscriptions Health Check Reports) returning more rows than expected. For example, "Business Units without GL Accounts" errors if that report returns any rows at all. | | Apex Class | 12 | A fusionCore-specific Apex class doing a comparison a report or plain SOQL query can't express (see the list below). | | SOQL Query | 7 | A query embedded directly on the check record — for example, active `Order` records whose next installment date has already passed, or a Subscription Plan with no default Pricebook. | Every one of the 94 checks is a **zero-rows-expected** data-integrity check — each one treats any row returned as an Error, not a Warning. None of them distinguish a "getting worse" state from a hard failure. The 12 Apex-backed checks: | Check | What it flags | | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Financial Event Lines mislinked to Financial Periods | A Financial Event Line linked to a non-Closed Financial Period whose Financial Event succeeded outside that period's date range | | Installment/balance-due mismatch | An Order's total balance due not matching the sum of its pending or failed installments | | Order Items not matching their Financial Event Lines | Order Product transaction fields that disagree with their linked Financial Event Lines | | Order Items without Financial Event Lines and wrong amounts | Order Products with a non-zero transaction amount but no linked Financial Event Line | | Orders not matching their Financial Events | Order transaction fields that disagree with their linked successful Financial Events | | Orders without Financial Events and wrong amounts | Orders with a non-zero transaction amount but no linked Financial Event | | Community Member with mismatched dates | A Community Member's dates that don't line up with its Community Position's dates (this check depends on the separate Committees package) | | Payment Provider Accounts with wrong payment types | Stripe Payment Types offering direct-only payment methods (Alipay, WeChat Pay) on an org without a direct Stripe connection | | Inactive Order/Opportunity with inactive Subscription Plan | An Order or Opportunity tied to a Subscription Plan that's no longer active | | Renewal Purchase Activity missing Order or Product | A renewal-generated Purchase Activity whose renewal-days configuration is missing or inconsistent | | Subscription Purchase Activity missing renewal | An active or expired Purchase Activity with no renewal Order or Order Product | | Subscription product without default Pricebook Entry | A subscription product missing the default Pricebook Entry its Subscription Plan needs | ## Limitations and Common Pitfalls * **The fusionCore add-on's checks all activate the moment it's deployed.** All 94 come in with `Active__c = TRUE` — there's no staged rollout. Deploying the add-on to an org that's missing one of the fusionCore packages its checks query (Subscriptions, Stripe, or the separate Committees package for the Community Member check) causes those checks to error or fail to deploy — confirm the relevant packages are installed first. * **The "delete previous results" option is global, not per-check.** Both the on-demand flow (checked by default) and a scheduled run configured to delete results wipe **every** prior `Health Check Result` record, not just the ones from the check you're re-running. Uncheck it if you want to keep a history. * **All active checks run in a single transaction.** A large or growing library of checks can hit Salesforce's per-transaction limits on SOQL queries or synchronous report runs, failing the whole run rather than just one check. One of the add-on's Apex checks (Financial Event Lines mislinked to Financial Periods) explicitly stops early and under-counts instead of throwing once it nears the SOQL query limit; the others don't have that same guard, so on a large org they're more likely to fail outright than under-count quietly. * **Report checks match by exact report Name.** A renamed or missing report fails that check with a logged error rather than blocking configuration up front — if a check keeps returning an error, verify the report name first. This is a real risk with the fusionCore add-on's 75 bundled Report checks specifically: nothing enforces that a Report Name and its check record stay in sync if either is renamed later. * **Report checks are capped by Salesforce's report row limits**, so a check against a very large report may under-count. * **A check with no conditions configured always reports Success**, regardless of the row count returned — an all-green result doesn't necessarily mean everything was actually checked correctly. Make sure Error/Warning conditions are set before trusting a check's status. * **A failed check doesn't stop the run.** Other checks still execute; read the individual check's message to see what actually went wrong rather than assuming a Warning/Error status always reflects the row count shown.