Examples
Examples you can copy
Detailed page. Use “On this page” to jump directly to the section you need.
Choose an Evaluation Type and a complete example that matches the Salesforce requirement you want to check.
Use these examples to build a health check for a Salesforce record. Each example starts with a business question, explains which Evaluation Type fits, lists the Setup values, and shows how to test the result.
Examples change only when a release capability improves the business story they teach. Runtime fixes, deliberately invalid configurations, and specialized API/security behavior use the existing example, an integration-only fixture, or a focused walkthrough instead of being added to every Check. See Example coverage for the current decisions and verification data.
You do not need to read every page. Choose the row closest to your requirement, create a Check from the example values, and replace its fields, limits, and messages with values approved for your org.
The pages in this library are instructions, not metadata installed in your org. The installed
package includes four Check Set records and 50 Check records whose names
begin with rhc__Example_. Other examples exist only in these documentation pages unless an
administrator creates them.
Unless a page states otherwise, its Check Set shows a Run button with the utility:play icon
and changes the button label to Rerun after the first run. The configuration tables give the
exact field values.
Not installed yet? Finish Install and verify first, then return here. Use an example Check Set included with the installed package for the first sandbox test. Create a new Check Set for your org before adapting a documentation example.
Choose the right Evaluation Type
Section titled “Choose the right Evaluation Type”Start with where Salesforce stores the information needed to decide whether the record passes.
| What do you need to check? | Use | Good first example |
|---|---|---|
| Fields on the current record or a parent record | Verify with a formula | Seller research readiness |
| Related records, such as Contacts, Opportunities, or Cases | Verify with a query | Customer handoff |
| Whether the results of two queries match or overlap | Compare two queries | Opportunity Contact Role coverage |
| A decision that requires custom code | Verify with Apex | Recent Account activity |
Start with a formula when possible. Move to a query when the answer depends on related records. Use Apex only when the other Evaluation Types cannot express the business decision clearly.
How to use an example
Section titled “How to use an example”- Open an example that resembles your business requirement.
- Read Why use this Evaluation Type to confirm why the example uses Formula, Query, Compare Two Queries, or Apex.
- Create the Check Set first when the example requires a new one. In Setup, go to Custom Metadata Types → Record Health Check Set → Manage Records.
- Create the Check. In Setup, go to Custom Metadata Types → Record Health Check → Manage Records and copy the values from Configure the Check.
- Replace the sample fields, limits, and messages with values that match your org’s requirement.
- Add the Record Health Check component to the correct Lightning record page if it is not already present. Select the Check Set, save, and activate the page as Org Default, App Default, or for the intended app, record type, and profiles.
- Assign Record Health Check Card User to the test user and confirm that the Check Set Object matches the Lightning record page object.
- Follow Test the Check and confirm the documented passing, failing, skipped, or error results that apply before making the Check available to users.
utility:play is a standard Lightning icon name that you paste into Run Button Icon; it is not
a file upload. Tables can show API values such as ALL_ROWS_PASS beside their Setup labels so
developers can identify metadata, but administrators should select the visible Setup label.
The technical reference lists every setting, operator, limit, and result rule. Use an example when creating a Check. Use the reference when the example does not cover a setting you need.
Formula examples
Section titled “Formula examples”Choose Verify with a formula when the Check can read everything it needs from the current record or a parent relationship. A formula is usually the simplest option and does not require Apex.
| Example | What it checks | What you will learn |
|---|---|---|
| Seller research readiness | An Account has a Phone or Website | Allow either of two fields to satisfy a Check |
| Billing address review | Required billing-address fields are populated | Require several fields together |
| Partner regional assignment | Partner Accounts have regional-assignment information | Run a Check only for matching records |
| Branch handoff | A branch has the headquarters information needed for handoff | Read a parent record and link users to it |
| Small-business program eligibility | Employee count meets a program limit | Compare a number and explain the found and expected values |
Query examples
Section titled “Query examples”Choose Verify with a query when the answer depends on related Salesforce records. One query can return a count, a field value, or a list for the Check to evaluate.
| Example | What it checks | What you will learn |
|---|---|---|
| Customer handoff | An Account has at least one Contact | Compare a related-record count with a minimum |
| Pipeline next steps | Every open Opportunity has a Next Step | Require every returned record to pass |
| Meaningful pipeline | At least one open Opportunity meets an Account-specific amount | Compare query results with a value from the current record |
| Forecast amounts | Every open Opportunity has an Amount greater than zero | Evaluate numbers and handle empty values |
| Placeholder email cleanup | Contact emails do not use a placeholder domain | Check text returned by a query |
| Account Owner team membership | The Account Owner is also an Account Team member | Find a current-record value in a related-record list |
| Case review capacity | The high-priority Case backlog stays within a limit | Compare a related-record count with a maximum |
Compare-two-queries examples
Section titled “Compare-two-queries examples”Choose Compare two queries when both sides of the decision come from related records. The Check can compare two counts or determine whether two lists match, contain the same values, or overlap.
| Example | What it checks | What you will learn |
|---|---|---|
| Opportunity Contact Role coverage | Every open Opportunity has a Contact Role | Compare two related-record counts |
| Open-pipeline product continuity | Open pipeline includes a previously purchased Product | Check whether two lists share a value |
| Account Team coverage | The Account Team includes every open Opportunity Owner | Check whether one list contains every value from another list |
Apex examples
Section titled “Apex examples”Choose Verify with Apex when the Check needs calculations, several steps, or Salesforce behavior that the other Evaluation Types cannot express clearly. Apex examples require development and test coverage before deployment.
AccountHasRecentActivityCheck is included in the namespaced unlocked package. The strategic-readiness and
open-opportunity classes are source-development recipes unless your team reviews, tests, and
deploys them.
| Example | What it checks | What you will learn |
|---|---|---|
| Recent Account activity | An Account meets a recent WhatId Task/Event cadence | Exercise typed parameters, per-record recovery, evidence, display overrides, and inline links with positive and negative data |
| Open Opportunity health | An open Opportunity does not have several warning signs at once | Apply several conditions to the same related record |
| Strategic Account readiness | A Strategic Account meets a weighted readiness score | Calculate and explain a configurable score |
What makes each example different
Section titled “What makes each example different”Each example teaches a different Record Health Check feature. Examples can use the same Salesforce object without repeating the same configuration pattern.
| Example | Feature demonstrated |
|---|---|
| Seller research readiness | Formula OR, optional alternatives, and an edit action |
| Billing address review | Formula AND with display-only Found and Expected formulas |
| Partner regional assignment | Formula applicability, SKIPPED, and count-only display for passed Checks |
| Branch handoff | Parent relationship fields and a parent-record action URL |
| Small-business program eligibility | Numeric Formula comparison with Found/Expected visible on every result |
| Customer handoff | Aggregate COUNT() compared with a fixed minimum |
| Pipeline next steps | ALL_ROWS_PASS, Is not empty, no-row SKIPPED, and empty-field failure |
| Meaningful pipeline | ANY_ROW_PASSES compared with an Account formula and formula applicability |
| Forecast amounts | Numeric ALL_ROWS_PASS with result-summary merge tokens |
| Placeholder email cleanup | Text exclusion, ignored blank fields, and a prerequisite Check |
| Account Owner team membership | Query list-membership mode using a record formula and Comparison Query |
| Case review capacity | Aggregate upper limit plus optional Check Result and Check Set Run lifecycle events |
| Opportunity Contact Role coverage | Aggregate alias, two-query equality, and count-query applicability |
| Open-pipeline product continuity | Two lists compared with Lists overlap |
| Account Team coverage | Two lists compared with Lists contain all and no-row failure |
| Recent Account activity | Apex across Task and Event with a limited date range configured in JSON |
| Open Opportunity health | Apex applying several conditions to each related record plus count-query applicability |
| Strategic Account readiness | Weighted Apex score, multiple JSON parameters, and formula applicability |
The reference pages document additional operators and limits that do not need separate examples.