Salesforce terms starting with H

A half-life in Salesforce is the time-decay rule that lowers an idea's popularity ranking as its supporting votes age. It is a setting under Setup, Ideas Settings, that controls how quickly older ideas drop on the Popular Ideas subtab so newer ideas with recent votes can surface. The value is entered in days, and it applies across every zone in the org. The same idea of a half-life also shows up in Salesforce Knowledge, where an article's average rating shifts over time so old votes do not keep a stale article artificially high or low. Both uses share one principle: recent activity should count for more than activity from long ago. The Ideas Half-Life field is the version most admins set by hand, so this entry focuses there and notes the Knowledge behavior alongside it.

A hallucination is a confident, plausible-sounding output from a generative AI model that is factually wrong, fabricated, or unsupported by the model's grounding data. In a Salesforce context, the term refers to an Einstein Generative or Agentforce response, summary, or action that looks correct in the user interface but contradicts the underlying customer record, knowledge article, or policy. The model is not lying or guessing in the human sense. It does not have a way to know that it does not know. Generative models hallucinate because their training optimizes for fluent next-token prediction, not for factual accuracy. Without explicit grounding (retrieval from authoritative data) and guardrails (validation, confidence thresholds, citation requirements), a model fills missing context with statistically likely text rather than verified content. Hallucinations are the single largest enterprise blocker for AI rollout in Salesforce orgs. Trust collapses the first time an agent confidently quotes the wrong entitlement to a customer, and rebuilding that trust takes months.

Handoff in the Salesforce context refers to the structured transition of a record (a Lead, an Opportunity, a Case, or an Order) from one team or role to another, with the receiving team picking up the work where the previous team left off. The concept is generic across the platform: SDR-to-AE lead handoffs in sales, sales-to-service post-sale handoffs, tier-1-to-tier-2 case escalations, and presales-to-implementation engineering handoffs all share the same pattern. Salesforce does not ship a single Handoff feature; it provides a set of building blocks (Queues, Assignment Rules, Approval Processes, Flow Orchestration, Path, Chatter, and the Conversation Insights features in Service Cloud) that admins assemble into a handoff workflow. A typical handoff combines four ingredients: a record-level signal that triggers the handoff (a Stage change, an SLA breach, a custom button), a reassignment action that updates the OwnerId or the Owner field to the receiving team or queue, a notification to the receiving team via email, Chatter, mobile push, or Slack, and a context-capture mechanism that documents what the previous team did so the receiving team can pick up cold. The Handoff term is also used heavily inside Salesforce Industries (Health Cloud patient handoffs, Financial Services Cloud advisor handoffs) where the receiving team needs more structured context than a simple owner change provides.

A Hardware Security Module (HSM) is a tamper-resistant physical device that generates, stores, and uses cryptographic keys without exposing the key material to the surrounding software. In the Salesforce context, HSMs are the foundation of Shield Platform Encryption's customer-controlled key options: when a customer uses Bring Your Own Key (BYOK) or Cache-Only Key Service, the master key material typically originates from and resides in an HSM operated by the customer. The HSM signs key operations rather than exposing the key itself, which provides the strongest available guarantee that keys cannot be extracted or copied. HSMs come in several form factors. Network-attached appliances (Thales Luna, Utimaco SecurityServer) sit in customer data centers and serve key operations to applications through a network protocol. Cloud HSMs (AWS CloudHSM, Azure Dedicated HSM, Google Cloud KMS HSM) provide the same capabilities as a managed service. Most Salesforce customers using BYOK or Cache-Only Key Service rely on cloud HSMs because the operational simplicity outweighs the marginal control improvement of self-operated hardware.

Health Check is the Salesforce Setup feature that grades an org's security configuration against a baseline of recommended settings and produces a numeric score from 0 to 100. The score reflects how many of the platform's security settings (password policies, session settings, certificate management, network access, sharing rules, login flow controls) align with the Salesforce-recommended Standard Baseline. A score above 80 percent is healthy. A score below 50 percent indicates significant misconfiguration. The page lives at Setup, Security, Health Check. Health Check is not an audit log or a forensics tool. It is a configuration assessment. The platform compares the current org settings against the baseline, flags each setting as Compliant, At Risk, or High Risk based on its deviation, and surfaces a Fix Risks button for each. Admins can also import Custom Baselines for industry-specific frameworks (NIST CSF, HIPAA, PCI DSS), giving compliance-driven organizations a more tailored target than the Salesforce default. The score is a single-number snapshot of the org's security posture.

Health Cloud is Salesforce's industry-specific product for healthcare and life sciences. It extends Salesforce CRM with healthcare-specific data models, workflows, and integrations: patient and member 360 views, care plan management, clinical data integration, provider network management, payer-specific workflows, and life-sciences scenarios like clinical trial management. Health Cloud is licensed separately from base Sales Cloud and Service Cloud, sold to providers (hospitals, clinics), payers (health insurance), pharmaceutical companies, medical device manufacturers, and digital health companies. The product extends the standard data model with healthcare-specific objects (Patient, Member, Care Plan, Health Condition, Medication, Encounter, Visit) and supports FHIR (Fast Healthcare Interoperability Resources), the modern healthcare data exchange standard. Health Cloud has compliance baselines for HIPAA in the US, with regional variations for other countries. The product is one of Salesforce's industry clouds, alongside Financial Services Cloud, Manufacturing Cloud, Consumer Goods Cloud, and others, each tuned for the workflows and regulatory requirements of a specific vertical.

Health Cloud CRM Analytics Settings is a Setup page for configuring the CRM Analytics app dedicated to Salesforce Health Cloud. The settings page lets healthcare organizations deploy pre-built dashboards and datasets that read from Health Cloud's clinical data model: patients, care plans, care team members, clinical encounters, conditions, medications, and assessments. The result is a starting view of population health, care coordination effectiveness, and outcome trends without building dashboards from scratch. The page sits in Setup under CRM Analytics, with a Health Cloud subsection that bundles the wizard that deploys the analytics app plus the configuration options for dataset refresh schedules, row-level security predicates, and tier-based filtering. Most healthcare orgs running Health Cloud also license CRM Analytics, and the Health Cloud Analytics Settings is the connecting tissue between the operational system and the analytical surface that clinical and operational leadership relies on.

Health Cloud Setup is the collection of configuration steps and Setup pages an administrator uses to turn a standard Salesforce org into a working Health Cloud org. It covers the prerequisites (person accounts, shared contacts, My Domain, Chatter), the Health Cloud managed package install, the permission set licenses and permission sets that grant access, and the patient-facing components like the Patient Card and care plans. Health Cloud is the Salesforce product for healthcare payers, providers, and life sciences. It sits on the core platform and adds a clinical and member data model, FHIR-aligned objects, and purpose-built console apps. Most of that data model now lives as standard platform objects, and a managed package adds the extra objects, flow templates, Lightning components, and Apex triggers on top. Health Cloud Setup is the work of wiring all of those pieces together so care teams can open a record and see the full picture of a patient or member.

A Healthcare Plan in Salesforce Health Cloud is the data that records which insurance a patient carries and what that insurance covers. The patient side of this lives on the MemberPlan object, which represents the insurance coverage held by a specific member or subscriber. The benefits attached to that coverage, including copays, coinsurance, deductibles, and out-of-pocket limits, are stored in CoverageBenefit and CoverageBenefitItem records linked back to the member plan. Health Cloud keeps two sides of the plan separate. The purchaser side describes the plan a sponsor (an employer or government program) buys and offers, modeled by Purchaser, PurchaserPlan, PlanBenefit, and PlanBenefitItem. The member side describes one person's actual enrollment in that plan. This split lets a payer define a plan once, then enroll thousands of members against it without copying the benefit rules onto every record.

Heroku is the cloud application platform that Salesforce acquired in 2010, now offered as part of the Salesforce platform family. It is a managed Platform as a Service that runs applications written in Ruby, Node.js, Python, Java, Go, PHP, Scala, and Clojure on Linux containers called dynos, without asking the developer to manage servers, operating systems, or patching. In the Salesforce world, Heroku is where code goes when it needs a runtime outside Apex governor limits. A customer-facing web app, a high-volume batch job, a machine learning pipeline, or a microservice that powers an Agentforce action can all live on Heroku and still exchange data with Salesforce. Heroku is licensed and billed separately from your Salesforce org, with its own pricing (dyno usage plus add-on subscriptions) and its own admin console at dashboard.heroku.com.

Hierarchy Custom Settings are a type of Salesforce Custom Setting that store configuration values with per-user, per-profile, and org-wide overrides arranged in a strict precedence hierarchy. When code reads a Hierarchy setting, the platform returns the most specific value available: a value defined for the running user takes precedence over a value defined for their profile, which takes precedence over the org-wide default. The mechanism is a lightweight alternative to building a custom configuration object with sharing rules and ownership. Hierarchy Custom Settings differ from List Custom Settings (the other type), which store key-value pairs without hierarchy and require explicit lookup by name. Hierarchy is the right choice when configuration legitimately varies by user or profile: a sales rep's default email signature, a profile-specific API endpoint, a feature flag that should be on for everyone except certain user populations. List is the right choice when the configuration is a set of records (currency rates, environment-specific service URLs) that does not vary per user.

High-Volume Portal Users (HVPU) is the legacy Salesforce user-license type designed for Customer Portal and Partner Portal deployments where the number of external users counted in the hundreds of thousands or millions. The license traded most of the standard portal-user features (role hierarchy participation, manual sharing, sharing rules) for radically lower per-user pricing, making large-scale customer self-service viable on Salesforce. The license is now called High Volume Customer Portal User in modern terminology, with the equivalent Experience Cloud license being Customer Community (HVCC) or the External Apps + High Volume licensing in current Salesforce pricing. HVPU users have no role, do not participate in the role hierarchy, and gain record access only through explicit sharing rules and account-based sharing. The trade-off saves enormous amounts of memory and processing power on the Salesforce side, but it means the standard sharing model many admins know does not apply. Designing record access for HVPU users is a specialized skill, and getting it wrong is the most common reason large-scale Communities projects struggle in their first year.

A Highlights Panel is the strip of key fields shown at the top of a Salesforce record page in Lightning Experience. It surfaces the most important attributes of the record (Account Name, Amount, Close Date, and Owner on an Opportunity, for instance) and keeps them pinned in view while the user scrolls through related lists and the activity timeline. The first field appears in a larger accented font, and the panel renders up to the first seven fields of the record's compact layout depending on screen width and the user's permissions. The Highlights Panel is unusual among record-page elements: it is the one part of the page that you cannot configure with the page layout editor. Instead, its content comes entirely from the compact layout assigned to the record. The Lightning App Builder places the panel as a standard component, but the fields inside it are chosen in Object Manager under Compact Layouts. Get that one setting right and every record answers "what is this?" at a glance.

Holidays is the Salesforce Setup configuration that records non-working days for Business Hours, affecting how the platform calculates time on records that respect Business Hours. Each Holiday record carries a name, a date, and an optional recurrence pattern (annually on this date). Holidays are associated with specific Business Hours configurations; the same calendar date can be a holiday in one Business Hours profile and not another, which matters for global organizations with regional Business Hours. The configuration matters most for Case milestones, Entitlement processes, and any custom calculation that uses BusinessHours.diff() in Apex to count working time between two timestamps. Without holidays defined, the platform treats every day except weekends as a working day, which causes Service Level Agreement (SLA) calculations to count holiday days as if support were available. Service Cloud customers operating with strict SLAs need accurate Holiday configuration; without it, automated escalation paths may fire on dates when no agents are working.

A Home Organization is the primary Salesforce org that owns a user's identity in an enterprise that runs more than one org. It is the org where the User record is created, where the login credential or Federation ID lives, where the license is consumed, and where password and session policy apply. Every other org the person reaches treats this org as the authoritative source for who they are. The term turns up wherever one identity spans several orgs. With Salesforce Identity, the home org issues the SAML assertion that signs a person into a downstream org. In a hub-and-spoke or peer federation, it acts as the identity provider that the spoke orgs trust. In cross-org record sharing, queues and sharing references resolve a person through their home-org user ID. Pinning down the home org removes ambiguity about which org holds the real account.

The Home Tab is the landing page a Salesforce user sees when they first log in to Lightning Experience. It is a configurable Lightning page built in Lightning App Builder from a grid of components such as Performance, the Assistant, Today's Events, Today's Tasks, Recent Records, and Top Deals, alongside any custom components an admin chooses to add. Admins design one or more Home pages, then assign each one to the whole org, to a specific Lightning app, or to a combination of app and profile. At login, Salesforce picks the most specific page that applies to the user. A tailored Home Tab shows the work a person needs to handle today, while a default Home Tab shows the generic layout that ships with every org.

Hover Detail is the Salesforce feature that shows a small popup preview of a record when a user points their cursor at the record's name or a lookup link, without opening the full record. In Salesforce Classic, where the name originates, this preview is configured through the Mini Page Layout and is switched on by the org-level Enable Hover Details setting. The popup lets someone scan a list view, a related list, or the Recent Items sidebar and read a few key fields at a glance. The Classic Hover Detail (driven by the Mini Page Layout) is the older, separately configured version of this idea. Lightning Experience kept the hover preview but changed how it is built. In Lightning the same popup is driven by the Compact Layout, the configuration that also feeds the Highlights Panel, the mobile app, and search results. If you are building new today, you customize the Compact Layout, not a Mini Page Layout. The Classic Hover Detail still works for orgs on Classic, but it is legacy.

An HTTP Debugger in the Salesforce context is any tool that captures, inspects, and replays HTTP requests and responses traveling between Salesforce and an external system. Developers use HTTP debuggers when diagnosing integration failures: a callout returns the wrong status code, an inbound API call posts the wrong payload, an OAuth handshake stalls midway, or a Salesforce Connected App rejects a SAML response. The debugger surfaces the raw HTTP exchange so the developer can see exactly what was sent and received. Salesforce ships a small set of native debugging tools (Apex Debug Logs with Callout filter, the Developer Console Logs tab, the Salesforce Workbench REST Explorer) that show the Salesforce side of any HTTP exchange. For the external side, developers reach for third-party debuggers (Postman, Charles Proxy, Fiddler, mitmproxy, Wireshark, Chrome DevTools Network tab). The combination is mandatory for any non-trivial integration work, because a callout failure rarely tells you which end is misbehaving until you compare both sides of the wire.

Hyperforce is Salesforce's reimagined infrastructure platform that runs the Salesforce stack on public cloud infrastructure providers including AWS, Azure, and Google Cloud. It is the successor to the legacy first-party data centers Salesforce operated for two decades, designed to give customers the same Salesforce functionality with the added benefits of geographic data residency, faster regional expansion, and modern infrastructure operations. The migration from legacy Salesforce data centers to Hyperforce has been ongoing since 2021 and is a multi-year effort that touches every Salesforce product. Each org gets migrated to a Hyperforce-hosted instance in a specific cloud region, chosen based on the org's data residency requirements (US, EU, India, Australia, and more being added). The customer-facing experience is unchanged: the same Lightning Experience, the same APIs, the same login URL. The change is under the hood, where Salesforce operates on cloud-native primitives (Kubernetes, microservices, object storage) instead of bespoke data center hardware.

A Hyperforce Assistant is the in-Setup guided tool that helps Salesforce admins prepare an org for migration from legacy first-party infrastructure to Hyperforce. Hyperforce is Salesforce's public-cloud infrastructure, built on Amazon Web Services and described by Salesforce as composed of code rather than hardware. The Assistant runs org-contextual readiness checks, points to the right help articles, and tracks the preparation work so the cutover goes smoothly. You reach it in Setup by typing Hyperforce Assistant in the Quick Find box and selecting it. The tool became generally available in the Summer '23 release and runs in both production and sandbox orgs. It organizes the work into two phases, Learn and Prepare, and surfaces the specific tasks your org needs, such as removing hard-coded instance URLs and confirming connectivity to the target Hyperforce instance.