Explore the installed example Check Sets

Note

Use this page after installing the package. It identifies the example metadata that appears in Setup and on Lightning record pages. These records are different from the copyable recipes in the examples library.

The package installs four active Example Check Set records and 50 Example Check records. Forty-nine Checks are active. One original Relationship & Risk Check remains inactive so upgrades do not remove metadata that an existing subscriber may still reference. Their labels begin with Example: and their Developer Names begin with Example_. In an installed package, a Qualified API Name also includes the rhc__ namespace, such as rhc__Example_Account_Check_Builder_Guide.

Use these records to verify a sandbox installation. Create separate Check Sets with names and requirements owned by your organization before using Record Health Check in a business process.

The descriptions below match the examples in this checkout. An installed release can have different rules and order; see version availability before expecting identical results.

Outcome

After this walkthrough, you will have located the installed example Check Sets, connected one to a Lightning record page, and proved that a controlled record change updates the expected result.

Before you start

• Install Record Health Check and assign Record Health Check Card User to the person testing it.
• Add the Record Health Check component to an Account, Contact, or Opportunity record page.
• Use records whose values you are allowed to change in a sandbox.

Example catalog

The tables group the examples by card. For the generated, source-backed list of every shipped Check and its Evaluation Type, use Installed example Checks.

Account

Check Set Developer Name	Card title	Installed Checks
Example_Account_Check_Builder_Guide	Example: Account Check Builder Guide	25 active Checks: 3 Formula, 10 Query, 11 Compare Two Queries, and 1 Apex
Example_Account_Relationship_Risk	Example: Account Relationship & Risk Health Check	9 Checks, 8 active, covering ownership, contact coverage, pipeline, parent alignment, and activity

The Account Check Builder Guide is ordered from Formula to Query to Compare Two Queries, followed by one Apex Check. See Install the demo in a scratch org for the exact 25 Checks, their order, expected outcomes, and demo data. For formulas, queries, and settings, use Account Check Builder Guide: configuration and results.

Dynamic result text

Thirty-four installed Checks use {!rhcResult...} merge tokens in Display: Found Text, Display: Expected Text, or Message When Failed. They are working examples, not placeholder snippets. For example:

• Example: No High-Priority Issues uses the value found and its plural suffix to show “1 open high-priority case” or “2 open high-priority cases.”
• Example: Contacts Have Email Addresses shows the number of Contacts reviewed, the number missing an email address, and the second Contact’s email from {!rhcQuery.sourceRows[1].Email fallback="email not available"}. Its Source Query uses ORDER BY Id, so “second” has a stable meaning. Query-row indexes start at 0, making [1] the second row.
• Example: Average Deal vs Largest Deal inserts the values that the Check compared into Found and Expected.

The first example also uses {!record.Name fallback="This account"} so its message remains clear when the Account name is unavailable.

Open these Check records in Setup to see where each token is saved. Use the merge syntax reference when adapting them to your own Check.

Apex and inline-link example

Example: Verified engagement cadence is the packaged public contract Check. Its AccountHasRecentActivityCheck class declares the two JSON parameters and their bounds, returns typed comparison evidence, and adds display-only guidance with a safe Account link. Its metadata keeps complete fallback message, fix, and action values, including an explicit {!link ...} token, so the Check remains readable if an optional Apex display value is absent or rejected.

Use the demo Accounts to verify both sides of the contract:

Demo record	Expected outcome	Evidence to confirm
RHC Builder Ready	PASS	At least two completed WhatId Tasks/Events in the 60-day window
RHC Builder Needs Review	FAIL	Fewer than two qualifying activities; remediation and Open account are visible
RHC Builder Empty	FAIL	Found is exactly zero and evidence remains present rather than becoming missing

The same two aggregate queries serve one Account or the complete scope. A Contact-only WhoId Task and activity older than the window are intentional negative cases and do not count. Follow the complete recent-activity verification and the public contract for limits and security behavior. The example coverage explains why these two Apex Checks carry the plugin and presentation lessons while unrelated installed Checks remain focused on their own tasks.

Contact and Opportunity

Check Set Developer Name	Card title	Installed Checks
Example_Contact_Relationship_Readiness	Example: Contact Relationship Readiness	8 active Checks: Account context; Title or Department; regional context; Email or Phone; reporting line; email without a bounce; active owner; recent Task
Example_Opportunity_Deal_Readiness	Example: Opportunity Deal Readiness	8 active Checks: Account context; active owner; positive amount; current close date; non-placeholder Next Step; probability aligned with deal state; primary buyer contact; recent activity

Step 1: Inspect an example in Setup

1. In Setup, open Custom Metadata Types.
2. Next to Record Health Check Set, select Manage Records.
3. Open one of the records whose label begins with Example:. Note its Developer Name, Base Object API Name, and Card Title.
4. Return to Custom Metadata Types. Next to Record Health Check, select Manage Records.
5. Open a record whose label begins with Example: and confirm that Check Set points to the example you selected.
6. Review Evaluation Type, the evaluation settings, Pass Message, and Fix Message.

Step 2: Prove the installation

1. Open a record for the example’s base object.
2. If When Checks Run is When the user clicks Run, select Run.
3. Confirm that the card displays rows rather than setup guidance.
4. Change one safe sandbox field used by the example and run it again.
5. Confirm that the affected row changes as expected.

The result can be Pass, Failed, Warning, Info, Skipped, Unable to Check, or System Error depending on the record and Check severity. Use Read Record Health Check results to translate the card label into the programmatic status.

Lightning App Builder selects only the Check Set. Run timing, summary placement, and Run/Rerun presentation come from that Check Set’s Custom Metadata fields.

Resolve verification issues

If no example appears in Lightning App Builder, confirm the installed package version and refresh the builder. If the card shows setup guidance, confirm the record object’s API name matches the Check Set and that the user has Record Health Check Card User. For an Unable to Check or System Error result, enable Show Diagnostics on the Check Set and use Record Health Check Diagnostics Viewer alongside Card User or User. Admin already includes diagnostic access. Follow Troubleshoot with Show Diagnostics.

Installed metadata versus documentation recipes

Source	Already in the org?	Intended use
The four Check Set records on this page	Yes, after package installation	Verify installation and inspect working metadata; use the example for the same Salesforce object as the record page
Pages under docs/examples/	No	Copy a pattern and adapt it to an approved business requirement
Apex class AccountHasRecentActivityCheck	Yes	Demonstrate a packaged custom Apex Check
Strategic readiness and open opportunity health Apex classes	No; test fixtures only	Developer examples that require review, deployment, and tests

Next steps

• Install and verify
• Create your first Check
• Examples library
• Configure Check Sets and Checks