Salesforce terms starting with H

Half-life in Salesforce refers to the decay-weighted relevance metric used in two distinct features. In Salesforce Knowledge and Salesforce Search ranking, half-life is the time interval after which an article''s view-based ranking signal loses half its weight, so newer high-traffic articles outrank older ones over time. In Ideas and Idea Themes, half-life is the period (configured by the admin in days) after which an idea''s up-vote score decays by half, ensuring that recent ideas with strong engagement rank higher than old ideas with long-accumulated votes. The term is also occasionally used informally to describe the half-life of CRM data: how quickly contact records go stale, how soon a closed-lost opportunity stops being relevant for pipeline analysis, or how long support cases retain reporting value. Those informal uses do not map to a configured setting in Salesforce, but the formal Ideas Half-Life setting under Setup, Ideas Settings, is the one most admins encounter when configuring an Ideas community.

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 Salesforce Setup node that configures Health Cloud, the Salesforce Industries product for healthcare and life-sciences organizations. The node bundles every Health-Cloud-specific configuration: enabling the data model (Patient, Provider, Care Plan, Health Condition, Medication, EHR sync mappings), assigning Health Cloud permission sets, configuring the Patient Card and Care Team layouts, and turning on integrations like the EHR connector and the Patient Service Console. Health Cloud sits on top of Service Cloud as an industry-specific layer. The base Service Cloud licenses still apply for agent seats; Health Cloud adds the medical data model (managed package + standard objects), the patient-centric UI components, and the regulatory configuration (HIPAA-aligned auditing, consent management, FHIR integration patterns). Health Cloud Setup is where the entire configuration surface for these capabilities is collected, so a Health Cloud admin lives in this node during initial provisioning and during every release upgrade.

A Healthcare Plan in Salesforce Health Cloud is a record on the HealthcarePayerNetwork or HealthcareProductCoverage object representing the insurance plan a patient is enrolled in, with the relationships to the issuing payer, the covered services, the network of providers, and the cost-sharing details (copays, deductibles, out-of-pocket maximums). The object family includes HealthcarePayer (the insurance company), HealthcarePayerNetwork (a named network within a payer like PPO or HMO), HealthcareProduct (a specific plan SKU), HealthcareProductCoverage (what the plan covers), and PurchaserPlan (the patient''s membership in a plan). The Healthcare Plan model exists because patient access, prior authorization, claims handling, and care coordination all depend on knowing what insurance a patient has and what it covers. Without the structured plan data, every benefit check is a manual phone call to the payer. Health Cloud encodes this data in the standard objects, lets the payer integration populate it automatically via FHIR Coverage and CoverageEligibilityResponse resources, and surfaces the active plan on the Patient Card so providers can see eligibility in real time.

Heroku is the cloud application platform that Salesforce acquired in 2010, now branded as Salesforce Heroku and positioned as the polyglot, container-based runtime that complements Salesforce''s declarative platform. Heroku runs Ruby, Node.js, Python, Java, Go, PHP, Scala, and Clojure applications on a managed PaaS, with Heroku Postgres as the default database, Heroku Connect as the bidirectional sync to Salesforce data, and a marketplace of add-ons (Redis, Apache Kafka, monitoring tools) that extend the runtime. In the Salesforce ecosystem, Heroku is the answer when an integration or customer-facing application needs a runtime outside Apex governor limits. Common patterns include high-volume public web apps that read or write Salesforce data via Heroku Connect, machine-learning pipelines that train on Salesforce data and write predictions back, mobile app backends, and any custom code that cannot fit within the Apex/Visualforce/LWC trifecta. Heroku is licensed separately from Salesforce, with its own pricing model (dyno hours, database tiers, add-on subscriptions) and its own administration console (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.

The Highlights Panel is the strip of key fields displayed at the top of a Salesforce record page in Lightning Experience. It surfaces the four to eight most important attributes of the record (Account Name, Amount, Close Date, and Owner on an Opportunity, for instance), keeping them in view as the user scrolls through related lists and Chatter feeds. Admins configure which fields appear via the Compact Layout assigned to the record type, and the Highlights Panel renders the chosen fields automatically; there is no separate Highlights-Panel layout editor. The component is one of the highest-leverage UX surfaces in Salesforce. A well-tuned Highlights Panel surfaces the answer to "What is this record about?" in three seconds. A neglected one shows whatever fields happen to sit at the top of the alphabet on the master layout, often missing the field the user actually needs. The Lightning App Builder includes a Highlights Panel as one of the default record-page components; admins can also build custom highlights via Lightning Record Page Header components when the standard panel falls short.

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.

Home Organization is the Salesforce term for the primary org a user belongs to in a multi-org enterprise setup, particularly in Salesforce-to-Salesforce, Org-Wide Federation, and Identity Connect scenarios. It is the org where the user record lives natively, where their credentials are stored, where their license is assigned, and where their default identity is anchored. Other orgs the user accesses (through single sign-on, federated identity, or cross-org sharing) treat the home organization as the source of truth for that identity. The term shows up in three concrete contexts. In Salesforce Identity, a user authenticating into a downstream org via federated SSO presents credentials issued by their Home Organization. In Org-Wide Federation, where many Salesforce orgs share users through SAML-based or Auth Provider-based trust, the Home Organization is the SAML identity provider. In multi-org sharing patterns, sharing rules and queues identify users by their home-organization user ID; without it, the cross-org reference is ambiguous.

The Home Tab is the landing page Salesforce users see when they first log in. In Lightning Experience, it is a configurable Lightning Page assembled from components (Performance, Today''s Events, Today''s Tasks, Recent Records, Top Deals, News, Chatter Feed, custom Lightning Components). Admins design one or more Home Lightning Pages per app, assign them to user profiles or apps, and the system selects the appropriate page for each user at login. The Home Tab anchors the user''s daily Salesforce experience. A well-designed Home Tab surfaces the work the user needs to do today (open opportunities, overdue cases, pending approvals) without forcing a click. A neglected Home Tab shows the Salesforce default layout, which is generic enough that most users develop the habit of skipping it entirely. The component library is wide enough that admins can build role-specific home pages (one for sales reps, one for managers, one for service agents) using the same Lightning App Builder used for record pages.

Hover Detail is the Salesforce UI feature that surfaces a popup preview of a record when a user hovers over its name or link in a list view, related list, lookup picker, or report. The popup shows the Compact Layout fields (the same field set that drives the Highlights Panel) for the hovered record, letting the user inspect key attributes without navigating away. The feature reduces clicks; an admin scanning a Contacts list view can see each contact''s email, phone, and account at a glance by hovering, without opening each record. Hover Detail is a Lightning Experience feature; the legacy Classic UI had a similar but separately configured Mini Page Layout that powered hover previews. In Lightning, the hover content is derived directly from the Compact Layout assigned to the record type, so customizing the Compact Layout customizes the hover detail at the same time. There is no separate Hover Detail editor in modern Salesforce; the Compact Layout is the single source of truth.

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.

Hyperforce Assistant is the Setup-guided migration tool that helps Salesforce admins evaluate and migrate their orgs from legacy first-party-pod infrastructure to Hyperforce, Salesforce''s public-cloud-based infrastructure platform. Hyperforce is the long-term replacement for the Salesforce-managed data centers; it runs on AWS (and selected hyperscalers) inside customer-aligned regions and brings benefits like data residency by region, faster provisioning, and tighter compliance certifications. The Assistant guides admins through readiness checks, migration scheduling, and post-migration verification. The Assistant sits in Setup under Hyperforce Migration Assistant (the exact node name varies by release). It runs prerequisite checks: confirms the org is on a supported release, identifies legacy features incompatible with Hyperforce, surfaces integrations that may need IP allow-list updates, and shows expected downtime windows. It also coordinates the migration scheduling, which historically required filing a Salesforce Support case manually. The whole experience is designed to make a non-trivial infrastructure move feel like a guided wizard.