Salesforce terms starting with C

A Calculated Insight is a Salesforce Data Cloud metric or attribute computed by an SQL-style query against Data Model Objects, materialized on a schedule, and surfaced as a queryable field on a DMO or as a standalone metric available to segmentation, activations, and Customer 360 profile cards. Calculated Insights are how Data Cloud turns transactional event data (every email opened, every purchase, every web visit) into derived attributes like Lifetime Value, Average Order Value, Last Engagement Date, or Customer Health Score. The Calculated Insight engine runs scheduled SQL queries that aggregate child records into parent-level metrics. The query language is a constrained dialect (essentially ANSI SQL with Data Cloud-specific functions and joins). Each Calculated Insight produces one or more output fields, persisted on the target DMO or stored in a separate Calculated Insight Object. Downstream segmentation, prompts, and activations can filter or display Calculated Insight values exactly like any other DMO attribute. This is the bridge from raw events to actionable business metrics.

The Calendar in Salesforce is the personal and shared scheduling surface that displays Event records (and any Object-Based Calendar built from other records with date fields) in day, week, and month views. It sits inside the Salesforce Lightning UI as the Calendar tab and as the Calendar component on Lightning pages. Users see their own Events plus any other calendars they have been granted access to. Object-Based Calendars let admins surface records like Opportunity Close Dates, Service Appointments, or custom-object due dates as calendar entries, so the calendar becomes the scheduling overlay across the org's data. Salesforce Calendar matters because schedule data lives in many places and users need one view. Without the Calendar tab, sales reps would track meetings in Outlook, account close dates in spreadsheets, and field appointments in a separate system. With it, all of those (when surfaced through Object-Based Calendars and Einstein Activity Capture sync) appear in one weekly view. Calendars are also the foundation for Salesforce Scheduler, Field Service appointment booking, and any workflow that needs to consider time availability. The personal Calendar is the entry point; the shared and object-based calendars layered on top are how it becomes operational.

Calendar Settings is the Salesforce Setup page that controls how user calendars, shared calendars, and public calendars behave across the org: default event reminders, whether events show participant lists by default, the calendar sharing model (private, public read-only, public read/write), enabling Salesforce-side public calendars (Resource Calendars, Public Calendars), and the integration with Lightning Sync or Einstein Activity Capture for external calendar sync. Calendar Settings is one of the lower-traffic Setup pages and holds defaults that shape the daily calendar experience for every user. Most settings are reasonable out of the box and rarely need adjustment; the ones that matter are sharing model (public-by-default vs private-by-default affects how reps see colleagues' meetings) and external calendar sync configuration (Lightning Sync, EAC, or third-party). The page deserves a quarterly review alongside Activity Settings and Account Settings to catch drift between platform defaults and team workflow.

A Call in Salesforce is a customer-facing telephone interaction, recorded in CRM either as a logged Task (TaskSubtype = Call) for manually documented calls, or as a Voice Call standard object record for calls placed through Service Cloud Voice or a CTI-integrated telephony platform. Both representations capture the same conceptual event (a conversation between a Salesforce user and a customer) but differ in how the data is created and what additional context is attached. Logged Calls are quick post-fact notes by an agent or rep. Voice Call records capture full telephony metadata: ANI, DNIS, call duration, recording URL, transcript, and a link to the connected Agent. Calls are foundational to Salesforce activity reporting. Reps log them to track outreach. Service agents handle them through Voice Call records in the Service Console. Forecasting and account-based selling lean on call volume metrics as leading indicators. Service Cloud Voice extended the model with real-time transcripts and Einstein Conversation Insights, turning the Call record into a rich source of signal beyond timestamps and duration. The combination of logged Calls (the bulk of activity data) and Voice Calls (the high-quality, telephony-captured subset) gives Salesforce a complete view of how often the team is on the phone and what gets said.

A Call Center in Salesforce is the Setup record that connects a telephony platform to Salesforce's Computer Telephony Integration (CTI) framework. Each Call Center represents one telephony deployment (an Amazon Connect instance through Service Cloud Voice, a Five9 contact center, a Genesys Cloud deployment, a RingCentral platform) and exposes a Softphone in the Service Console for agents to receive and place calls. The Call Center record holds the CTI adapter URL, capacity settings, dial prefix, and other connection parameters; users with Call Center membership see the Softphone on their console pages and can take calls routed through the connected telephony. Call Centers matter because Salesforce does not ship its own complete telephony platform; it integrates with one. Service Cloud Voice with Amazon Connect bundles a Salesforce-provisioned Connect instance, but the Call Center record still mediates the connection. Partner Telephony products (Five9, NICE inContact, Talkdesk, Genesys, RingCentral, Cisco) each have their own Open CTI adapter that registers a Call Center record. Picking a Call Center, configuring it correctly, and assigning users to it is the foundational step for any Salesforce service organisation that handles voice. Without a Call Center, the Softphone does not render and voice integration does not work.

An Apex Callout is an outbound HTTP request that Apex code sends to a system outside Salesforce, typically a REST or SOAP API. The callout runs from inside the Salesforce platform, hits an external endpoint, and parses the response into Apex objects that the rest of the code can act on. Callouts are how Salesforce integrates with payment processors, ERP systems, identity providers, AI models, and any third-party service that exposes an HTTP API. The platform restricts callouts heavily. They cannot fire from inside a database trigger synchronously (must be queued via @future, Queueable, or platform events), they require a Remote Site Setting or a Named Credential allowlist, they count against per-transaction governor limits (100 callouts per Apex transaction, 120-second total callout time), and they must use HTTPS in production unless the endpoint is explicitly exempted. Every restriction exists to keep the multi-tenant platform from becoming an attack surface or a runaway resource consumer.

A Campaign in Salesforce is a marketing program record: an email send, a webinar, a trade show, a paid ad flight, a content syndication push, or any other outreach effort that produces Leads and influences Opportunities. Campaigns hold the metadata for the program (Name, Type, Status, Start and End Date, Budgeted Cost, Actual Cost, Expected Response, Expected Revenue) and they hold a roster of CampaignMember records that ties every Lead and Contact who participated back to the program. Campaigns matter because they are how marketing makes its case for budget. Without Campaign records, the question "did the trade show we spent forty thousand dollars on produce any pipeline" has no answer in Salesforce. With Campaign records and a working Campaign Influence model, the same question turns into a report. The Campaign object is one of the more underused parts of Sales Cloud in B2B orgs, partly because marketing teams use dedicated tools like Pardot or Marketing Cloud and assume those tools cover the attribution job. They do not. Pardot and Marketing Cloud track engagement; native Salesforce Campaigns track attribution to revenue.

Campaign Hierarchy is the Salesforce feature that lets you stack related Campaign records into a parent-child tree up to five levels deep. Each child campaign rolls its Campaign Members, costs, and influenced revenue up to the parent, so marketing leadership can see the aggregate impact of a multi-touch program in one place instead of summing twenty individual campaigns by hand. The hierarchy lives on the Parent Campaign lookup field on the Campaign object. Set Parent Campaign on a child record and the child is now part of the hierarchy; the parent's hierarchy fields aggregate from every descendant. The standard fields (Total Members in Hierarchy, Total Opportunities in Hierarchy, Total Won Opportunities in Hierarchy, Total Value Won Opportunities in Hierarchy, Total Value Opportunities in Hierarchy) calculate live without flow or formula work.

A Campaign Member is the junction record that links a Lead or Contact to a Campaign in Salesforce. The record captures who the person is, which campaign they touched, what their current Member Status is (Sent, Responded, Registered, Attended), and the Response Date when status flipped to a responded state. Every interaction between a person and a marketing program lives in one of these rows. CampaignMember is a standard junction object, but it is shaped differently from a normal junction. It carries fields from both parent records (Lead/Contact and Campaign) plus its own status, response, and date fields. It is the data source for Campaign Influence, Campaign Hierarchy rollup counts, and most marketing reports. Without Campaign Members, a Salesforce Campaign is just a label with a cost field.

Campaign ROI (Return on Investment) in Salesforce is the formula-driven percentage that compares the closed-won revenue attributed to a Campaign against the cost the marketing team spent to run it. The standard Campaign object ships with the ROI field computed as (Total Value of Won Opportunities minus Actual Cost in Campaign) divided by Actual Cost in Campaign, multiplied by 100. A 200 percent ROI means the campaign returned twice its cost in won revenue. Salesforce uses Campaign Influence and Campaign Members to attribute Opportunities to the Campaign; ROI is just the rolled-up math on that attribution. Campaign ROI matters because every marketing team needs to prove which campaigns work. Without it, marketing budgets get cut indiscriminately or expanded without evidence. With it, leadership can see the campaigns that produce real pipeline and the ones that consume budget without return. The accuracy of Campaign ROI depends entirely on two inputs: how rigorously cost is tracked in the Actual Cost field, and how completely Opportunities are attributed to the right Campaigns through Campaign Influence. Sloppy on either side and the ROI number reads like fiction; rigorous on both and ROI becomes the single most-watched marketing performance metric.

The Canvas App Previewer is the Salesforce developer tool that lets engineers test a Canvas App before publishing it to end users. Canvas Apps are third-party web applications embedded inside Salesforce (in the Service Console, on Lightning record pages, in Chatter publisher) through the Canvas framework. The Previewer is a Setup page that mimics how the Canvas App will appear inside Salesforce, lets the developer feed in a context (a record ID, a user, a session), and renders the app live. It is the standard testing surface during Canvas App development before the app gets a Connected App registration and is rolled out to production users. Canvas App Previewer matters because Canvas Apps are complex integrations. The framework passes a signed JSON payload with user, org, and record context to the embedded web app via OAuth. Testing all the moving parts (the auth handshake, the signed payload, the iframe rendering, the cross-window messaging back to Salesforce) without the Previewer would require manually building and tearing down a Connected App for every test cycle. The Previewer makes the loop short: paste the Canvas App URL, run the preview, debug the integration. Once it works in the Previewer, the integration is ready for production registration through Connected Apps.

A Care Plan in Salesforce Health Cloud is a structured record that captures a patient's clinical goals, identified problems, planned interventions, scheduled tasks, and progress over time. The Care Plan ties together Patient (a Person Account), Care Team members, Goals (what the patient should achieve), Problems (clinical conditions being addressed), and individual Tasks or Activities that implement the plan. Care Coordinators, social workers, and case managers use Care Plans to organise the longitudinal effort around one patient, especially in chronic-care, behavioural-health, and post-acute scenarios where many providers contribute over months or years. Care Plans are central to Health Cloud's value proposition. Without them, the patient's record is a flat list of disconnected interventions; with them, the same data organises into a coherent plan of care that the entire Care Team can read at a glance. Health Cloud ships standard Care Plan templates for common conditions (diabetes management, post-surgical recovery, chronic-disease coaching), and admins extend with org-specific templates. Government and public-sector programs use the same structure under Public Sector Solutions, where Care Plans become Case Plans tracking participants in social services programs. The data model is similar; the vocabulary differs by industry.

A Care Program in Salesforce Health Cloud is an enrolment-based program that patients participate in over time: a Diabetes Management Program, a Mental Health Coaching Cohort, a Post-Discharge Follow-Up Program, a Maternity Support Program. The Care Program record defines the program's name, sponsor, eligibility criteria, target outcomes, and budget. Patients enrol into a Care Program through a Care Program Enrollee record, which tracks their participation status, start date, end date, assigned Care Coordinator, and progress milestones. A single Care Program serves many enrollees; one patient can be enrolled in multiple Care Programs simultaneously. Care Programs are the macro-level structure that Care Plans sit inside. Where a Care Plan organises work around one patient, a Care Program organises a population of patients pursuing a shared goal (managing diabetes, recovering from surgery, navigating maternity). Health plans, providers, and disease-management vendors use Care Programs to run population health programs at scale. The Care Program record carries the budget, the staffing model, the reporting framework, and the outcomes metrics that justify the program to leadership. Enrollees inherit the program's standard Care Plan Template, get assigned Care Team members from the program's pool, and roll up into program-level outcomes reports.

A Care Team in Salesforce Health Cloud is the set of users (clinicians, social workers, case managers, family members, and others) coordinating on one patient's care. Each Care Team Member record links a user to the Patient (Person Account) with a defined role (Primary Care Physician, Care Coordinator, RN Coach, Social Worker, Family Caregiver, Emergency Contact), a relationship type, and an access level. The Care Team is what makes Health Cloud multi-disciplinary; everyone working with the patient sees a unified view of who is involved, what they own, and how to reach them. Care Teams matter because chronic care, behavioural health, and post-acute scenarios involve many people working with the same patient over months or years. Without an explicit Care Team, the patient's record becomes a flat list of unrelated interventions; with one, the Care Team panel surfaces the entire roster on one page, contact info inline, and an at-a-glance picture of accountability. The same model works in Public Sector Solutions as Case Team for social-services participants, with similar mechanics under different vocabulary. Care Teams underpin Care Plan task assignment, Care Program staffing, and the cross-disciplinary collaboration that Health Cloud was built to enable.

A Cart in Salesforce is the Commerce Cloud or B2B Commerce object that holds a shopper's selected items, applied promotions, calculated taxes and shipping, and current totals before checkout. The Cart is the working draft of an order; once the shopper completes checkout, the Cart converts to an Order record and the cart is closed. Cart records are tied to a Buyer Account (B2B) or a Person Account / Guest Shopper (B2C), and child Cart Item records represent the individual products with quantity, price, and configuration. Salesforce B2B Commerce, B2C Commerce, and the Lightning B2B Commerce platform all use the same conceptual Cart model with slightly different schemas. Carts matter because every e-commerce interaction passes through one. The shopper's experience (add to cart, remove, change quantity, apply promo code) is direct manipulation of the Cart and its items. Backend operations (price calculation, inventory check, fraud screening) all read and write to the Cart. Salesforce's Commerce platform encapsulates these operations as Cart Calculator framework calls; the framework orchestrates pricing, promotions, tax, shipping, and inventory in a defined sequence. Abandoned-cart workflows (the customer left without checking out) operate on Cart records that have not converted to Order, with Marketing Cloud journeys triggered to re-engage the shopper.

A Cart Item is the child record of a Salesforce Commerce Cart that represents one product line: a specific Product, the quantity, the unit price, the configured options (if the product supports configuration), and any item-level promotions or notes. Each Cart Item belongs to exactly one Cart; together the Cart Items form the line-level detail under the Cart's totals. When the Cart converts to an Order at checkout, each Cart Item becomes an Order Product (or Order Item depending on the product family). Cart Items matter because Cart-level totals are the rollup of Cart Item math. Price changes, promotion application, inventory checks, and configuration validation all operate on individual Cart Items first, with the Cart's totals recalculated after. The Cart Calculator framework reads and writes Cart Items during each calculation step. Reports that need line-item analysis (which products sell, which configurations get added then removed, which promotions move which SKUs) query Cart Items directly rather than the parent Cart. Most operational analytics in Salesforce Commerce live at the Cart Item level.

Cascading Style Sheet (CSS) in Salesforce is the same web-standard styling language used everywhere else on the web: a declarative rules language that sets colours, fonts, spacing, layout, and other visual properties for HTML elements. Salesforce uses CSS to render Lightning Experience, Lightning Web Components, Aura Components, Visualforce pages, Experience Cloud sites, Email Templates, and Salesforce-built mobile interfaces. Most Salesforce developers write CSS in component-scoped files (one stylesheet per Lightning Web Component), in legacy global stylesheets (for Visualforce), or in Experience Cloud Builder's branding panel. CSS in Salesforce comes with platform-specific constraints. The Salesforce Lightning Design System (SLDS) ships the design tokens, base styles, and utility classes that Lightning Experience and Lightning Web Components inherit. Developers are encouraged to compose SLDS classes rather than write bespoke CSS from scratch. Locker Service (the now-retired security wrapper) and Lightning Web Security (its replacement) impose limits on CSS in Lightning components, particularly around shadow DOM scoping and access to certain global selectors. Visualforce pages have fewer constraints but render in an iframe in Lightning Experience, which limits cross-frame styling. Experience Cloud sites apply CSS through Branding Sets and global stylesheets, with theme tokens that propagate to every component.

A Case is a customer support ticket in Salesforce, the record that captures something a customer needs from you and tracks the work done to resolve it. Cases tie to a Contact (the person who raised the issue) and usually to an Account (the company they belong to). They carry Subject, Description, Status, Priority, Origin, Type, and Reason, plus whatever custom fields your service organization uses to route, triage, and report on incoming work. The Case object is the heart of Salesforce Service Cloud. Most of what makes Service Cloud distinct from Sales Cloud sits on top of Case: the OmniChannel routing engine, the Service Console, Entitlements and Milestones for SLA tracking, Knowledge article suggestions, and the Email-to-Case and Web-to-Case capture endpoints. If your org runs a support team out of Salesforce, almost every operational question that matters (how long are we taking to respond, where are we missing SLAs, which Account has the most escalations) traces back to a query against Case.

Case Feed is the chronological activity stream that surfaces on a Salesforce case record, combining emails sent and received, call logs, status changes, attached files, internal posts, and customer-portal interactions in a single timeline. It is the agent's primary working surface inside the Service Console: above the feed sit publishers for the most common actions (Reply Email, Log a Call, Internal Note, Change Status), below it sits the chronological case history. The combination collapses what would otherwise be five separate related lists into one continuous thread. Case Feed has two generations. Classic Case Feed shipped in 2010 as a workaround for the limitations of the standard Case detail layout. Compact Case Feed, the modern Lightning version, redesigned the surface to fit the Service Console workspace, with the Highlights Panel above, the publisher tab strip in the middle, and the feed below. Publishers are now Quick Actions, configurable through the page layout. The Compact Case Feed is the recommended surface for any Lightning Service Cloud deployment. The Classic version still ships in older Salesforce Classic orgs but receives no new development.

Case Checkout in Salesforce Service Cloud is the workflow pattern where an agent explicitly claims a Case (or a record from a queue) by taking ownership before working on it. The behaviour signals to the rest of the team that this case is being handled, prevents two agents from picking up the same case, and starts the work clock from the moment of checkout. Salesforce surfaces the pattern through Take Ownership buttons on Queue list views, through Omni-Channel routing (which automatically assigns work and prevents double-claim), and through custom Apex or Flow that updates the case Owner field on user action. Case Checkout matters because customer service teams often share a pool of incoming work. Without checkout, two agents can independently work the same case, duplicating effort and confusing the customer. With checkout, ownership becomes an explicit, visible state. Modern Service Cloud increasingly automates checkout through Omni-Channel rather than relying on manual Take Ownership. Either approach works; both produce the same operational outcome of one Owner per Case at any given time. The phrase Case Checkout appears most in legacy Service Cloud documentation and partner blogs; modern documentation uses Take Ownership or Omni-Channel Routing as the more specific terms.

Category Group for Articles is the Salesforce Knowledge taxonomy structure that organises articles into hierarchical Data Categories along a named dimension (Product, Topic, Geography, Audience). Each Category Group represents one dimension, containing nested Data Categories that articles get tagged with. A typical Knowledge implementation runs two or three Category Groups in parallel: a Product hierarchy for what the article is about, a Region hierarchy for where it applies, and sometimes a Lifecycle hierarchy for content maturity. Articles can tag against one or many categories per group; readers narrow by category to find relevant content. Category Group for Articles is configured in Setup, Data Category Setup. Admins build the tree, assign per-profile visibility, and link the Category Group to the Knowledge object so authors can categorise articles. The model is the same Data Category infrastructure that powered the retired Answers feature; for Knowledge, the term and the feature both survive. Visibility per profile lets admins expose different slices of the taxonomy to different audiences. Reporting filters by Data Category to slice content metrics by Product, Region, or any other dimension the org models. The Category Group is the foundation of any Knowledge program; misdesign here propagates to every downstream report and search experience.

Category for Ideas is the legacy Salesforce Ideas feature that organised user-submitted ideas into one or more category dropdowns inside an Idea Community (or Zone). Members posted ideas into specific categories so other community members could browse and vote. The Idea object's Categories field held the multi-select tagging; each community could define its own category list. Salesforce Ideas was bundled with the older Community Application alongside legacy Answers, and the same retirement pattern applied: Ideas as a standalone product was deprecated, with Chatter Feed and Experience Cloud Q&A now serving the modern equivalent. Idea Categories matter to readers of legacy Salesforce documentation because the term appears in pre-2020 certification material, partner blogs, and AppExchange listings. Newer Salesforce orgs no longer expose Ideas as a top-level community feature, though the underlying objects (Idea, IdeaComment, Vote) remain queryable for orgs that ran the feature historically. Modern product feedback programs run on a mix of Chatter Questions, Experience Cloud Q&A, third-party feedback tools (Pendo, ProductBoard), and Salesforce Community surfaces with the Idea-style functionality rebuilt from custom objects. The Categories concept lives on inside those custom builds even though the standard Categories for Ideas field is no longer the canonical surface.

Category, Knowledge and Answers is the legacy bundling of three related Salesforce Classic features: Data Categories (hierarchical content grouping), Knowledge (article-based help content), and Answers (community Q and A). The phrase appeared in Salesforce documentation through the 2010s as the umbrella term for the customer self-service content stack: visitors browse Categories to find Knowledge articles or Answers threads on a Service Cloud-powered portal. The bundle is mostly historical now; modern equivalents are Data Categories with Lightning Knowledge plus Chatter Answers or Experience Cloud-based Q and A. The phrase persists in older Salesforce Help documentation, Trailhead modules from the Classic era, and migration guides. New deployments do not encounter it as a single feature; the three components are now configured independently through Setup. Understanding the historical term helps when reading legacy material or supporting orgs that still run the Classic Answers feature. Salesforce retired the Answers feature itself in stages between 2015 and 2022, replacing it with Chatter Answers and then with Experience Cloud-based community Q and A.

Category for Solutions is the legacy Salesforce Solutions feature taxonomy that organised the Solution object's records into a hierarchical category tree, letting service agents browse and search for canned solutions when resolving Cases. The Solutions feature predates Salesforce Knowledge and shipped with Salesforce Service Cloud's earliest releases. Each Solution record represented a documented answer to a recurring customer issue; Solution Categories organised the solutions for faster discovery. Like Answers and Ideas before it, the Solutions feature has been deprecated in favour of Salesforce Knowledge, with most orgs migrating between 2015 and 2020. Category for Solutions matters mainly as a historical reference. The Solution object remains queryable in older orgs and partner blogs from the 2008 to 2015 era reference it extensively. Modern Salesforce Service Cloud documentation steers customers to Lightning Knowledge for canned-answer content, with Knowledge's Data Category Groups serving the same organisational role that Solution Categories once did. New orgs do not get the Solutions UI as a primary feature; the schema persists for backward compatibility but Salesforce no longer recommends building service operations around it. Reading any pre-2020 Salesforce documentation that mentions Category for Solutions should translate the concept to Data Category Groups for Knowledge.

Certificate and Key Management is the Salesforce Setup page where administrators create, import, and manage X.509 certificates and cryptographic keys used by the org for SAML signing, OAuth JWT bearer authentication, mutual TLS callouts, encrypted callouts, and platform encryption key wrapping. Each certificate has a label, a unique name, a key size (1024 or 2048 bit RSA, plus ECC options in newer versions), an expiration date, and a usage context (Self-Signed for SAML SP, CA-Signed for production, Connected App JWT, mutual TLS). The page is the central inventory of cryptographic identity material the org uses to prove itself to other systems. Certificate and Key Management is one of the lower-traffic Setup pages but holds material that directly affects authentication, integration, and compliance. An expired certificate breaks the integration that depends on it; a leaked private key requires re-issuing and re-distributing certificates everywhere they are used. Most production orgs hold a dozen or more certificates accumulated over years; treating the page as a registry with active inventory management is the difference between predictable rotation and 3 AM emergency outage calls.

A Challenge in the Salesforce ecosystem is the hands-on practice exercise at the end of a Trailhead module unit. Each Challenge asks the learner to perform a specific task in a Trailhead Playground (a free Developer Edition org provisioned for the lesson), and Trailhead's verification engine checks the work by querying the Playground's metadata or data. Pass the Challenge and the learner earns points, badges, and ranks toward higher Trailhead status (Ranger, Double Ranger, Triple Ranger). Fail and the engine returns a diagnostic message naming what is missing or wrong, so the learner can iterate until it passes. Challenges matter because Trailhead is how most Salesforce professionals learn the platform. A module taught only through reading would produce learners who recognise the concepts but cannot execute. Adding a Challenge per unit forces hands-on practice: building a Flow, writing a Validation Rule, creating an Apex class, importing data. The Challenge engine's automated verification scales across millions of Trailhead users and provides instant feedback that human grading could not. The result is the Trailhead community's distinctive blend of structured learning, gamification, and verifiable hands-on competence that has become the platform's standard learning credential.

Change Data Capture (CDC) is a Salesforce streaming feature that publishes change events (create, update, delete, undelete) for selected objects to the event bus in near real time. External systems subscribe to these events to replicate Salesforce data, trigger downstream automation, or feed analytics pipelines without polling the REST API for changes. CDC events look similar to Platform Events but carry the full record state alongside the change metadata. CDC is the foundation of modern Salesforce-to-external-system synchronization patterns. Where the older approach was to poll Salesforce on a schedule for records modified since the last run, CDC pushes changes to subscribers as they happen. The latency drops from minutes (or hours) to seconds. The platform handles ordering, replay, and partitioning automatically. Subscribers consume CDC through CometD (legacy) or the Pub/Sub API (modern), and the same event bus that powers Platform Events also delivers CDC events. The two are siblings architecturally but different in purpose: CDC tracks record changes, Platform Events represent business actions.

A Change Set is a Salesforce-native package of metadata components (custom fields, page layouts, Flows, Apex classes, Permission Sets, Validation Rules, Lightning Pages, and many other types) that an admin builds in one org and deploys to a connected org. Change Sets are the traditional sandbox-to-production deployment path: build in a sandbox, package the changes into an Outbound Change Set, send to production, receive in production as an Inbound Change Set, validate, deploy. The mechanism predates Salesforce DX and remains in wide use, particularly for admin-led deployments that do not involve source control. Change Sets exist because most Salesforce deployments need to move metadata between environments without source-tracking discipline. They are the lowest-friction deployment path: no command line, no Git, no separate deployment tool. The trade-off is that Change Sets do not support some modern metadata types (newer features ship as DX-only), do not include modification history, and can be tedious when many components need to ship together. Most production orgs use Change Sets alongside source-tracked deploys, picking the tool based on the change type and the team's source-control posture.

A Channel Manager in Salesforce is the internal user role responsible for managing relationships with channel partners (resellers, distributors, system integrators, agents) inside Salesforce Partner Relationship Management (PRM). Channel Managers own partner accounts, coordinate joint pipeline, register deals on the partner's behalf, run partner enablement programs, and report on partner-sourced revenue. The role exists in any company that sells through external partners, and Salesforce PRM (built on Experience Cloud plus the Partner Community) gives Channel Managers the standard tools to do the work: Partner Account hierarchies, Deal Registration, Lead Distribution, Market Development Funds (MDF), Partner Performance dashboards. Channel Managers matter because partner-sourced revenue is significant in most B2B businesses. Without explicit management, channel relationships drift, deal-registration disputes fester, and partner-sourced opportunities go uncredited. With it, Channel Managers maintain the structured operational rhythm (quarterly business reviews, deal-registration approvals, MDF requests) that keeps partners engaged. Salesforce PRM gives the Channel Manager a dashboard of partners, a queue of registration requests to approve, a tracker for MDF, and the partner-side Experience Cloud site where partners themselves submit deals and access enablement content.

Chat in Salesforce is the embeddable web-chat channel that lets customers start a text conversation with a service agent (or an AI bot) from a website. It originated as Live Agent in early Service Cloud, was rebranded to Chat with the Service Cloud Lightning console, and now sits inside Salesforce Service Cloud Digital Engagement as one of several Messaging channels (alongside SMS, WhatsApp, Apple Messages for Business, Facebook Messenger). Chat conversations route through Omni-Channel to available agents and persist as Live Chat Transcript or Messaging Session records in Salesforce, complete with the full message history, customer info, and any attached Knowledge articles. Chat matters because text-based support is now table stakes for most consumer-facing brands. Customers prefer chat to phone calls for many issue types; agents handle multiple chats concurrently with capacity controls, which makes Chat one of the most cost-effective service channels per resolved case. Salesforce's Chat product is the embedded widget plus the agent-side console plus the routing and analytics on top. Modern deployments increasingly front-load Chat with Agentforce or Einstein Bots to handle the long tail of common questions, escalating only to human agents when the bot cannot resolve. The result is dramatically higher containment (the percentage of conversations the bot handles end-to-end) with no loss of customer experience.

The Chat Console (also called the Live Chat Console in older documentation) is the Salesforce Service Cloud surface that agents use to handle incoming chat conversations alongside other case work. In Salesforce Classic, it was a dedicated console layout with chat panels embedded. In Lightning Experience, the Chat Console folds into the standard Service Console, with the Omni-Channel widget surfacing incoming chats and the chat panel opening as part of the active workspace tab. Agents see the active chat transcript, the customer's record details, related Knowledge articles, and any concurrent chats they are handling, all within one consolidated UI. The Chat Console matters because agent productivity on chat scales differently than on calls. A chat agent handles three to five concurrent conversations; the console must surface each one without confusion. Salesforce's modern Service Console with the Omni-Channel widget handles this well: each active chat lives in its own tab, the agent switches between them with keyboard shortcuts, and the console state preserves context per chat. The legacy Chat Console pattern was a more rigid multi-panel layout; the modern approach is more flexible. Reading any pre-2020 Salesforce documentation that references the Chat Console should translate to the Service Console plus Omni-Channel for current implementations.

The Chat Window is the customer-side UI of a Salesforce Chat conversation: the panel that opens when a website visitor clicks the embedded Chat button or accepts a proactive prompt. The window shows the running transcript, a typing area for the customer's messages, the agent's branding (logo, name, photo when configured), typing indicators, and any attached files or links. The Chat Window's visual design, behaviour, and content are configured through the Embedded Service deployment and inherit branding from the parent site. The Chat Window matters because it is the moment of truth for the customer's chat experience. A slow-opening window, an ugly branding mismatch, or a confusing pre-chat form drops conversions before the customer even reaches an agent. A well-designed Chat Window opens fast, matches the brand, collects only the information the agent needs, and feels like a natural extension of the website. Salesforce ships a default Chat Window that works out of the box; mature deployments customise it heavily through CSS overrides, branding configurations, and pre-chat form design to fit the customer experience the brand wants to deliver.

A Chatlet was a small custom Chatter widget or applet in early Salesforce Chatter that an admin or developer could add to a Chatter publisher to extend the kinds of posts users could create. Chatlets surfaced as buttons in the Chatter publisher and let users compose specialised post types: a poll Chatlet for quick voting, a thank-you Chatlet for peer recognition, a question Chatlet for structured Q&A. The concept was loosely Salesforce's early answer to extensible micro-apps inside Chatter feeds, predating the modern Lightning Component model. Chatlet is largely a historical term. Salesforce never standardised Chatlets as a first-class feature, and the patterns they covered have moved into modern surfaces: Chatter Questions handle the question use case, Quick Actions handle structured Chatter posts, and Lightning Components extend Chatter feeds with custom UI. The term appears in some pre-2018 partner blogs, AppExchange listings, and Chatter administration material. Reading any contemporary Salesforce documentation, treat Chatlet as a legacy concept; the modern equivalent is a Chatter Quick Action or a custom Lightning Web Component embedded in the feed surface.

Chatter Bookmarks is the Salesforce feature that lets users save Chatter feed items for later by clicking a Bookmark icon on the post. Bookmarked posts collect in the user's Bookmarked feed view, accessible from the left navigation in the Chatter tab. The feature serves a similar role to favourites or saved-posts on other social platforms: a private list of feed content the user wants to find again. Bookmarks are personal; no one else sees which posts a user has bookmarked. Chatter Bookmarks matter because Chatter feeds can move fast in active organisations, and important posts scroll off the top of the feed within hours. Bookmarking is the lightweight personal-curation mechanism that lets a user save announcements, useful Q&A threads, or reference posts for later reading. The feature is less prominent in modern Lightning Chatter than it was in Classic Chatter, where the Bookmarks tab was a primary navigation item. In Lightning, the feature still exists but lives behind the feed filter dropdown. Reading any Salesforce documentation about Chatter productivity, treat Chatter Bookmarks as one of several lightweight personal organisation features alongside Chatter Favorites and Topic following.

Chatter Favorite is the Salesforce feature that lets users save records, list views, Topics, or Chatter posts as personal favourites for quick access from the Favorites menu in Lightning Experience. The Favorites menu appears in the top navigation bar; selecting a saved favourite navigates the user back to that record, list view, or filtered feed. Where Chatter Bookmarks save Feed Items specifically, Chatter Favorites saves broader entities including Accounts, Opportunities, Cases, custom-object records, list views, and Chatter Topics. Chatter Favorites matter because Salesforce users navigate to the same records repeatedly: their top accounts, the dashboard they check daily, the list view they use to triage cases. Without Favorites, every navigation requires search or app-launcher clicks. With Favorites, the top navigation surfaces the user's most-used destinations one click away. Lightning Experience replaced the legacy Chatter Favorites tab (Classic Chatter) with the Favorites menu in the global header; the feature is more useful in the modern surface because it covers more entity types and integrates with the navigation bar that users already look at constantly.

The Chatter Feed is the Salesforce social timeline that displays posts, comments, files, links, questions, and system-generated record updates relevant to a user, a record, or a group. Each post is a Feed Item that links to its author, its parent context, and the people who have liked, commented on, or @mentioned others within it. The feed surfaces on the Chatter tab as the user's personal What I Follow feed, on every record's Activity timeline (the record-specific Chatter feed), and inside Chatter Groups (the group-specific feed). The Chatter Feed is the core social-collaboration surface of Salesforce. Chatter Feed matters because it is how internal communication happens around records in Salesforce. Sales reps post updates to an Opportunity's feed and the manager sees them in their What I Follow stream. Service agents log notes on a Case feed and the customer (if they have access through Experience Cloud) sees the response. Group feeds host project-team discussions. Chatter is Salesforce's answer to the question of how cross-functional teams collaborate around CRM data without leaving the platform. The feature has waned in prominence as Slack integration has grown, but Chatter Feed remains the canonical record-level conversation surface in Salesforce.

A Chatter Group in Salesforce is a shared collaboration space with its own membership, feed, files, and post-permission rules. Groups host project teams, topic-focused communities, customer-facing partner groups, and any structured discussion that benefits from being separate from the global Chatter feed. Each group has Public, Private, or Unlisted visibility, owners and managers, and members. The group feed is where the team posts, files get shared, and ongoing conversation accumulates. Salesforce supports both internal-only groups and groups that include Experience Cloud partners or customers. Chatter Groups matter because most cross-functional work in Salesforce benefits from a focused space. A global What I Follow feed drowns in noise; a project-specific Chatter Group filters out everything but the project's conversation. Owners moderate membership and posts, managers help with curation, and members contribute. Groups have largely been overtaken by Slack channels in organisations that have adopted Slack as the primary collaboration tool, but Chatter Groups remain useful for record-anchored team work that does not need a separate Slack channel. The right pattern depends on the org's collaboration culture and Slack adoption.

Chatter Mobile was the standalone iOS and Android app Salesforce provided to give users access to their Chatter feed, posts, files, and notifications on a phone or tablet. It launched in 2010 alongside the original Chatter rollout and ran as a separate app from the broader Salesforce Mobile App (then called Salesforce1, later renamed Salesforce Mobile). Chatter Mobile let users post to feeds, like and comment, access groups, and view records from a stripped-down mobile UI optimised for Chatter consumption rather than full CRM work. Chatter Mobile is now legacy. Salesforce consolidated Chatter functionality into the unified Salesforce Mobile App between 2014 and 2018; the standalone Chatter Mobile app was retired from app stores. Modern Salesforce users access Chatter through the Salesforce Mobile App's Chatter tab, which provides the same feed, post, like, comment, file, and group functionality plus full record access. The phrase Chatter Mobile appears in pre-2018 Salesforce documentation and partner training material; current documentation refers to the Salesforce Mobile App or the Mobile Chatter experience without using the legacy product name.

Checkout in Salesforce Commerce is the multi-step flow that turns an active shopping Cart into a placed Order: collect billing address, collect shipping address (if needed), select shipping method, accept payment, run fraud screening, validate inventory, and finalise the Order record. The Checkout flow is the highest-stakes part of any e-commerce surface; abandonment here directly reflects lost revenue. Salesforce B2B Commerce and B2C Commerce both implement Checkout as a configurable multi-step Lightning Flow plus the Cart Calculator integrations behind it. Checkout matters because every shopper passes through it before becoming a customer. Friction in the flow drops conversion; smoothness compounds revenue. Salesforce's Checkout architecture lets admins customise the steps, the payment integrations, the shipping options, and the post-checkout actions while inheriting the platform's order creation, tax calculation, and inventory integration. Modern Checkout flows typically integrate with PayPal, Stripe, or a similar payment processor; with Avalara or Vertex for tax; and with a carrier API for shipping rates. Bringing these third-party services into the Checkout flow without slowing the shopper is the operational design challenge.

A Child Relationship in Salesforce is the schema connection from a parent object back to a child object that references it through a lookup or master-detail field. Where the parent-to-child reference is just a lookup field on the child, the Child Relationship is the metadata that lets you walk from the parent record back to its many children. SOQL exposes this through the Child Relationship Name: SELECT Id, (SELECT Id FROM Cases) FROM Account walks from Account to its Case children. Apex describes the relationship through DescribeFieldResult's getRelationshipName method. Reports use it to join parent and child for multi-level data display. Child Relationships matter because they make parent-side traversal possible. Without them, code could find a Case's Account but not an Account's Cases (except via SOQL on Case filtered by AccountId, which is awkward). With them, the schema is bidirectional in practice. Each lookup or master-detail field automatically generates a Child Relationship Name; admins customise the name on the field definition. Most production schemas inherit defaults; sophisticated apps customise names to make code and reports more readable. The Child Relationship Name appears throughout SOQL subqueries, related lists, dynamic Apex, and metadata references.

A Claim in Salesforce is the standard insurance industry object that represents a policyholder's request for payment, repair, or benefit under an active Insurance Policy. The object lives in Financial Services Cloud Insurance and Salesforce Industries Insurance solutions, with fields for Claim Number, Policy, Claimant (the Person Account or Insured Entity making the claim), Loss Date, Loss Type, Status, Reserve Amount, Paid Amount, and links to associated Claim Items, Claim Participants, and Claim Documents. Claims pass through a lifecycle (Submitted, Acknowledged, Under Review, Approved, Settled, Denied, Closed) tracked through standard status fields plus custom milestone records. Claims matter because they are the moment of truth for any insurance carrier. The claim experience defines customer perception of the brand; speed, accuracy, and empathy through the claim lifecycle determine renewal rates and word-of-mouth. Salesforce Industries Insurance gives carriers a unified Claim record that ties to the Policy, the policyholder, the adjusters working it, third-party participants (witnesses, body shops, medical providers), and the financial reserves and payouts. The model integrates with policy administration, finance, and customer-service workflows so the claim file is the single source of truth across the carrier's operation.

Classic Email Templates are the legacy Salesforce email template format introduced in Salesforce Classic, supporting four template types: Text (plain-text emails), HTML (with Letterhead), Custom HTML (without Letterhead), and Visualforce (templates rendered through a Visualforce page). Each Classic Email Template is a metadata-managed record under Setup, Email, Classic Email Templates with merge field support for inserting record fields into the email body. Users select a Classic Email Template from the email-sending action (Send Email button, Mass Email, Workflow Email Alert, Approval Process action) when composing outbound mail. Classic Email Templates predate Lightning Email Templates, which launched alongside Lightning Experience with a richer authoring UI, sharing across users, and inline image support. Both template types coexist in modern orgs; Classic Email Templates remain available for Email Alerts (workflow rules and approval-process actions still use them) and for orgs that have not migrated authoring to Lightning. Most new email authoring uses Lightning Email Templates; Classic Email Templates persist where automation infrastructure references them. Reading any contemporary Salesforce documentation, distinguish Classic Email Templates (legacy four-type model with Letterheads) from Lightning Email Templates (modern unified authoring).

Classic Letterheads in Salesforce are the legacy branded header-footer wrappers that HTML Classic Email Templates used to apply consistent visual branding across outbound emails. Each Letterhead is a metadata record under Setup, Email, Classic Letterheads that defines a header (logo, banner image, top section), a footer (legal text, social links, opt-out instructions), and the colour palette and font defaults that wrap the email body. HTML Classic Email Templates link to one Letterhead; the Letterhead's wrapper renders around the template's body content at send time. Classic Letterheads have been deprecated since 2021. Salesforce stopped enabling Letterheads for new orgs and moved branded-email capability into Lightning Email Templates with Email Branding (a Lightning-era replacement that uses Builder UI instead of HTML editing). Existing Letterheads still work in orgs that had them; new orgs do not see the Letterheads UI. Reading any contemporary Salesforce documentation, treat Classic Letterheads as a legacy feature; modern email branding uses Lightning Email Template branding instead. The Workflow Email Alert dependency on Classic templates (which often reference Letterheads) is the main reason Classic Letterheads persist in many production orgs.

A Client App in Salesforce is any external software application that authenticates against Salesforce and uses the platform's APIs to read or write data. Client Apps include mobile apps (the Salesforce Mobile App, custom mobile apps built on the Mobile SDK, third-party iOS or Android apps), web apps (Marketing Cloud Engagement, custom integrations, partner-built portals), backend services (ETL pipelines, billing systems, data warehouses), and command-line tools (Salesforce CLI, custom scripts). Each Client App registers as a Connected App in Salesforce; the registration carries the OAuth Client ID, Client Secret, allowed scopes, and IP restrictions. Client Apps matter because every external integration with Salesforce is one. The Connected App registration is the platform's mechanism for managing who can call the APIs, with what permissions, under what restrictions. Production Salesforce orgs typically have dozens of registered Client Apps representing every external system that touches the platform. Mature programs audit Client Apps annually, rotate secrets routinely, and apply IP restrictions where the integration runs from known addresses. The Client App concept spans every Salesforce SDK and integration pattern; understanding it is foundational to anything beyond the standard Salesforce UI.

The Clinical Data Model in Salesforce Health Cloud is the FHIR-aligned schema of objects, fields, and relationships that represent patient clinical information: encounters, conditions, observations, medications, allergies, procedures, immunizations, lab results, and the patient's overall health profile. Health Cloud ships dozens of standard objects (Clinical Encounter, Condition Detail, Observation, Medication Statement, Allergy Intolerance, Procedure) that map closely to HL7 FHIR resource definitions, making integration with EHR systems and health information exchanges much smoother than a custom schema would allow. The Clinical Data Model matters because healthcare integration is constrained by interoperability standards. FHIR (Fast Healthcare Interoperability Resources) is the dominant standard for exchanging clinical data; aligning the Salesforce data model to FHIR resource shapes lets Health Cloud customers integrate with EHRs (Epic, Cerner, Meditech, athenahealth) and HIEs without building bespoke mapping layers. The data model also supports Care Plans, Care Programs, and the broader Health Cloud workflow stack, giving care coordinators, clinicians, and patient-facing surfaces a unified view of clinical information that respects the standards the rest of the industry has adopted.

Clone in Salesforce is the action of creating a copy of an existing record (or metadata component) with most or all of the field values pre-populated from the source. The Clone button appears on most standard and custom object record pages; clicking it opens the New Record form pre-filled with the source record's values, allowing the user to adjust and save the copy. Clone applies to records (Account, Opportunity, Contact, Case, custom objects), to certain metadata (page layouts, validation rules, flows, profiles), and to specific Salesforce constructs (Quote line items, Opportunity Products, Flow versions). Clone is one of the most-used micro-actions in daily Salesforce work. Reps clone Opportunities for renewal cycles, clone Quotes for revisions, clone Cases for related issues. Admins clone Permission Sets to derive variants, clone Flow versions to safely edit, clone profile-based page layouts to start customization. The mechanism is simple but the behavior around relationships, lookup fields, and child records is nuanced; understanding what gets copied and what does not is what separates productive clone usage from accidental data duplication.

Cloud Computing in the Salesforce context is the architectural and commercial model that delivers software through a multi-tenant cloud service rather than as on-premise installed software. Salesforce was the first major Software-as-a-Service (SaaS) CRM, launched in 1999 explicitly to challenge the install-and-maintain model that dominated enterprise software at the time. The platform runs on Salesforce-managed infrastructure, customers access it through a browser or API, upgrades happen three times per year automatically, and pricing follows a per-user-per-month subscription rather than a perpetual licence. Cloud Computing matters as the foundational Salesforce concept because it shapes everything else: the multi-tenancy model influences governor limits, the SaaS delivery shapes the three-times-yearly release cadence, the API-first architecture enables every integration, the cloud-native data residency drives international compliance posture. Every product Salesforce ships (Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud, Data Cloud, Agentforce) runs on the same multi-tenant cloud platform. Understanding the cloud-computing context is foundational to understanding why Salesforce is shaped the way it is; the constraints and capabilities all trace back to the cloud model.

Code Coverage in Salesforce is the percentage of Apex code (triggers and classes) exercised by the org's Apex unit tests when those tests run. Salesforce calculates coverage by tracking which executable code lines each test method touches and dividing by the total number of executable lines across all production code. The platform enforces a 75 percent overall coverage threshold for production deployments: any deploy that drops org-wide coverage below 75 percent fails with a coverage error. Individual triggers must hit at least 1 percent coverage. The rules are platform-enforced; they exist to ensure deployed code has been minimally tested. Code Coverage matters because it is the only platform-enforced quality gate Salesforce applies to Apex. Without it, untested code could ship to production routinely. With it, every Apex change forces the developer to write at least minimum tests. The 75 percent threshold is widely criticised as too low to guarantee real quality; a class with 100 percent coverage and no assertions still passes the gate. Mature teams target 85 to 95 percent coverage with meaningful assertions, treating the platform's 75 percent as a floor rather than a target. Code Coverage shows up at production deploy time, in the Apex Test Execution page, and in the Code Coverage Setup page that lists coverage per class.

A Collapsible Section is a Lightning record page or page layout container that users can expand and collapse to show or hide its child fields and components. The admin marks a section as collapsible at design time; users see a chevron icon on the section header that toggles visibility. Collapsed sections persist per user (the page remembers which sections each user keeps collapsed), so reps configure their own visual default once and the page respects it across visits. Collapsible Sections exist to manage information density on record pages with many fields. A standard Account page can hold dozens of fields across multiple sections (Account Information, Address Information, Account Details, System Information, Custom Fields). Without collapsible sections, every record load shows everything; with them, users collapse the sections they rarely need and focus on the data that drives their daily work. The default-collapsed setting is the admin's hypothesis about what most users want; users override per their preference and the page adapts.

A Combination Chart in Salesforce reports and dashboards is a chart type that overlays multiple data series in different visual forms on one chart canvas: a bar series for one metric, a line series for another, sometimes a second Y-axis for series with very different scales. The chart type lets analysts show related but differently-shaped metrics in a single view: bookings (bar) against win rate (line), pipeline volume (bar) against average deal size (line), case volume (bar) against CSAT (line). Combination Charts work in both Salesforce Reports (Lightning report builder) and on dashboards. Combination Charts matter because not every story is one metric. Sales managers want to see bookings alongside conversion rate, service leaders want to see case volume alongside customer satisfaction, marketers want to see lead volume alongside lead quality. Forcing each into its own chart breaks the visual connection between related metrics; a Combination Chart preserves the connection by overlaying them. The dual Y-axis option (when the two metrics have very different scales) is what makes the overlay readable; without it, the line series can disappear into the bar series's vertical range. Modern Salesforce report and dashboard builders support Combination Charts as standard chart types with intuitive configuration.

A Comment in Salesforce is a textual note attached to a parent record, typically used to capture updates, status notes, or contextual annotations that do not belong in a structured field. The most common Comment object is CaseComment (notes added to a Case during resolution), but Salesforce ships several Comment-style objects: CaseComment, IdeaComment (on legacy Ideas), FeedComment (on Chatter Feed Items), Solution comments, and custom Comment objects on partner packages. Each Comment captures the author, the timestamp, the body text, and the parent record reference. Comments are queryable, reportable, and often surfaced inline on the parent record's UI. Comments matter because they capture the conversational layer of Salesforce work. A Case's structured fields tell what happened; the CaseComments tell why it happened, what the agent tried, and what the customer said. Without Comments, the audit trail loses the narrative; with them, the next agent reading the Case understands the full context. Salesforce's modern Service Console surfaces CaseComments prominently in the Case feed; Chatter FeedComments behave similarly for Chatter posts. The Comment pattern persists across many objects because the use case (free-text annotation with author and timestamp) is universal in CRM and service work.

A Chatter Comment is a reply added to a Salesforce Chatter Feed Item: the comment thread under a post, the response to a Chatter Question, or the agent's note added to a Case feed. Stored as FeedComment records, each Chatter Comment carries the comment body, the parent Feed Item, the author, the timestamp, and any @mentions, attachments, or rich text formatting. Comments are how Chatter conversations actually happen; without them, every post stands alone with no way for the team to discuss or build on it. Chatter Comments matter because they are the granular unit of Chatter engagement. Likes signal acknowledgement but carry no information. Comments contribute substance: questions, clarifications, decisions, follow-ups, agreement, disagreement. The Best Answer mechanism on Chatter Questions marks one Comment as the canonical answer. Engagement metrics (Comment count per post, average response time, top commenters) trace community health. Modern Chatter UIs render Comments inline with the parent post, support @mentions to notify users, and let authors edit or delete their own Comments. The pattern is the same across Service Cloud Case feeds, Chatter Group feeds, and Experience Cloud Q&A surfaces.

Commerce Cloud is Salesforce's product family for running e-commerce: storefronts, product catalogues, pricing, promotions, carts, checkout, orders, and the surrounding integrations with payment, tax, shipping, and inventory systems. The family includes B2C Commerce (consumer-facing storefronts), B2B Commerce (business-to-business commerce on the Salesforce Platform), Order Management (post-purchase fulfilment), and adjacent capabilities like Payments, Marketing-driven personalization, and integration with Service Cloud for customer service. Salesforce acquired Demandware in 2016 to form the B2C Commerce backbone; B2B Commerce evolved natively on the Salesforce Platform. Commerce Cloud matters because e-commerce is increasingly central to most consumer and many business-to-business companies. Salesforce's positioning is to unify commerce with the rest of the customer record (marketing, service, sales) so the shopper experience is consistent across channels. The B2C Commerce platform handles high-traffic consumer storefronts with sophisticated personalization. The B2B Commerce platform handles complex buyer-organisation purchase flows with role-based pricing and approval workflows. Both share the same Cart, Order, and Customer concepts; both integrate with Marketing Cloud, Service Cloud, and Data Cloud through the broader Salesforce stack.

Commerce Cloud Einstein is the AI feature set inside Salesforce Commerce Cloud that drives product recommendations, predictive search, personalized sort, content recommendations, and commerce insights for B2C and B2B storefronts. The features run on shopper behavior data (clicks, views, carts, purchases) plus catalog metadata, surface inside the standard storefront templates without custom code, and feed analytics back into Commerce Cloud reports. The point is to raise conversion and average order value through personalization the merchandiser would not have time to build by hand. Commerce Cloud Einstein is not one product but a bundle that ships with Commerce Cloud at most editions. The most-used features are Einstein Product Recommendations (cross-sell, also-bought, recently-viewed), Einstein Predictive Sort (reorders category listings by per-shopper relevance), and Einstein Search Recommendations (suggests searches and ranks results). The newer Commerce Agentforce builds on the same data foundation to add conversational shopping. Together they form the personalization layer most B2C storefronts run today.

A Commerce Cloud Storefront is the customer-facing website built on Salesforce Commerce Cloud where shoppers browse the catalog, add to cart, and check out. The Storefront is the visible surface of the commerce platform: the homepage, product detail pages, category pages, search results, cart, and checkout flow. B2C Commerce Storefronts run on SFRA (Storefront Reference Architecture) or a custom theme; B2B Commerce Storefronts run on Experience Cloud-based templates. Both inherit branding, content, and SEO configuration from the underlying Commerce Cloud setup while exposing the catalog and cart through the shopper UI. Commerce Cloud Storefronts matter because they are where every commerce decision becomes shopper experience. Catalog quality determines findability; pricing rules determine perceived value; promotion configurations determine conversion; checkout design determines abandonment. The Storefront integrates with Marketing Cloud for personalisation, Service Cloud for post-purchase support, Data Cloud for unified customer profile, and Payment processors for transactions. Modern Storefronts increasingly run headless (custom React/Vue/mobile front-end calling Commerce Cloud APIs) for full design control; the platform supports both stock-theme and headless models. Performance, SEO, accessibility, and mobile-responsive design are the design disciplines that determine a Storefront's commercial success.

Commit Amount is the Collaborative Forecasts column that shows the forecast value rolled up from Opportunities in the Commit forecast category, summed across a user's pipeline and any reports rolling up beneath them. Commit is the conservative number sales reps are willing to put their name on; it sits between the closed-won total (already booked revenue) and the Best Case total (deals likely but not certain). Sales leadership treats Commit as the floor of the quarter's expected close; missing Commit is a material risk that triggers urgent intervention. Commit Amount is calculated by mapping each open Opportunity's Stage to its Forecast Category, summing the Amount of every Opportunity whose Forecast Category is Commit for the relevant period and ownership, then applying any forecast adjustments. The Commit column on the Forecasts tab and the matching ForecastingItem record both expose the value. Reps and managers can manually override the calculated Commit through forecast adjustments. The discipline of what counts as Commit (which Stages map to it, how rigorously adjustments are made) is one of the most consequential sales operations decisions any org makes; it directly shapes how leadership interprets pipeline health.

A Community Application is a Salesforce site that exposes a controlled slice of org data and functionality to external users through a branded portal. It runs on the Experience Cloud platform, renamed from Community Cloud in 2021, and is built from a template (typically Lightning Web Runtime, Aura, or a legacy Visualforce theme) that ships with pages, navigation, and a theme already wired to Salesforce records. The external users who sign in are not standard internal Salesforce users. They hold one of the external license types (Customer Community, Partner Community, or their Plus and Login variants), and their record access is governed by a separate sharing model built around their Account or Contact. A single Salesforce org can host multiple Community Applications, each pointed at a different audience with its own URL, branding, and login flow.

A Community Expert is a user designated by a site admin to appear as a verified knowledge holder within a Salesforce Experience Cloud site. The badge sits next to the user's name in feed posts, question threads, and member profiles, and signals to other members that this person's answers carry more weight than a typical reply. The designation is set per site, not per org, so the same internal user can be marked an expert in one customer portal and a regular member in another. Experts are usually a small group: top-performing support agents, recurring contributors from a partner firm, or product owners who answer questions in their own domain. The role does not grant any additional record access or permissions. It is a recognition layer that shapes how other members perceive that user's contributions in the community feed.

Company Information is the Salesforce Setup page that holds the org's identity and global configuration: organization name, primary contact, default time zone, currency, locale, language, fiscal year settings, edition, user license counts, used storage, API request counts, and the Organization ID. It is the org's identity card; the values here cascade to nearly every other feature (currency defaults on Opportunities, time zone defaults on scheduled jobs, fiscal year boundaries on reports and forecasts). Company Information is one of the least-edited Setup pages but holds some of the most consequential settings. Changing the default currency, the time zone, the fiscal year start, or the multi-currency toggle is rare but high-impact when it happens; the change ripples through historical data, reports, dashboards, and any automation that depends on date or currency math. Most orgs configure this page at go-live and never revisit; the maintenance audit is more about confirming the values still match reality than about active editing.

A Competitor in Salesforce is a child record on an Opportunity that names another company chasing the same deal, along with optional notes about that company strengths and weaknesses. The records live on the OpportunityCompetitor object and surface as a related list on the Opportunity page layout. The point of tracking competitors at the deal level is to give the sales team a snapshot of the bidding field and to feed win/loss analysis once the Opportunity closes. Reports built on OpportunityCompetitor can answer questions like which competitor we lose to most often, which industries trigger which rival, and whether deals with competitor X tend to close at smaller amounts. The structure is simple by design: a free-text Competitor Name plus strengths and weaknesses fields, which is what makes it easy for reps to populate and easy for sales operations to slice.

Complaint Management is a Salesforce feature set, primarily packaged with Financial Services Cloud and adjacent regulated-industry clouds, that gives an organization a structured way to log, categorize, investigate, and resolve customer complaints under audit. It centralizes the complaint record on a dedicated object (the standard Complaint object in newer FSC releases, a custom Complaint__c object in older deployments) and links it to the customer Account, the related products or services, and any agent investigation that follows. The feature exists because complaint handling in regulated industries (banking, insurance, healthcare, telecommunications) is not just customer service. It is a compliance obligation with statutory time limits, mandatory categorization, and regulatory reporting requirements: CFPB in the US, FCA in the UK, MiFID II for investment products, and similar regimes elsewhere. Stock Salesforce Cases handle the customer touch points, but they do not enforce the structured fields, escalation timers, and audit trails that a complaint demands. Complaint Management adds those layers on top.

Compliance BCC Email is the Salesforce Setup feature that automatically blind-carbon-copies every outbound email sent through Salesforce (case emails, sales emails, mass emails, Email Alerts from automation) to a specified compliance archival address. The address typically belongs to an email archival system (Microsoft Purview, Mimecast, Smarsh, Global Relay, Proofpoint) that retains all corporate email for regulatory or legal hold purposes. The user sending the email does not see the BCC; the archive captures the message silently. Compliance BCC Email exists because regulated industries (financial services, healthcare, legal, government) commonly need to capture every outbound business communication for retention and supervisory review. Salesforce-sent emails are part of that business communication; without Compliance BCC, they would bypass the archival system. The feature is one of the cheapest compliance wins: a single Setup configuration plus a mailing list at the archival side captures every Salesforce-sent email forever.

Compliant Data Sharing is the Salesforce sharing model designed for regulated industries (financial services, healthcare, government) that need explicit, audited record sharing with attestation, expiration, and supervisory controls. Unlike standard sharing (which grants visibility through sharing rules, role hierarchy, manual share, or team membership and persists silently), Compliant Data Sharing requires a Participant record explicitly granting access, optionally with an expiration date, optionally with an attestation clause the recipient acknowledges, and always with a full audit trail of who granted what to whom when. The model exists because regulated workflows need to prove who could see what data and when. Financial Services Cloud and Industries Cloud editions ship Compliant Data Sharing for objects like Financial Account, Account-Account Relationship, and custom industry objects. The pattern is heavier than standard sharing but produces the compliance evidence regulators expect during examinations. Most non-regulated orgs do not need it; the orgs that do need it cannot operate without it.

The Component Reference for Visualforce is Salesforce published catalog of every standard Visualforce tag, organized by namespace (apex, chatter, knowledge, liveAgent, and others) with each tag attributes, types, defaults, and sample markup. Developers consult it when building Visualforce pages to confirm which tag to use, which attributes it accepts, and how it nests with other tags. The reference lives on the Salesforce developer documentation site and ships alongside the Visualforce Developer Guide. It is the source of record because Visualforce is a closed tag library; you cannot invent new apex namespace tags, only use the ones Salesforce ships. The reference has been effectively frozen since around 2018, when Salesforce moved most new investment into Lightning Web Components. Visualforce-specific bug fixes and an occasional new attribute still appear in release notes, but the tag list itself rarely changes.

A Composite App is a Salesforce architecture pattern where one application combines native Salesforce code (Apex, LWC, Flow, page layouts) with external functionality (a third-party web app, a Canvas-rendered service, a microservice called through External Services, or a Heroku-hosted process). The user sees a single experience inside the Salesforce UI, but the runtime crosses platforms. Composite App is one of three Salesforce architecture archetypes alongside Native App (everything runs on the Salesforce platform) and Web App (everything runs externally and uses Salesforce only as an API). It is the pattern most large enterprises end up with, because few real applications fit cleanly into one bucket: customer data lives in Salesforce, AI inference runs on a Python service, billing lives in a SaaS, and the user wants one screen that pulls from all of them.

Computer-Telephony Integration (CTI) is the bridge between a phone system and Salesforce that lets a service or sales agent place, receive, and log calls without leaving the Salesforce interface. The phone provider supplies a JavaScript adapter built on the Open CTI framework, the adapter renders a softphone inside the Salesforce console, and call events (ringing, answered, hung up) push data into Salesforce objects in real time. CTI replaces the older world of a separate desk phone plus a Salesforce browser tab where the agent typed in everything manually. With CTI wired up, an incoming call triggers a screen pop that opens the caller Contact or Account record, the call duration and outcome auto-log to a Task or Voice Call record, and outbound calls fire from a click-to-dial link next to the phone number on any record. Salesforce ships its own first-party CTI through Service Cloud Voice, and a long roster of third-party providers (Five9, Talkdesk, Genesys, RingCentral, Amazon Connect, Dialpad, NICE inContact) plug into the same Open CTI framework.

A Connected App is a Salesforce configuration that registers an external application or integration with the platform's identity and OAuth infrastructure. It is the bridge that lets a mobile app, web service, or third-party tool authenticate users into Salesforce, make API calls on their behalf, and stay within the security boundary the admin has approved. Every modern integration with Salesforce (custom mobile apps, AppExchange packages, Slack workspaces, MuleSoft instances, ETL tools, Pub/Sub API clients) is fronted by a Connected App. A Connected App holds the OAuth client ID and secret, the allowed OAuth scopes (api, refresh_token, full, web, openid, custom_permissions), the callback URLs for redirect-based flows, and the user-access policies (admin-approved versus self-authorized). It also controls IP relaxation rules, session policies, and certificate-based authentication for the JWT bearer flow. Connected Apps are the centerpiece of Salesforce identity and access management for anything outside the Salesforce-built UI; every API token in production traces back to one.

Connected Apps OAuth Usage is the Salesforce Setup page that surfaces operational visibility into OAuth-based access to the org: every Connected App that has authorized users, the count of users who have authorized each app, the count of active OAuth sessions per app, and the usage volume (API requests, total requests, error rates). The page is the audit and monitoring surface for any integration, mobile app, or third-party tool that authenticates to the org through OAuth. Connected Apps OAuth Usage exists because OAuth proliferation is silent. Every app a user authorizes (Salesforce Mobile App, third-party tools, custom integrations, AppExchange products) creates an authorization persistent until revoked. Without visibility, orgs accumulate dozens of Connected Apps with active sessions from former users, unused apps, or compromised authorizations. The page is the visibility layer; the operational discipline around it (regular review, deauthorize unused, block compromised) is what turns visibility into security.

A Connected User in Salesforce is a user record that has authorized access to one or more Connected Apps through OAuth, meaning the user has explicitly granted an external application (mobile app, integration tool, third-party service) permission to act on their behalf in the org. The connection persists until the user revokes the authorization, the admin blocks the Connected App, or the OAuth session expires per the configured token lifetime. Connected Users are visible per-Connected-App in the OAuth Usage page and per-user in the user's Personal Settings. The term shows up most often in two contexts: security audits (which users have connected which apps, and are any of those connections stale or compromised) and offboarding (when a user leaves, every Connected User authorization they held needs explicit revocation, because user deactivation does not automatically revoke OAuth tokens). Connected User management is one of the underappreciated security disciplines in mature orgs; the authorizations accumulate silently and become liabilities when not actively pruned.

A Connection (for Salesforce to Salesforce) is the named, configured link between two separate Salesforce orgs that lets them share specific records with each other. Each org administers its own side of the connection, controlling which objects and fields it publishes to the partner and which it subscribes to from the partner. The shared records remain in each org own database, but updates propagate between orgs through the connection. Salesforce to Salesforce (often abbreviated S2S) was designed for partner-collaboration scenarios: a manufacturer sharing leads with a channel partner, a regional org sharing service cases with a global HQ org, or two divisions of the same company that ended up on separate Salesforce orgs after an acquisition. The Connection record is the unit of administration; each org typically has a small number of Connections to specific partner orgs rather than a broad share to everyone.

A Console Layout in Salesforce defines the UI configuration of the Service Console (and adjacent agent-console experiences): which primary tabs appear, which sub-tabs open inside a primary, which utility-bar items are available, which Lightning components render in the sidebar, and which Highlights Panel fields show at the top of each record type. The Console Layout sits alongside the Page Layout (which controls fields on the record body) and the App configuration (which controls navigation and apps). It is the layout type specific to console-style workflows where agents work multiple records simultaneously in a tabbed interface. Console Layouts exist because agent-console workflows have different UX requirements from standard record pages. A service agent juggling 5 open cases needs Highlights at the top, sidebar tools, utility bar items for quick actions, and tab management; a sales user viewing one Opportunity at a time needs a simpler layout. The console layout is where admins design the agent experience deliberately for the multi-tab pattern.

Console Settings is the org-wide Setup area that controls global behavior of the Lightning Service Console and related console-style apps: keyboard shortcuts, tab behavior (reopen tabs on restart, tab limit, sub-tab behavior), push notification preferences, console-wide custom branding, and the enable/disable toggle for specific console features like Macros, Quick Text, and the Recent Items component. Console Settings sits at the org level; per-app Console Layout configuration sits at the app level. The two work together to produce the agent console experience. Console Settings exists to centralize org-wide console behavior so admins do not configure the same option on every console app. Enabling Reopen Tabs on Restart, setting the maximum primary tab count, configuring keyboard shortcuts apply org-wide. Per-app variations (which utility bar items appear in this console) live in the Console Layout. Most admins touch Console Settings once at console rollout and revisit only when adding console features that surface here.

A Console Tab in Salesforce is one of the individual tabs that appear at the top of a Service Console or Sales Console app, each representing an open record or workspace. The console interface is built around the idea that an agent often needs several records open simultaneously, so the app holds them as parallel tabs rather than forcing a back-and-forth navigation through individual record pages. The tab system has two levels. Primary tabs hold the main record an agent is working on (a Case, an Account, an Opportunity). Subtabs hold related records opened from inside a primary tab (the Contact who owns the Case, an attached Order). Subtabs stack underneath their primary, and closing the primary closes all its subtabs together. The structure mirrors a one-customer-many-related-records-open workflow that is common in support and sales.

A Consult Call in Salesforce is a feature in Service Cloud Voice (and many third-party CTI adapters) that lets an agent step away from an active customer call to consult a colleague before deciding what to do next. The customer is parked on hold while the agent dials the consult party (a supervisor, a subject expert, an external number), discusses the issue, and then returns to the customer, transfers them, or merges both into a three-way conference. The Consult Call workflow exists because cold transfers are bad customer experience. Without the consult, an agent would either guess at the right person to send the customer to, or transfer blind and hope the receiving party answers prepared. With Consult Call, the agent confirms availability and briefs the recipient before the customer ever hears them. The mechanic is standard across modern contact center platforms, and Salesforce surfaces it natively in Service Cloud Voice and through Open CTI adapters.

A Contact is a person record in Salesforce, almost always tied to one Account through an AccountId field. Contacts hold the name, title, email, phone, and contact preferences for an individual you do business with. Cases reference Contacts. So do Activities. Opportunities take it a step further with Contact Roles to identify each person's part in a deal. Most customer-facing communication in a Salesforce org gets tracked against a Contact, which is why Contact hygiene tends to be the single biggest input into the perceived quality of the system. The Contact object is where the bulk of an org's regulated personal data lives. Email addresses, phone numbers, names, postal addresses. Most of what GDPR, CCPA, and the rest of the world's privacy regimes care about sits on Contact rows. That fact shapes a lot of decisions about Contact records that look mundane on the surface: who can see them, how they get deleted, how merges work, what fields are masked in sandboxes. If your data-protection team has not weighed in on how Contacts work in your org, that is your first project.

A Contact Role in Salesforce is a junction record that names the part a Contact plays in relation to another record, most commonly an Opportunity but also Accounts, Contracts, Orders, and Cases. The Contact itself does not change; the Contact Role is metadata about how that Contact participates in the parent record. On an Opportunity, a Contact Role might mark someone as Decision Maker, Evaluator, or Economic Buyer. On an Account, it captures relationship types like Primary Contact or Technical Contact. The mechanic exists because real-world business relationships are many-to-many. A single Contact can be a Decision Maker on one Opportunity and an Influencer on another. A Contact can be the Primary Contact for two different Accounts (a subsidiary and a parent company). Without Contact Roles, sales teams have to invent custom fields or junction objects for stakeholder mapping. With them, Salesforce ships a structured way to record who matters for which record and what they do.

Contact Roles on Opportunities is the Salesforce feature that lets sales teams attach Contacts to an Opportunity record with a defined role (Decision Maker, Champion, Economic Buyer, Influencer, and others) and a Primary flag. The data lives in the OpportunityContactRole standard object, surfaces as a related list on the Opportunity page, and powers stakeholder mapping reports and sales-methodology dashboards. Salesforce ships this enabled by default in every edition above Group, with a starter set of role picklist values and a Contact Roles related list on the standard Opportunity page layout. Admins customize the role values to fit their sales methodology and add validation rules or Flow logic to enforce when Contact Roles must be populated. For most sales teams running MEDDIC, MEDDPICC, Force Management, or Challenger, this object is where the methodology data actually lives.

A Content Delivery in Salesforce is a trackable URL generated for a document stored in Salesforce CRM Content (the older document management system) so the document can be shared with an external recipient who does not have a Salesforce login. Each delivery records views, downloads, and the date the recipient last opened the link, giving the sender visibility into how the content is consumed. Salesforce introduced Content Delivery alongside Salesforce CRM Content in 2008 as a structured way to share sales collateral with prospects while tracking engagement. The delivery URL can be password-protected, set to expire on a specific date, restricted to download-only or view-only, and re-issued if the recipient loses the link. The feature still works in modern orgs, but newer document-tracking tools like DocSend, PathFactory, Highspot, Seismic, and Salesforce Files (with its own sharing model) have eclipsed it for most sales-enablement use cases.

A Content Document in Salesforce (ContentDocument in the API) is the persistent parent record that represents a single file in the Salesforce Files framework. The Content Document itself does not hold the binary content. It holds the metadata users see, such as Title, FileType, FileExtension, ContentSize, ContentModifiedDate, OwnerId, the LatestPublishedVersionId pointing at the current Content Version, and the SharingPrivacy flag. The binary lives on child Content Version records, and the file-to-record attachments live on child Content Document Link records. Salesforce introduced Content Document as part of the modern Files framework that replaced the legacy Attachment object around 2014. The shift moved Salesforce from a per-record attachment model (where each file was tied to one parent) to a shared-file model (where one file can be linked to many parents at once and carries its own version history). Content Document is the user-facing identifier that survives across versions; the Content Versions underneath are the actual binary payloads.

A Content Pack is a Salesforce CRM Content feature that bundles multiple Content Documents into a single logical package that can be shared, delivered, and tracked as one unit. The pack itself is a record with a name and description; the bundled documents remain as separate Content Documents underneath. A common pattern is a sales pitch deck plus three datasheets plus a case study, packaged together so a sales rep can send the whole bundle through a single Content Delivery link rather than five separate links. Salesforce introduced Content Packs in 2008 alongside the rest of CRM Content. The feature still works in modern orgs, but the use case has been overtaken by modern sales-enablement platforms (Highspot, Seismic, Showpad) that offer richer packaging, interactive content, and per-document analytics. Content Packs are most often seen in long-running Salesforce orgs that built sales operations around CRM Content before the sales-enablement market matured.

A Content Version in Salesforce (ContentVersion in the API) is the child object in the Salesforce Files framework that holds the actual binary content for one specific version of a Content Document. Each Content Version record contains the file binary data in the VersionData field (stored base64-encoded over the API), along with metadata like Title, FileType, FileExtension, ContentSize, VersionNumber, IsLatest flag, ReasonForChange (free-text explanation), and a parent ContentDocumentId pointing back to the persistent Content Document parent. When a file is first uploaded, Salesforce creates one Content Version record (the initial version, VersionNumber = 1, IsLatest = true) plus its parent Content Document. Subsequent uploads under the same Content Document insert new Content Version records that increment VersionNumber and flip IsLatest on the prior version. Apex and API code that uploads files always inserts Content Version, not Content Document; the platform automatically creates the Content Document parent and the initial Content Document Link to the inserting user.

A Contract in Salesforce is the record that captures a commercial agreement between your company and a customer. The object holds the Account the agreement is with, the Contract Term in months, the Start and End Dates, the Status (Draft, In Approval Process, Activated, Expired, Terminated), an Owner, and any custom fields your org uses to model the commercial terms. Contracts live on the Account record as a related list and are the system-of-record reference that Sales, Legal, Finance, and Customer Success all point at when somebody asks "what did we actually agree to with this customer." Contracts in Salesforce are not legal documents. The signed PDF lives in DocuSign, Conga, Ironclad, Adobe Sign, or whatever contract-lifecycle-management tool your org uses; the Salesforce Contract record is the CRM-side projection of that legal document. Most CLM tools push selected fields back to the Salesforce Contract record after signature, so the platform has the start date, end date, owning account, total value, and renewal terms without anybody manually copying them in. The platform Contract record is your reporting layer; the CLM platform is your legal layer. Confusing the two leads to teams editing Contract fields in Salesforce without realizing the legal document has not changed, which is one of the more common audit findings in enterprise Salesforce implementations.

A Contract Line Item in Salesforce is a child record of a Contract that names a specific product or service covered by that contract, with quantity, unit price, term, and (depending on the implementation) entitlement and billing details. Each Contract Line Item points back to a parent Contract through the Contract field and forward to a Product through the Product2Id field, similar to how an Opportunity Product joins an Opportunity to a Product on the sales side. Contract Line Items exist because most real contracts cover more than one product. A SaaS contract might include the platform license, two add-on modules, and a support tier. Each of those is a separate Contract Line Item under the same Contract. The line items hold the pricing, quantity, and renewal terms specific to each product, while the parent Contract holds the overall term length, customer signature, and account-level metadata. Service Cloud uses Contract Line Items to drive entitlement (which products under this contract are eligible for support), and Revenue Cloud uses them to drive subscription billing.

A Contract (Checkout) in Salesforce Commerce is the contract record created at the end of a B2B Commerce or Subscription Management checkout flow when the purchase involves recurring billing or a multi-period commitment. The checkout captures the line items, pricing, term length, billing schedule, and customer signatures, then writes them to a Contract record (standard or custom) that downstream finance and customer success teams operate against. The pattern exists because B2B Commerce purchases are often not one-shot transactions. A buyer commits to a 12-month subscription, an annual support contract, or a multi-year SaaS deal. The checkout writes the immediate Order, but it also writes the longer-lived Contract that governs renewals, billing cycles, and modifications throughout the term. Salesforce Revenue Cloud and Subscription Management both rely on this pattern; older B2B Commerce orgs sometimes use a custom Contract object instead of the standard.

A Controller Extension is an Apex class that layers extra logic and methods onto a Visualforce standard controller without replacing it. The extension is declared on the Visualforce page tag with the extensions attribute, alongside the standardController attribute. When the page loads, the platform constructs the standard controller for the target object (Account, Opportunity, or any custom object) and then constructs the extension, passing the standard controller into the extension's constructor as ApexPages.StandardController. Extensions exist because standard controllers handle common patterns (load, save, delete, edit) but cannot reach beyond the object's own fields and the user's view state. An extension adds custom action methods, computed properties, related-object queries, and integration hooks. The relationship is composition, not replacement: the standard controller continues to power the save and edit cycle, while the extension supplies whatever the page needs that the platform did not predict.

A Controlling Field in Salesforce is a picklist or checkbox field whose value determines which values are available in a related Dependent Picklist on the same record. The pairing creates a dependent-picklist relationship: when the user picks a value in the Controlling Field, the Dependent Picklist refreshes to show only the values mapped to the chosen controlling value. The pattern reduces user error (the user cannot pick an invalid value combination) and shrinks long picklists into context-aware short ones. A common example: Country as the Controlling Field and State or Province as the Dependent Picklist. The user picks United States, the State picklist shows US states. The user picks Canada, the State picklist shows Canadian provinces. Without the dependency, the State picklist would show every state and province in the world, and users could pick incompatible combinations. Controlling and Dependent fields are an essential data quality pattern for any object with multiple related picklists.

Conversation Designer is the visual bot-building UI inside Salesforce Einstein Bots, the previous-generation conversational AI product that pre-dates Agentforce. It lets admins lay out intents, entities, dialogs, and flow-like branching logic on a canvas, attach them to channels (Messaging, Web Chat, WhatsApp), and configure handoff rules to live agents. The output is a deployable Einstein Bot that classifies user messages, extracts named entities, and walks the conversation through structured dialog steps. Conversation Designer is mostly a legacy surface as of 2026. Salesforce continues to support it, and many orgs still run Einstein Bots in production, but new conversational AI work has moved to Agent Builder and the Agentforce architecture. The two paradigms differ fundamentally: Designer is intent-and-dialog-driven with deterministic branching, while Agentforce is topic-and-action-driven with LLM-based reasoning. Migration is not automatic and most orgs run both side by side during transition.

Conversation Transcript Export is the Salesforce feature that lets administrators export the full text of customer-agent conversations (Live Chat sessions, Messaging conversations, voice call transcripts from Service Cloud Voice) as structured files for compliance archival, analytics, training data, or external system consumption. Each export captures the conversation participants, timestamps, message text, and metadata (sentiment if available, intent classification, agent identity) in a downloadable format. Conversation Transcript Export exists because conversation data is increasingly the most important service-team artifact: regulators want to verify scripts were followed, supervisors want to review agent quality, AI teams want training data for the next iteration of Agentforce, analytics teams want sentiment trends. The standard Salesforce UI shows transcripts one conversation at a time; the Export feature unlocks bulk access. Most regulated service teams configure it as part of go-live; analytics-heavy teams configure it during the first quarter as the value becomes obvious.

Convert in Salesforce refers to the Lead Conversion process: the action that takes a qualified Lead record and turns it into one Account, one Contact, and optionally one Opportunity in a single transaction. The Lead is marked Converted and locked from further edits; the new records inherit the Lead field values through the Lead Field Mapping defined in Setup. Convert is the bridge between the Lead world (where marketing tracks prospects) and the Account/Contact/Opportunity world (where sales runs the pipeline). The process exists because Salesforce treats Leads as suspects (unqualified prospects) and Accounts, Contacts, and Opportunities as known entities (qualified prospects and active customers). The Convert action moves data between the two models without requiring a manual copy. Sales orgs that follow this lifecycle religiously have clean handoff metrics; orgs that skip Convert and instead create Accounts directly tend to have data hygiene problems.

A Cookie in the Salesforce context is a small key-value pair stored in a user browser by Salesforce, an Experience Cloud site, a Salesforce Sites page, or a Salesforce marketing product like Marketing Cloud Account Engagement or Marketing Cloud Engagement. Cookies are how Salesforce maintains the user session across HTTP requests, identifies returning visitors on public-facing sites, remembers preferences, and tracks engagement for marketing analytics. Cookie handling in Salesforce splits into two worlds. Essential cookies (session, auth, CSRF, load balancing) are required for the platform to work and ship enabled. Non-essential cookies (marketing tracking, analytics, personalization) are subject to privacy regulations like GDPR and CCPA and require user consent before they can be set. Salesforce ships the Cookie Consent component for Experience Cloud sites to handle that consent workflow.

CORS (Cross-Origin Resource Sharing) in Salesforce is a Setup configuration where admins allowlist external web origins that the browser is permitted to use when calling Salesforce APIs from JavaScript. Without an entry in the CORS allowlist, browsers block JavaScript code on https://app.example.com from making API calls to https://your-org.my.salesforce.com, even with valid OAuth tokens, because the cross-origin restriction is enforced at the browser level rather than the server level. CORS exists because browsers enforce the same-origin policy by default to prevent malicious websites from reading data from arbitrary other domains using a user logged-in session. Salesforce inherits this. The CORS allowlist tells Salesforce to respond to preflight requests from your trusted origins with the headers that let the browser proceed with the actual request. CORS does not bypass authentication; it complements OAuth and session-based auth by telling the browser that this server is OK with cross-origin requests from this origin.

A Coupon in Salesforce (the Coupon standard object) is a single redeemable discount code issued to a buyer or loyalty member, used by Loyalty Management and Salesforce Commerce to track per-instance discount redemption. Each Coupon record carries a unique CouponCode, a lookup to a parent Promotion (which defines the discount mechanics: percentage off, fixed amount, free shipping, BOGO), an issued-to identifier (typically a Loyalty Member or Account), an EffectiveFromDate and EffectiveToDate that bound validity, a Status (Issued, Redeemed, Expired, Cancelled), and a UsageCount tracking redemption against the parent Promotion max-use rules. Coupons differ from Promotions in scope. A Promotion defines the rule: every customer who applies code SAVE10 gets 10 percent off. A Coupon represents a single instance of that rule: member 12345 was issued code SAVE10-XYZ123, valid through April 30. The per-instance modeling enables precise tracking of who received which coupon, when it was used, and what its lifetime contribution to revenue and engagement was. This is the structure Salesforce Loyalty programs and Commerce promotion engines need to drive personalized discounts.

Coverage in Salesforce describes whether a customer is entitled to receive service or how an insurance policy applies to them, depending on which Salesforce cloud you are looking at. In Service Cloud, Coverage refers to the Entitlement and Service Contract check that runs when a Case is created: does this customer have an active support entitlement, and if so, what SLA milestones apply. In Health Cloud and Insurance Cloud, Coverage is a standard object representing a member enrollment in a health or insurance plan, with effective dates, plan tier, and benefit details. The two senses share an idea: what does this customer have access to and under what terms. Service Cloud coverage drives whether an agent should help and how quickly. Insurance coverage drives whether a claim should be paid and at what level. Both feed reports and dashboards that operations teams use to manage capacity, compliance, and customer experience.

A Credit Memo in Salesforce (the standard CreditMemo object in Revenue Cloud and Salesforce Billing) is a financial document that records a credit issued to a customer, reducing the amount they owe against one or more Invoices. Credit Memos are created when invoiced charges need to be reversed: refunds, billing errors, contract amendments that reduce the customer commitment, returns of physical goods, or post-billing concessions. Each Credit Memo carries a reference to the originating Invoice or Order, a list of Credit Memo Lines for the specific items being credited, and a Total Amount that adjusts the customer balance. Credit Memos exist because billing systems cannot just edit an Invoice after it has been sent. The audit trail demands an explicit, separate document. The Credit Memo is that document. Once issued, the customer account balance shows the original invoice minus the credit memo, the credit can be applied to a specific invoice or held as an account credit for future bills, and the revenue recognition flows reverse to match. Finance and audit teams treat the Credit Memo as a primary transactional record, not a soft note.

CRM Analytics is Salesforce's enterprise analytics platform for building interactive dashboards, exploring large data sets, and embedding analytical insights directly into Sales Cloud and Service Cloud records. It is the product previously branded as Tableau CRM (and earlier as Einstein Analytics and Wave Analytics) before consolidating under the CRM Analytics name. The platform handles analytical workloads that exceed what standard Salesforce reports and dashboards can serve: tens of millions of rows, complex joins across data sources, statistical analyses, and embedded dashboards inside record pages. CRM Analytics ingests data from Salesforce orgs, external databases, data lakes, and uploaded CSV files. The data lives in CRM Analytics datasets optimized for analytical queries. Users build lenses (visualizations), dashboards (collections of lenses), and explorations (ad-hoc analytical workflows). Each dashboard supports interactive filtering, drill-down, and bindings that link components together. Einstein Discovery layers on top to provide AutoML-driven predictive analytics. CRM Analytics is licensed separately from base Salesforce; many enterprise orgs use it alongside Salesforce's standard reporting for the analytical scenarios standard reports cannot handle.

CSV (Comma Separated Values) is a plain-text file format that stores tabular data: rows of records separated by line breaks, fields within each row separated by commas, and (optionally) text fields wrapped in double quotes to escape embedded commas or newlines. In the Salesforce context, CSV is the de facto exchange format for bulk data: Data Loader exports and imports use CSV, the Data Import Wizard reads CSV, Salesforce Reports export to CSV, and most third-party tools that talk to Salesforce read or write CSV files. CSV exists in Salesforce because it is the lowest common denominator for tabular data exchange. Every spreadsheet program (Excel, Google Sheets, Numbers) can read and write it. Every programming language has a CSV parser. Salesforce APIs accept and return CSV alongside XML and JSON. The format is not standardized as rigorously as JSON (different tools handle quoting and line endings slightly differently), but it is the workhorse format for moving data in and out of Salesforce orgs at scale.

A CTI Adapter in Salesforce is the JavaScript software component that runs in the Open CTI iframe inside a Salesforce console app and translates events between the agent phone system and Salesforce. When a call rings in, the adapter receives the event from the telephony platform and calls Salesforce Open CTI methods like screenPop and saveLog to surface the right record and log the call. When the agent clicks a phone number in Salesforce, the adapter receives the click and tells the telephony platform to place the outbound call. The adapter is the actual code that makes CTI work. It is supplied by the telephony vendor (Five9, Talkdesk, Genesys, RingCentral, Amazon Connect partner builds, and others), distributed as a managed AppExchange package, and registered in Salesforce through a Call Center definition file. Service Cloud Voice ships its own first-party adapter; third-party adapters all conform to the same Open CTI specification.

A CTI Connector in Salesforce is the broader installable package that bundles a CTI Adapter, the Call Center definition file, supporting Lightning components, and any vendor-specific configuration UI that connects a telephony provider to Salesforce. The terms Adapter and Connector are often used interchangeably in vendor marketing, but in practice a Connector is the AppExchange-installable bundle, while the Adapter is the JavaScript code inside it that runs in the Salesforce console softphone. Most major telephony vendors (Five9, Talkdesk, Genesys, RingCentral, NICE inContact, Dialpad, Amazon Connect partners) ship their integration as a Connector through the AppExchange. The Connector installs as a managed package, brings along the adapter and configuration, and surfaces in Setup as a Call Center plus any custom objects the vendor needs. Service Cloud Voice ships its own Connector as part of the SCV package.

A CTI System in Salesforce refers to the complete telephony infrastructure that ties an organization phone platform to Salesforce: the underlying phone system (PBX, cloud-based VoIP, or SCV-hosted Amazon Connect), the CTI Adapter or Connector that translates events between phone and Salesforce, and the Salesforce Call Center configuration that registers the adapter and assigns users. Together these components let agents place, receive, and log calls from inside Salesforce without juggling a separate phone application. CTI System is the umbrella term, distinct from its parts. The Adapter is the JavaScript code; the Connector is the AppExchange package that ships the adapter plus configuration; the Call Center is the Salesforce registration record; the phone platform is the actual telephony plumbing. People say CTI System when they want to discuss the integration as a whole rather than any single piece. Most enterprise Salesforce deployments operate one CTI System with one phone vendor; some operate parallel systems during a migration.

A Custom App in Salesforce is an admin-built Lightning or Classic application configured in App Manager (Setup, Apps, App Manager). Each Custom App has its own name, logo, branding color, navigation items (tabs and utility bar), default landing page, and a list of profiles or permission sets that can access it. Users see Custom Apps in the App Launcher alongside the standard apps that ship with Salesforce (Sales, Service, Marketing CRM Classic). Custom Apps exist because every org has workflows that the standard apps do not perfectly fit. A medical device manufacturer builds a Field Service Engineer app with tabs for Work Orders, Customer Sites, Parts Catalog, and Knowledge. A sales-operations team builds an Ops Console app with tabs for Forecast, Pipeline Health, Territory, and Team Reports. The Custom App is the packaging mechanism that gives a workflow its own branded surface inside Salesforce; without it, users navigate a single sprawling Sales or Service app with every tab visible regardless of relevance.

A Custom Console Component in Salesforce is an admin-added Visualforce page, Lightning component, or Canvas app that lives in a designated area of a Service Console or Sales Console: the sidebar, footer, highlights panel, or related-list area. The component extends the console with functionality that the standard Salesforce UI does not provide, such as showing external data alongside the Salesforce record, providing agent productivity tools (notes, scratchpad, snippets), or embedding a third-party app inside the agent workspace. Custom Console Components exist because console agents need fast access to context that lives outside the current record. A support agent on a Case needs to see the customer order history, an order-line system, the contract terms, and maybe a billing system snapshot. Cramming all of that into Salesforce native components is slow; embedding a Custom Console Component pulls the external context into the agent flow without forcing a tab switch.

A Custom Controller in Salesforce is an Apex class that provides all the data and behavior for a Visualforce page, without relying on the Standard Controller framework. The page declares the class through the controller attribute, and from that moment on, every getter, setter, and action method called from the page must exist on that class. Custom Controllers give developers complete control over data access patterns, custom queries, complex business logic, and navigation, at the cost of writing more code than a Standard Controller would require. Custom Controllers exist because Standard Controllers are object-bound and cannot do anything the standard CRUD APIs cannot already do. A page that needs to query across objects, run complex business logic, call external services, or render a UI that does not map cleanly to a single record needs a Custom Controller. Sample use cases: a search page that queries Knowledge articles plus Cases plus Contacts in one query, a wizard that walks through multi-step form input, a dashboard page that aggregates records across the org.

A Custom Field in Salesforce is an admin-created field on any standard or custom object that captures data beyond what the standard object schema includes. Custom Fields come in many types (Text, Number, Currency, Date, Picklist, Checkbox, Lookup, Master-Detail, Formula, Roll-Up Summary, Auto Number, and others), each with type-specific configuration. Custom Fields surface on page layouts, list views, reports, filters, validation rules, and integrations the same way standard fields do; the platform treats them identically once created. Custom Fields are the most-built customization in any Salesforce org. A typical mature org holds dozens to hundreds of custom fields per heavily-used object (Account, Opportunity, Case, Contact). The fields capture industry-specific data (Account.AccountTier, Opportunity.RegionRevenue, Case.Tier_Number), integration keys (External_ID__c that maps to an ERP), calculated values (Formula fields), and process state. The discipline around custom field creation (naming, documentation, governance) is what separates orgs that stay maintainable from orgs that accumulate field debt.

Custom Help in Salesforce is the feature that lets administrators replace or supplement the default Salesforce help links and inline help text with org-specific help content. Custom Help applies at multiple levels: field-level help text (tooltips on individual fields), object-level help (custom URLs the Help link on an object's tabs points to), and the broader Custom Help Settings that govern which help content users see when they click contextual help links throughout the org. The feature exists because Salesforce's default help text is generic; an org with custom processes, custom fields, and custom workflows benefits from help content that explains those specifics. A field labeled Tier means different things to different orgs; field-level help text on that field tells users what the org means by Tier. Custom Help is one of the cheapest enablement investments; users with relevant help content adopt the platform faster and call the helpdesk less.

Custom Labels in Salesforce are admin-managed text strings stored centrally and referenced by code (Apex, Lightning Web Components, Aura Components, Visualforce, Flow) instead of hardcoding text. Each Custom Label has a name (the API identifier code uses), a value (the actual text), an optional categorization, and translations for every language the org supports. Code references the Label by name; the platform serves the right translation based on the user's language preference. Custom Labels exist because text in code is brittle. Hardcoding "Please enter a valid email address" in an Apex class works until the org needs Spanish or until the wording needs to change everywhere. Custom Labels move the text out of code and into a managed surface where translations live alongside the strings, admins can update wording without redeploying code, and the same Label can serve every code path that needs that string. They are the foundation of any serious localization or wording-governance strategy in a Salesforce org.

Custom Links in Salesforce are admin-configured URL-based actions that appear on record pages, list views, and home pages, allowing users to navigate to external websites, internal Salesforce pages, or Visualforce pages with dynamic context from the current record. Each Custom Link has a label, a URL (which can include merge fields like {!Account.Name} to inject record data), a display type (link, button, sidebar component), and a behavior (open in new window, open in same window, open in popup). Custom Links predate Lightning Web Components and Quick Actions; they were the original Salesforce mechanism for adding navigation outside the standard page chrome. In Lightning Experience they still work but are usually superseded by Custom Buttons, Quick Actions, or LWC components that produce better-integrated experiences. Most established orgs hold Custom Links from years of accumulated customization; the modern admin pattern is to maintain existing Custom Links and build new navigation through Lightning-native constructs.

A Custom Metadata Type is a Salesforce configuration construct that stores records as metadata rather than data. The records live in the same metadata tier as Apex classes, custom objects, and page layouts, which means they deploy through change sets, version in source control, and travel with managed packages. Apex, Flow, and formula fields can read Custom Metadata Type records without consuming SOQL governor limits, the same way they read Custom Settings. Custom Metadata Types were introduced in 2015 as the strategic replacement for List Custom Settings. The difference matters: a Custom Setting record is data, a Custom Metadata record is metadata. Custom Metadata records can be deployed from sandbox to production, packaged into managed packages, and rolled back through deployment pipelines. They support cross-object relationships through Metadata Relationship fields, picklist fields, and protected visibility for managed-package authors. Most modern Salesforce configuration that does not need User or Profile hierarchy belongs in Custom Metadata Types rather than Custom Settings.

A Custom Notification in Salesforce is an admin-defined push notification that can be sent to specific users through the Salesforce mobile app, the desktop bell icon, or both. Notifications are triggered programmatically from Flow, Process Builder, Apex, or the REST API, and let admins build domain-specific alerts (High-value Opportunity at risk, VIP customer just submitted a Case, SLA breach imminent) without writing custom mobile push integration code. Custom Notifications are configured through the Custom Notification Type standard object (CustomNotificationType in the API), which holds the MasterLabel, CustomNotifTypeName, Description, and channel toggles (Desktop, Mobile). Once a type is defined, automations reference it by Id and supply a Title, Body, optional Sender Id and TargetId (the record the notification is about), and a list of recipient User Ids. Salesforce delivers the notification across the configured channels to each recipient.

Custom Notifications are admin-defined notification types that Flow, Apex, or process automation can fire to specific Salesforce users via the desktop notification bell, the Salesforce mobile app push channel, or both. Each notification type carries a title, body, and a target record URL that opens when the user clicks. Custom Notifications replaced the older Push Notification API as the modern way to send alerts without writing Apex. A Custom Notification Type is metadata: configured in Setup, deployed across orgs like any other metadata. The notification itself is sent at runtime via the Send Custom Notification action in Flow, the Messaging.CustomNotification class in Apex, or the REST API. The receiving user sees a desktop notification through Salesforce Lightning Experience and a push notification on the Salesforce mobile app, with the receiving channels controlled by the notification type's configuration. No code is required for the most common use cases.

A Custom Object in Salesforce is a user-defined object you create to model data that does not fit any standard object. Salesforce ships with around fifty standard objects (Account, Contact, Opportunity, Case, Lead, and the rest); Custom Objects extend that schema with the specific record types your business needs. Every Custom Object has an API Name ending in __c (the platform's marker for custom metadata), a set of fields you define, and access to nearly every platform feature that standard objects use: page layouts, record types, validation rules, triggers, formula fields, sharing rules, reports, Lightning Record Pages, and the rest. Custom Objects are how Salesforce stays usable as a platform rather than just a CRM. A pure CRM database with a fixed schema cannot model the dozens of business-specific concepts every customer eventually needs to track: Projects, Assignments, Service Requests, Invoices, Inventory Items, Patient Visits, Loan Applications, anything else that does not appear on Salesforce's standard list. Custom Objects fill that gap. Most enterprise Salesforce orgs have between thirty and three hundred Custom Objects, each modeling something specific to the business, and the cumulative weight of all those Custom Objects is what makes the org feel like the company's central operational system rather than just a sales tool.

Custom Permissions in Salesforce are admin-defined boolean permissions that exist alongside the platform's standard CRUD and field-level permissions. Each Custom Permission has a name, a label, an optional description, and a connection to permission sets and profiles. Code (Apex, Flow, Lightning Components) can check whether the running user has a specific Custom Permission and branch behavior accordingly. The construct exists to let admins gate custom code paths and configuration through the same permission-set assignment mechanism users already understand. Custom Permissions exist because some business logic does not fit cleanly into CRUD permissions. A user might need to approve renewals at one tier but not another; an Apex trigger should fire for some users and not others; a Flow should branch based on whether the running user is a regional manager or a regional director. Hardcoding these distinctions in code with profile or role name checks is brittle; using Custom Permissions lets the access decision live in permission set assignment where admins can see and audit it.

A Custom Report Type is a Salesforce metadata definition that exposes a set of objects, their relationships, and their fields as a foundation for building reports. Where standard Report Types ship with Salesforce and cover the most common analytical patterns (Accounts with Contacts, Opportunities with Products), Custom Report Types let admins build the cross-object combinations that are unique to each org. They are how teams expose junction objects, custom objects, and non-standard relationship paths to the report builder. Every Custom Report Type starts with a primary object and adds related objects through their relationship fields. The admin picks which fields are exposed for filtering, grouping, and display. They can also configure default columns, group columns into logical sections, and set the report type as Deployed (visible to users) or In Development (admin-only). Without the right Custom Report Type, certain reports cannot exist at all because the data path the analyst needs is not available through any standard type.

Custom Settings are a Salesforce data construct that store configuration data accessible from Apex, Flow, validation rules, and formula fields without consuming SOQL governor limits. They look like custom objects in Setup but live in an in-memory cache, which makes reads effectively free in code. The two types are List Custom Settings, which hold a flat list of named records, and Hierarchy Custom Settings, which support an inheritance hierarchy of org-default, profile-level, and user-level overrides for the same setting. Custom Settings were the standard configuration mechanism for most of Salesforce's history. Tax rates, integration endpoints, feature flags, geocoding API keys, validation thresholds: all classic Custom Settings use cases. Custom Metadata Types, introduced in 2015, have replaced Custom Settings for most new use cases because metadata can be deployed through change sets and tracked in version control. But Custom Settings remain the right tool for user-specific or profile-specific overrides (which Custom Metadata cannot do natively) and for any configuration that admins need to edit in production without metadata deployments.

A Custom View in Salesforce, more commonly called a List View today, is a saved filter on an object's record list that shows a defined subset of records with a defined set of columns. Each Custom View has a name, filter criteria (which records to include), columns (which fields to show), sort order, sharing scope (private, public, or shared with specific groups), and an optional pinning to the user's default. Users create Custom Views for their personal workflows; admins create them for team-wide use. Custom Views exist because every object has more records and more fields than fit usefully in one default list. A sales rep working their pipeline needs My Open Opportunities filtered to their owner and Stage not in Closed. A service supervisor needs Cases assigned to my team, sorted by SLA, with custom fields visible. The Custom View is how each user (and each team) crafts their working list rather than scrolling through everything. List Views are one of the most-used Salesforce surfaces and one of the most-customized per user.

Customer 360 is Salesforce product-portfolio and integration vision: a unified customer profile spanning every Salesforce cloud (Sales, Service, Marketing, Commerce, Data Cloud, Agentforce) so every department in the business sees the same data about each customer. The concept is delivered through shared data models (the Customer 360 Data Model), identity resolution in Data Cloud, and cross-cloud integration via Marketing Cloud Connect, Salesforce Connect, and the Einstein 1 Platform. Customer 360 is both the marketing term Salesforce uses to describe its suite and the technical capability that unifies customer data across the products. Salesforce introduced the phrase in 2018 to anchor a multi-year platform-consolidation initiative and continues to use it as the framing for new product launches. The phrase appears in keynotes, press releases, partner solution naming, and product documentation, even when individual products underneath have evolved or rebranded.

Customer Relationship Management (CRM) is the category of business software that centralizes a company customer-facing data and processes: who the customers are, what they have bought, what conversations the company has had with them, what opportunities are in flight, and what issues need resolving. A CRM stores all of this in a structured database and surfaces it through interfaces tailored to sales, service, marketing, and commerce roles. Salesforce is the largest CRM vendor by revenue and the originator of cloud-delivered CRM. CRM as a category predates Salesforce; it grew out of contact management software in the 1980s and pipeline management software in the 1990s. Salesforce founded itself in 1999 specifically to deliver CRM through a web browser instead of an installed desktop application, which became the dominant delivery model. Today CRM also extends beyond traditional sales-and-service into marketing automation, commerce, AI-driven insights, and unified data platforms. The Salesforce platform covers all of these as integrated products that share the same customer record.

Customer Satisfaction Score (CSAT) in Salesforce is a post-interaction survey metric that measures how satisfied customers are with the support, service, or experience they received. The standard pattern is to send a short survey (one question, sometimes two or three) after a Case is closed, asking the customer to rate their experience on a numeric or smiley-face scale, and to compute CSAT as the percentage of responses at the top of the scale. CSAT is one of three customer-experience metrics that most service organizations track. Net Promoter Score (NPS) measures advocacy intent on a 0-to-10 scale. Customer Effort Score (CES) measures how much work the customer had to do. CSAT measures immediate satisfaction. Salesforce Service Cloud supports all three through Surveys (the standard product) or third-party survey tools (Qualtrics, SurveyMonkey, Medallia) integrated through APIs. The CSAT score lands back on the Case record and rolls up into Service Cloud dashboards and Service Analytics.

Customers (Chatter) in Salesforce refers to external users who are invited to participate in specific Chatter Customer Groups without a paid Salesforce license. A Chatter Customer can post, comment, like, and share files inside the Chatter Customer Group they are invited to, but they cannot see any other Salesforce data: no records, no other groups, no profile pages beyond the ones explicitly shared. The feature exists for narrow external collaboration with vendors, partners, customers, or contractors who need to participate in a single project conversation without becoming a full Salesforce user. Chatter Customers are licensed under the free Chatter External license, which Salesforce has continued to provide alongside the much broader Experience Cloud. The mechanic predates Experience Cloud and continues to be supported, though most modern external-collaboration deployments use Experience Cloud sites instead because they offer richer features (record access, branded UI, single sign-on). Chatter Customers are still the right pick for the narrow case of adding one person to one group and nothing else.