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.

A Calendar in Salesforce is the scheduling surface in Lightning Experience that shows your Event records, plus any object calendars built from other records that carry a date field, in day, week, and month views. It lives as the Calendar tab and as a Calendar component you can drop onto a Lightning page. You always see your own events, and you can layer on calendars that other people share with you or that an admin builds from object data. The Calendar matters because schedule information is scattered across the org. Meetings sit in Event records, opportunity close dates sit on Opportunity, and field bookings sit on Service Appointment. The Calendar pulls those into one timeline through object calendars and external sync, so a rep does not have to check five places to see what is happening this week.

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 that the CRM records as structured data. It shows up in one of two shapes. A logged Call is a Task record with TaskSubtype set to Call, created when a rep clicks Log a Call to document a conversation after the fact. A Voice Call is a standard VoiceCall object record, created automatically when a call runs through Salesforce Voice, Sales Dialer, or a partner telephony connector. Both shapes capture the same idea, a conversation between a Salesforce user and a customer, but they differ in how the data arrives and how much context comes with it. Logged Calls are quick manual notes that carry a call type, a result, and a link to a Contact or Account. Voice Call records capture telephony detail automatically: the from and to phone numbers, start and end times, duration, a recording, a transcript, and the agent who handled it. Together they give a team one timeline of who talked to whom and what was said.

A Call Center in Salesforce is the Setup record that connects a telephony platform to Salesforce so agents can take and place phone calls inside the application. Each Call Center record corresponds to one computer-telephony integration (CTI) system, such as a Service Cloud Voice deployment on Amazon Connect or a partner platform like Five9, Genesys, or Talkdesk. The record holds the connection parameters, and it controls which users see a Softphone in their console. A Salesforce user cannot use any Call Center feature until an administrator assigns that user to a Call Center. The Softphone does not render and call routing does not reach the agent without membership. That single rule makes the Call Center record the foundation of every voice setup. You can create one by importing a CTI definition file (an XML file the telephony vendor supplies) or by cloning an existing record and editing its parameters.

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 a standard, read-only percentage on the Campaign object that compares the revenue a campaign produced against what it cost to run. Salesforce calculates it as the value of won opportunities tied to the campaign, minus the campaign's Actual Cost, divided by that Actual Cost, then expressed as a percentage. A result of 200 percent means the campaign returned twice its cost in closed revenue. The "value of won opportunities" comes from opportunities where the campaign sits in the Primary Campaign Source field and the stage is closed and won. Actual Cost is typed in by hand on the campaign. Because both inputs are manual or attribution-driven, the ROI number is only as honest as the data behind it. Track cost loosely or skip the campaign link on opportunities, and the figure stops meaning anything.

The Canvas App Previewer is a Salesforce Setup tool that lets you see what a canvas app will look like before you publish it to users. A canvas app is a third-party web application, written in any language and hosted outside Salesforce, that the Canvas framework embeds inside the Salesforce UI through an iframe. The Previewer renders that external app inside Salesforce so you can test and debug it during development. You reach the Previewer from the Quick Find box in Setup, then click a canvas app in the left-hand pane to load it in the preview frame. It runs as the logged-in user and constructs the same context that production Canvas would send, so the embedded app receives a realistic payload. Seeing the app behave correctly here is the signal that it is ready to be embedded in a Lightning page, a Visualforce page, or the publisher.

A Care Plan is a Salesforce Health Cloud record that organizes the work of treating one patient or member around three connected parts: the problems being addressed, the goals the patient should reach, and the interventions that move them there. It sits on the person's record and gives a care coordinator, clinician, or case manager a single place to see what is wrong, what success looks like, and who is doing what about it. In current Health Cloud, Care Plans are part of the Integrated Care Management feature. They are built from standard objects such as CarePlan, Care Plan Problem, Care Plan Goal, and Care Plan Intervention, with CareBarrier capturing obstacles like social or environmental factors. A care manager can build a plan from scratch, apply a Care Plan Template, or generate one from assessment recommendations or a care gap. The same structure shows up in public sector and nonprofit settings, where it tracks a participant's needs and a plan to meet them.

A Care Program in Salesforce Health Cloud is a record that represents a set of activities offered to participants by an employer, insurer, provider, or life sciences company. Those activities can be a patient therapy, a financial assistance program, patient education, a wellness plan, or a fitness plan. The Care Program record holds the program name, the parent program, the program sponsor, the approved budget, and the start and end dates. It is the top-level container for everything the program does. Patients join through a Care Program Enrollee record, which links a Person Account to one program. A single Care Program serves many enrollees, and one patient can be enrolled in several programs at once. Care Programs sit above Care Plans. A Care Plan organizes work for one patient, while a Care Program organizes a whole population pursuing a shared goal such as managing diabetes, adhering to a medication, or recovering after surgery.

A Care Team in Salesforce Health Cloud is the group of people coordinating on one patient's care, modeled as a set of Care Team Member records that link each person to the patient and give them a role on that patient's care plan. Members can be internal Salesforce users such as a primary care physician or care coordinator, external providers, or relatives like a family caregiver or emergency contact. Each member carries a role, an access level, and effective dates, so the org always knows who is involved, what they are responsible for, and how long their involvement lasts. The Care Team exists because chronic care, behavioral health, and post-acute work pull many people around the same patient over months or years. Without it, a record becomes a flat list of disconnected interventions. With it, the Care Team component shows the full roster on one screen, with each person's role, contact details, and accountability visible at a glance. Care Team roles also control access to the patient's care plan, so the team model doubles as a sharing model.

A Cart in Salesforce B2B and D2C Commerce is the WebCart object, an online shopping cart that holds a buyer's selected products, applied coupons, calculated taxes and shipping, and running totals before an order is placed. Each line a shopper adds becomes a child CartItem record, and the WebCart tracks the grand total across products, charges, and tax. The Cart is the working draft of a purchase. When the buyer finishes checkout, the platform places an order from the Cart, and the WebCart status moves to Closed. A WebCart is tied to a buyer Account and a WebStore, and it carries a Status field with values Active, Processing, Checkout, Closed, and Deleted. Every storefront interaction (add to cart, change quantity, apply a coupon) writes to the Cart and triggers a recalculation. Pricing, promotions, inventory, shipping, and tax all run against the Cart through the Cart Calculate API. Understanding the Cart means understanding how those calculators read the WebCart, write their results back, and hand a finished total to checkout.

A Cart Item is a child record of a Salesforce Commerce WebCart that represents one line in a shopper's cart. It stores a reference to a Product, the Quantity, the list and sales prices, the delivery group it belongs to, and any item-level price adjustments or taxes. Each Cart Item belongs to exactly one WebCart. Together the Cart Items hold the line-level detail that sits under the cart's overall totals in a store built with B2B Commerce or D2C Commerce. A Cart Item can be one of two types: a Product line or a Charge line (such as a shipping or handling fee). The object became available in API version 49.0. Cart Items matter because the cart's totals are a rollup of Cart Item math. Pricing, promotions, inventory, and tax all act on individual Cart Items first, and the cart totals are recalculated after. When the cart converts to an order at checkout, each Cart Item maps to an OrderItem, so the line you see while shopping carries through to fulfilment.

A Cascading Style Sheet (CSS) is the web-standard language for describing how HTML elements look on screen. It sets colors, fonts, spacing, sizing, and layout through declarative rules that a browser applies to markup. CSS works the same way in Salesforce as anywhere on the web, but the platform wraps it in conventions, security models, and a design system that change how you write and ship it. In Salesforce, CSS renders Lightning Experience, Lightning Web Components, Aura components, Visualforce pages, Experience Cloud sites, and email templates. Most styling does not start from a blank stylesheet. The Salesforce Lightning Design System (SLDS) supplies base styles, utility classes, and CSS custom properties that components inherit, so the common task is composing what SLDS already gives you. Where you do write CSS, the surface decides the rules: shadow DOM scopes it in components, an iframe isolates it in Visualforce, and email clients strip much of it away.

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.

A Case Checkout is the Service Cloud workflow pattern where a service representative explicitly claims a Case from a shared Queue by taking ownership of it before starting work. The act of checkout changes the Case Owner field from the Queue to the individual rep. That single change signals to the team that the Case is now being handled, and it stops two people from working the same record at once. Case Checkout is not a single button or object name in Salesforce. It is the operational concept behind several built-in features: the Accept button on Queue list views, Change Owner actions, and Omni-Channel routing that assigns work automatically. Older Service Cloud material and partner blogs use the phrase Case Checkout, while current Salesforce documentation describes the same behavior as taking ownership of a record or accepting a routed work item.

A Category Group for Articles is a named container in Salesforce that holds a hierarchy of Data Categories used to classify Knowledge articles. Each group represents one dimension of your content, such as Products, Geography, or Customer Type, and the categories inside it form a parent-and-child tree. Authors tag articles against categories in the group, and readers filter by those categories to find the right content. The same Data Category infrastructure also serves Ideas and the legacy Answers feature, but for Knowledge the Category Group is how articles get organized and secured. A Category Group does two jobs at once. It gives articles a browsable taxonomy, and it controls who can see what through Data Category Visibility settings tied to roles, profiles, or permission sets. You build and manage groups in Setup under Data Category Setup. Salesforce lets you keep up to five active groups, each holding up to 100 categories across up to five hierarchy levels. Good group design pays off everywhere downstream, because search, browse, reporting, and article access all read from the structure you define here.

A Category for Ideas is a value in the Categories picklist that organizes user-submitted ideas into sub-groups inside a Salesforce Ideas zone. Administrators define the category values, and members tag each idea with one or more of them. Readers then use the View Category drop-down on the Ideas tab to filter the list and find related ideas to vote and comment on. Categories belong to the older Salesforce Ideas feature, so the term is legacy. Salesforce still ships an Ideas Implementation Guide for recent releases, and the Idea, IdeaComment, and Vote objects remain queryable. New feedback programs usually move to Experience Cloud surfaces, Chatter questions, or a custom idea object instead of standing up a classic Ideas zone. The Categories idea carries over to those builds, even though the standard Categories picklist is no longer the default place teams collect product feedback.

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.

A Category for Solutions, usually called a Solution Category, is a label in the older Salesforce Solutions feature that groups similar Solution records into a browsable hierarchy. Each Solution is a documented answer to a recurring customer issue. Solution Categories let support agents and customers find the right answer by walking a category tree instead of relying only on keyword search. A single Solution can sit in more than one category. This is a legacy taxonomy. The Solutions feature predates Salesforce Knowledge and shipped with the earliest Service Cloud releases. Solutions and their categories are not available in Lightning Experience as a primary feature, and Salesforce now steers new service work to Lightning Knowledge. Knowledge uses Data Categories and Data Category Groups to do the same organising job with more flexibility. The Solution object still exists and stays queryable in older orgs, so the term shows up in pre-2020 documentation, certification material, and partner blogs.

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 on Salesforce Trailhead is the hands-on practice task at the end of a module unit. The Challenge asks the learner to perform a specific build in a Trailhead Playground, which is a free Developer Edition org provisioned for learning. When the learner clicks Check Challenge, Trailhead's verification engine inspects the Playground's metadata and data to confirm the work was done correctly, then awards points and badge progress. A passing Challenge earns points that count toward Trailblazer rank. A failing Challenge returns a diagnostic message that names what is missing or wrong, so the learner can fix it and try again. This automated, build-then-verify loop is how most Salesforce professionals practice the platform, and it is what separates Trailhead from a course that only asks you to read.

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 is the internal Salesforce user who owns the relationship with a company's external sales partners, such as resellers, distributors, system integrators, and referral agents. The role lives inside Partner Relationship Management (PRM), the Salesforce product built on Sales Cloud and Experience Cloud that gives partners a portal and gives the vendor the tools to run the channel. Salesforce documentation often calls this person the Channel Account Manager, or CAM. They own Partner Accounts, approve registered deals, route leads to partners, manage marketing funds, and report on partner-sourced revenue. In practice the Channel Manager works mostly from the internal Sales Cloud interface while partners work from a Partner Central site in Experience Cloud. The two sides share the same data. A partner submits a deal or a fund request on the portal, and it lands in the Channel Manager's queue for a decision. The role matters because indirect revenue is a large share of most B2B pipelines, and a channel left unmanaged drifts into disputes over who owns which deal.

Chat is the legacy Salesforce web-chat channel, originally called Live Agent, that let customers start a real-time text conversation with a service rep from a website or app. A visitor clicked a chat button, an Omni-Channel queue routed the request to an available agent, and the whole exchange was saved as a Live Chat Transcript record in Salesforce. It was a core Service Cloud feature for more than a decade. Salesforce retired Legacy Chat on February 14, 2026. New orgs can no longer set it up, and existing deployments are expected to move to Enhanced Chat, the channel formerly known as Messaging for In-App and Web. If you still see Chat in an older org, treat it as a sunset feature. The sections below explain how classic Chat worked, why it was retired, and how the replacement differs so a migration goes smoothly.

The Chat Console was the Salesforce Service Cloud surface that support agents used to send and receive real-time chat messages with website visitors. It was one of the four parts of the older Chat product (formerly Live Agent), alongside Omni-Channel, Embedded Service, and Einstein Bots. Omni-Channel routed each incoming chat to the right agent, and the agent worked the conversation inside the console next to the customer record, transcript history, and Knowledge articles. Supervisors used the same console to monitor live chats, send whisper messages, and report on chat session records. This term is legacy, and the product behind it is now retired. Salesforce retired Legacy Chat on February 14, 2026, and the recommended replacement is Enhanced Chat, also known as Messaging for In-App and Web. New work uses the standard Service Console with the Omni-Channel widget, where chats and messaging conversations share one routing engine and one agent workspace. Treat any older documentation that says Chat Console as a pointer to that modern Service Console setup.

The Chat Window is the customer-side interface of a legacy Salesforce Chat conversation: the panel that opened when a website visitor clicked the embedded Chat button or accepted a proactive invitation. The window showed the running transcript, a typing area for the visitor's messages, agent branding such as logo and name, typing indicators, and any files or links the agent shared. Its look, behaviour, and pre-chat fields were configured through an Embedded Service deployment, and it inherited styling from the host site. This window is now legacy. Salesforce retired Chat, also marketed as Live Agent, on February 14, 2026, and the embedded Chat Window retired with it. New deployments use enhanced Chat, formerly called Messaging for In-App and Web, whose messaging window keeps conversation history and supports asynchronous, cross-device chats. If you still run the old window, treat this entry as historical context and plan a move to enhanced Chat.

A Chatlet is an informal, unofficial nickname that circulated in the early Salesforce Chatter community for a small custom add-on bolted onto the Chatter publisher, the composer box at the top of a feed where people write posts. The idea was a compact widget that let users create a specialised post type, such as a quick poll or a recognition shout-out, instead of plain text. The word was never a Salesforce product name. It does not appear in any official Help article, Developer Guide, or release note. Because Salesforce never shipped a feature called Chatlet, the term is best treated as legacy shorthand. The capabilities people described as Chatlets are delivered today by documented mechanisms: Quick Actions (also called publisher actions) for declarative post types, and Rich Publisher Apps for programmatic add-ons built with Lightning components. If you find Chatlet in an old blog or forum thread, read it as one of those supported features rather than a thing you can switch on in Setup.

A Chatter Bookmark is a personal save action that lets a user keep a Chatter feed post for later by flagging it. The bookmarked post collects in the Bookmarked feed on the Chatter tab, and a star appears in the top-right corner of the post in its original feed. Bookmarks are private to the user who creates them. No one else can see which posts a person has bookmarked, so the feature works like a saved-posts list on a social network. Chatter Bookmarks exist because feeds in an active org move quickly, and a useful post can scroll out of easy reach within hours. Bookmarking is the lightweight way to set a post aside without reposting it, replying, or copying a link. The feature is current in Lightning Experience, where Bookmarked is one of the standard feeds on the Chatter tab alongside What I Follow, To Me, Company Highlights, and My Drafts.

A Chatter Favorite is a Salesforce Classic feature that lets a user save a list view, a Chatter feed search, or a Topic as a personal shortcut on the Chatter tab. Once saved, the favorite gives one-click access back to that filtered list, saved search, or topic feed without rebuilding it each time. Each user manages their own set, and the documentation caps the list at 50 favorites per user. Chatter Favorites belong to the Salesforce Classic experience. In Lightning Experience, the same idea lives in the Favorites menu in the page header, opened with the star icon. That newer menu is broader: it saves records, lists, dashboards, reports, folders, and Chatter groups, and it raises the cap to 200. If you are reading "Chatter Favorite" in a Classic context, this page describes exactly that feature, then maps it to its Lightning successor so you know where the function moved.

A Chatter feed is the Salesforce stream of updates that appears on profiles, groups, the Chatter tab, topic detail pages, and record detail pages. It shows posts, comments, files, links, questions, polls, and system-generated record updates that are relevant to a person, a record, a group, or a topic. Each entry is a feed item that links to its author, its parent context, and the people who liked, commented, or were mentioned in it. The feed is how internal teams talk to each other around CRM data without leaving Salesforce. A rep posts an update on an opportunity, and the manager who follows that record sees it in their personal feed. An agent logs a note on a case, and teammates following the case pick it up. Chatter has lost some prominence as Slack adoption grew, but the feed is still the canonical record-level conversation surface in Salesforce.

A Chatter Group is a shared collaboration space in Salesforce that has its own membership, feed, and files. People join a group to follow one focused conversation instead of wading through the global company feed. Each group carries an access level (Public, Private, or Unlisted), an owner, optional managers, and members who post, comment, and share files in the group's own feed. Groups exist to give a team, project, or topic its own room. A Public group is open to everyone in the org. A Private group is members only and people ask to join. An Unlisted group is hidden from search and runs invitation only. Private and unlisted groups can also include external customers through Experience Cloud, which makes a Chatter Group one of the few places internal staff and outside partners share a single Salesforce feed.

Chatter Mobile was the standalone iOS and Android app Salesforce shipped to put a user's Chatter feed, posts, files, and notifications on a phone or tablet. It launched in 2010 alongside the first Chatter release and ran as its own app, separate from the early Salesforce mobile CRM apps. The point was lightweight collaboration: read your feed, post an update, like and comment, join group conversations, and check notifications without opening a desktop browser. Chatter Mobile is retired. Salesforce announced Salesforce1 at Dreamforce 2013, a single mobile app that built Chatter in through the Chatter REST API instead of keeping a separate product. Over the next few years Salesforce1 was renamed the Salesforce Mobile App, and the standalone Chatter Mobile app was pulled from the app stores by around 2015. The name still shows up in pre-2018 documentation and training, but current Salesforce docs only reference the Salesforce Mobile App and its built-in Chatter experience.

A checkout is the guided, multi-step flow in Salesforce Commerce that turns an active shopping cart into a placed order. It collects the shipping address, the billing address and payment method, then validates inventory, calculates tax, authorizes payment, and finally converts the cart into an Order record. In B2B Commerce and D2C Commerce on Aura stores, the checkout is built as a Lightning Flow made up of smaller subflows, so each step can be moved, removed, or replaced. A checkout is the highest-stakes part of any storefront because every shopper passes through it to become a customer. The flow coordinates a sequence of system actions and screens against the cartCheckoutSession record, which tracks where the buyer is in the process. Salesforce ships a default checkout flow you can use as-is, then customize in Flow Builder when you need different steps, a custom payment integration, or extra tasks like purchase-order entry for B2B buyers.

A child relationship in Salesforce is the schema link that lets a parent object reach the many child records that point at it through a lookup or master-detail field. The lookup field lives on the child and references one parent. The child relationship is the reverse view, the path that walks from a single parent record back to its set of children. Every lookup and master-detail field automatically creates one child relationship on the parent object, and each one carries a name. SOQL uses that name in subqueries, Apex reads it through the describe API, and Lightning record pages render it as a related list. For standard objects the name is usually the plural child label, like Contacts on Account. For custom objects it ends in __r. Getting the name right matters because queries, related lists, and dynamic code all refer to the relationship by that exact name.

A Claim in Salesforce is the standard object that records a policyholder's request for payment, repair, or benefit under an active Insurance Policy. It is part of the Insurance Claims Management data model in Financial Services Cloud, and it ties together the policy, the people involved, the coverages that apply, and the money set aside and paid out. The Claim record acts as the file that an adjuster works from first notice to closure. Each claim holds the loss details and status, and it parents a set of related records: Claim Participants, Claim Coverages, Claim Items, Claim Cases, and the reserve and payment detail that track the carrier's financial exposure. Because everything hangs off one record, the claim becomes the single place to see what happened, who is involved, and what the carrier owes.

A Classic Email Template is the original Salesforce email template format, built and edited in Setup under Classic Email Templates. It comes in four types: Text, HTML (using Classic Letterhead), Custom, and Visualforce. Each one stores reusable email content with merge fields, so the platform fills in record values like a contact name or case number when the email is sent. This format predates Lightning Email Templates, which is why the site tags it as legacy. It still works in Lightning Experience and remains common because automation such as workflow Email Alerts and approval-process actions points at these templates. Most new authoring now happens in Lightning Email Templates, but Classic templates persist wherever older automation already references them.

A Classic Letterhead in Salesforce is a reusable branding wrapper that adds a consistent header and footer to HTML email templates built in Salesforce Classic. Each letterhead is a Setup record that defines a logo, header band, footer band, background colors, and divider lines. An HTML (using Classic Letterhead) email template links to one letterhead, and that header and footer render around the template body when the email is sent. Classic Letterheads are a legacy feature. You cannot create them in Lightning Experience, and existing letterheads remain editable mainly for backward compatibility. The modern replacement is Enhanced Letterheads, which attach to Lightning email templates that use Handlebars Merge Language. Many orgs keep Classic Letterheads alive because Workflow and approval email alerts still point at Classic templates that reference them.

A Client App in Salesforce is any external software application that authenticates against an org and uses the platform APIs to read or write data. The category covers mobile apps (the Salesforce mobile app, custom apps on the Mobile SDK, third-party iOS and Android apps), web apps (custom portals, partner integrations), backend services (ETL pipelines, billing systems, data warehouses), and command-line tools like the Salesforce CLI. Each client app is registered in the org through a definition record that carries its OAuth consumer key, allowed scopes, callback URL, and security policies. There are two registration frameworks for that record. The older one is the Connected App. The newer one, which Salesforce now recommends in every situation, is the External Client App (ECA). Starting in Spring '26, new Connected Apps can no longer be created through the UI or API without a support request, so any fresh client app you stand up today should be an External Client App. Understanding the client app concept is foundational to anything beyond the standard Salesforce UI, because every external system that touches your data is one.

The Clinical Data Model is the FHIR-aligned set of standard objects, fields, and relationships in Salesforce Health Cloud that represents a patient's clinical information. It covers encounters, conditions, observations, medications, allergies, procedures, immunizations, and diagnostic results, and links each record back to the patient stored as a Person Account. Health Cloud builds this schema to align with HL7 FHIR Release 4 (version 4.0.1), the open standard for exchanging healthcare data. The model currently maps 26 FHIR R4 resources across administration, clinical, medication, diagnostics, and workflow domains. Because the object shapes follow FHIR conventions, customers can connect electronic health record systems and health information exchanges without building a bespoke mapping layer for every field.

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 is a delivery model where software, storage, and compute run on a provider's internet-hosted infrastructure instead of on hardware the customer owns. In the Salesforce context, it is the architectural and commercial foundation of the whole platform. Customers reach Salesforce through a browser or an API, the vendor runs every server and database, upgrades arrive automatically several times a year, and billing follows a per-user subscription rather than a one-time perpetual licence. Salesforce launched in 1999 as one of the first enterprise Software-as-a-Service applications, built around a "No Software" message. The point was not that code disappeared, but that customers stopped installing and patching it themselves. Cloud computing is the lens that explains most of how Salesforce behaves: multi-tenancy creates governor limits, the hosted model drives the three-releases-a-year cadence, and the API-first design makes every integration possible. Sales Cloud, Service Cloud, Data Cloud, and Agentforce all sit on the same shared cloud platform.

Code Coverage in Salesforce is the percentage of executable Apex lines (in classes and triggers) that your Apex unit tests exercise when they run. The testing framework records which lines each test method touches, then reports covered lines divided by total executable lines as a percentage. Comments, method and variable declarations, System.debug calls, and the test methods themselves do not count toward the number. Coverage exists per class and per trigger, and the org also has a single overall figure. The number matters because it is the gate Salesforce uses before letting Apex reach production. A deployment needs at least 75 percent overall coverage, all tests passing, and some coverage on every trigger. The 75 percent floor is a minimum, not a quality signal: a class can hit 100 percent with no assertions and still tell you nothing about correctness. Many teams treat 75 percent as the line they must clear and aim well above it with tests that actually check results.

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 is a Salesforce report and dashboard chart that plots two or more measures on one chart canvas, with at least one of those measures rendered in a second visual form. The most common shape is a line drawn on top of a vertical column chart, so one metric reads as bars and the other reads as a line. Salesforce builds these by letting you add extra measures to an existing bar, column, or line chart, and (for column charts) plot one of those measures as a line, optionally on its own right-side axis. A Combination Chart is useful because not every question maps to a single number. A sales manager wants bookings next to deal count, a service lead wants case volume next to resolution time, a marketer wants lead volume next to conversion rate. Putting each metric on its own chart hides the relationship between them. Overlaying them keeps the relationship visible. The second axis option is what makes two very different scales (currency in the millions versus a count in the dozens) readable in the same frame. Combination Charts are a standard option in the Lightning report builder and render the same way inside dashboard components.

A comment in Salesforce is a free-text note attached to a parent record. It captures updates, decisions, and back-and-forth that do not fit neatly into a structured field. Salesforce ships several comment-style objects rather than one universal type. The most used are CaseComment (notes on a Case) and FeedComment (replies under a Chatter post or feed item). Each comment stores the author, the timestamp, the body text, and a reference to its parent. Comments hold the conversational layer of CRM work. A Case's structured fields say what happened; its comments say why it happened, what the agent tried, and what the customer asked for. That narrative is what the next person reading the record relies on. Because the pattern (free text plus author plus parent) is so common, Salesforce repeats it across Cases, Chatter feeds, and older products like Ideas and Solutions.

A Chatter Comment is a reply added to a Chatter feed item, such as the discussion under a post, the response to a Chatter Question, or a note an agent leaves on a Case feed. In the data model it is stored as a FeedComment record. Each comment carries the comment body, a link to its parent feed item, the author, the created date, and any mentions, attachments, or rich text. FeedComment has existed since API version 18.0, so the object underpins almost every modern Chatter surface. Comments are how a Chatter conversation actually happens. A post on its own is a broadcast. The comments are where people ask, clarify, agree, disagree, and decide. Likes signal acknowledgement but carry no detail, while comments carry the substance. On a Chatter Question, one comment can be marked as the best answer. Across Lightning, Service Cloud Case feeds, Chatter Groups, and Experience Cloud, the comment is the same building block.

Commerce Cloud is Salesforce's product family for running online stores. It covers consumer storefronts, business buying portals, product catalogs, pricing, promotions, carts, checkout, and the order fulfillment that follows a purchase. The family has two main commerce engines plus a fulfillment layer. B2C Commerce powers high-traffic consumer sites and grew from the Demandware platform Salesforce acquired in 2016. B2B Commerce on Lightning Experience runs business-to-business and direct-to-consumer stores natively on the Salesforce Platform. Salesforce Order Management handles what happens after checkout. The point of the family is to keep shopping connected to the rest of the customer record. A storefront alone is one channel. When commerce shares the same accounts, contacts, and orders with Service Cloud, Marketing Cloud, and Data Cloud, the shopper experience stays consistent. B2C Commerce is hosted and operated by Salesforce for retail scale. B2B Commerce is configured by admins inside a Salesforce org like any other cloud. Both share the cart, order, and customer concepts, and both can run headless when a brand wants full control of the front end.

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 shopper-facing website built on Salesforce Commerce Cloud. It is where customers land on the homepage, browse categories, open product detail pages, run searches, add items to a cart, and complete checkout. The Storefront is the visible front end of the commerce engine. Behind it sit the catalog, pricing, promotions, inventory, and order data that the shopper never sees directly. In B2C Commerce, a Storefront is usually built from the Storefront Reference Architecture (SFRA) or as a Composable Storefront running the PWA Kit on Managed Runtime. In B2B and D2C Commerce, the Storefront is an Experience Cloud site built with a Lightning Web Runtime (LWR) template in Experience Builder. Both models read from the same Commerce Cloud data and surface it through pages a shopper can use. The Storefront inherits branding, content, search, and SEO settings from the store configuration sitting underneath it.

A Commit Amount is the value in Salesforce Collaborative Forecasts that represents deals a sales rep is confident will close in the period. It rolls up the Amount of every Opportunity whose Forecast Category is Commit, summed across the rep's own deals and the deals of anyone reporting to them in the forecast hierarchy. Reps treat Commit as the number they are willing to put their name on, which is why leadership reads it as the floor of the quarter's expected close. The figure sits between two other totals. Closed is revenue already booked, and Best Case is the more optimistic total of deals that are likely but not certain. Commit is calculated by mapping each Opportunity Stage to a Forecast Category, then summing the Amount of every open and won deal that lands in Commit. Reps and forecast managers can override the calculated number through a forecast adjustment, and the column shows both the raw roll-up and the adjusted value.

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 file stored in a user browser by the platform, an Experience Cloud site, a Salesforce Sites page, or a marketing product like Marketing Cloud Account Engagement. Cookies let Salesforce keep a user signed in across separate HTTP requests, recognize returning visitors on public pages, remember preferences, and tie engagement back to a known prospect for marketing analytics. Cookie handling in Salesforce falls into two groups. Essential cookies (session, authentication, CSRF protection, and instance routing) are required for the product to function, so they ship enabled. Non-essential cookies (marketing tracking, statistics, and personalization) fall under privacy laws like GDPR and CCPA, and they need user consent before they are set. Salesforce ships a Cookie Consent solution for Experience Cloud to capture that consent.

CORS (Cross-Origin Resource Sharing) in Salesforce is a Setup feature where an admin allowlists external web origins that are permitted to call supported Salesforce APIs from JavaScript running in a browser. To reach Salesforce APIs, Apex REST resources, and Lightning Out from JavaScript on another domain, you add that origin to the org's CORS allowlist. If the origin is not in the allowlist, Salesforce returns HTTP status code 403 and the browser blocks the response. CORS exists because browsers enforce the same-origin policy to stop a malicious site from reading data from another domain using a logged-in user's session. Salesforce honors this. The allowlist tells Salesforce to answer a browser's preflight check with headers that let the real request proceed. CORS does not replace authentication. A call from an allowlisted origin still needs a valid session ID or OAuth access token. CORS only tells the browser that this Salesforce org accepts cross-origin requests from this specific 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 what support or protection a customer is entitled to and under what terms. The meaning shifts with the cloud you are in. In Service Cloud it is the entitlement check that decides whether the person who logged a case has a right to support, and which response and resolution clocks apply. In Health Cloud and Financial Services Cloud it refers to the records that capture a member's plan enrollment or a policy's protections. Across all of these, coverage answers one question: what does this customer have access to, and on what terms. In Service Cloud that drives whether an agent should help and how fast. In the industry clouds it drives whether a benefit applies or a claim should be paid. Salesforce does not ship a single object literally named Coverage, so the exact object depends on the product in play.

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 is the JavaScript software component that connects a telephony platform to Salesforce so agents can handle phone calls inside the console. It runs in the Open CTI iframe in the softphone panel. When a call rings, the adapter receives the event from the phone system and calls Open CTI methods like screenPop and saveLog to open the right record and log the call. When an agent clicks a phone number, the adapter receives that click and tells the phone system to dial out. The adapter is the actual code that makes computer-telephony integration work. It is usually supplied by a telephony vendor, shipped as an AppExchange package, and registered through a Call Center definition file. Note an important caveat: Open CTI is in maintenance mode and is scheduled for retirement on February 28, 2028. It is already unavailable for newly created Agentforce Service orgs. Salesforce now points new contact centers to Service Cloud Voice instead.

A CTI Connector is the installable Salesforce package that wires a telephony provider into the Salesforce console. It bundles a CTI Adapter (the JavaScript that runs the softphone), a Call Center definition file, any Lightning or Aura components the vendor adds, and the configuration screens an admin needs to point it at the phone platform. People say "Connector" and "Adapter" as if they mean the same thing, and vendor marketing rarely draws a line. In practice the Connector is the AppExchange bundle you install, while the Adapter is the code inside it that talks to Salesforce through Open CTI. Most providers (Five9, Talkdesk, Genesys, NICE, Amazon Connect partners) ship their integration as a Connector, and Service Cloud Voice ships its own first-party version.

A CTI System in Salesforce is the full set of pieces that wire an organization's phone platform into Salesforce so agents can place, receive, and log calls without leaving the CRM. It spans the telephony platform itself (an on-premises PBX, a cloud VoIP service, or Amazon Connect), the CTI Adapter or Connector that translates events between the phone and Salesforce, and the Salesforce Call Center record that registers the adapter and assigns users. People say "CTI System" when they mean the integration as a whole, not any single component. The classic way to build one is Open CTI, a browser-based JavaScript API that connects a third-party phone system to a Salesforce Call Center. That framework still runs in production today, but it is in maintenance mode and scheduled for retirement on February 28, 2028. It is already unavailable for newly created Agentforce Service orgs. New telephony work should target Salesforce Voice (Service Cloud Voice), the first-party replacement.

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 or developer-built Lightning component, Visualforce page, or Canvas app that you place in a defined region of a Salesforce console app. Those regions include the page sidebars, the utility bar at the bottom, the highlights panel, and related-list areas. The component adds functionality the standard layout does not provide, such as showing data from an outside system next to the open record, giving agents a notes or scratchpad tool, or embedding a third-party web app inside the workspace. Custom Console Components exist because agents who work inside a console need fast access to context that lives outside the current record. A support agent on a case might need order history, contract terms, and a billing snapshot. Pulling that context into the console keeps the agent in one screen instead of switching tabs and apps.

A Custom Controller in Salesforce is an Apex class that supplies all the data and behavior for a Visualforce page on its own, without sitting on top of the standard controller framework. The page names the class in its controller attribute. From then on, every property the page reads and every action it calls has to exist as a method on that class. Custom controllers hand the developer full control over queries, business logic, and navigation, in exchange for writing more code than a standard controller needs. You reach for a custom controller when a standard controller cannot do the job. Standard controllers are bound to one object and limited to the CRUD operations that object already supports. A page that queries across several objects, runs multi-step logic, calls an external service, or renders a screen that does not map to a single record needs its own Apex class behind it. One important detail: a custom controller runs in system mode by default, so it ignores the user's object permissions, field-level security, and sharing unless you add the with sharing keyword.

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, in-app alert that gets pushed to specific users through the desktop bell icon in Lightning Experience, the Salesforce mobile app, or both. It is fired from automation (Flow, Process Builder, Apex, or the REST API), so teams can raise targeted alerts like "high-value Opportunity went quiet" or "VIP customer just logged a Case" without building any mobile push plumbing. Every Custom Notification points back to a Custom Notification Type, a reusable record that names the alert and turns the Desktop and Mobile channels on or off. Once the type exists, automation references it and supplies a title, a body, the recipient IDs, an optional sender, and an optional target record. Salesforce then delivers the message across the channels that the type has enabled.

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.

A Chatter customer is an external user who is invited into a specific private Chatter group, and who can participate only inside the groups they have been invited to. The label "Customers, Chatter" in Salesforce points at this category of user: someone from outside your company email domains who joins a conversation without becoming a full Salesforce user and without any access to records or business data. Chatter customers exist for narrow external collaboration. A vendor, contractor, or client can post, comment, like, and share files inside one group, and see nothing else in the org. The feature predates Experience Cloud and is still supported today. Most richer external scenarios moved to Experience Cloud, but for a conversation-only group with a few outside people, Chatter customers stays the simplest option.