Salesforce terms starting with S

SaaS, or Software as a Service, is a cloud delivery model where software runs on the vendor's infrastructure and customers reach it through a web browser or API. There is nothing to install on local servers. The vendor handles hosting, security, scaling, and upgrades, and customers pay a recurring subscription instead of buying perpetual licenses. Salesforce is the company most often credited with bringing SaaS to enterprise software. When it launched in 1999, business applications normally meant buying licenses, racking your own servers, and running upgrades yourself. Salesforce delivered customer relationship management entirely over the internet, and that choice shaped almost everything about how the platform behaves today.

Sales Cloud is Salesforce's flagship CRM product, built around managing the sales process from lead capture through opportunity close. It is the original Salesforce product and remains the foundation for the majority of Salesforce customer deployments. Sales Cloud bundles the standard sales objects (Lead, Account, Contact, Opportunity, Product, Quote, Order, Forecast, Campaign), the workflow and automation framework, the reporting and dashboard tools, and the Lightning Experience UI tuned for sales reps. Sales Cloud is licensed per user, with several editions offering increasing capability: Starter, Pro Suite, Enterprise, Unlimited, and Einstein 1 Sales. Each edition includes more storage, more automation, more API access, and more Einstein AI features. Sales Cloud also serves as the platform on which most other Salesforce products are built; Service Cloud, Marketing Cloud, and Experience Cloud are sometimes added to a Sales Cloud foundation to give the organization end-to-end customer engagement. Most production Salesforce orgs are Sales Cloud orgs first, with additional clouds layered on top.

A Sales Cloud Everywhere is the Salesforce Chrome browser extension that brings core CRM capabilities into the web pages a sales rep already works in. It lets a rep view and update Salesforce records, work a to-do list, see engagement alerts, and surface account and prospect context without opening a separate Salesforce tab. It runs as a side panel inside Chrome, so the same Opportunity, Lead, or Contact a rep would edit inside Salesforce can be edited from a company website, a LinkedIn profile, or an email. An administrator turns the feature on in Setup, and each rep installs the extension from the Chrome Web Store.

Sales Engagement is the Salesforce product (formerly High Velocity Sales) that helps sales reps work through high-volume outbound prospecting and inbound lead follow-up with structured cadences, integrated email and call tools, and Einstein-driven next-step recommendations. The feature provides a Work Queue (the rep's prioritized list of next actions), Sales Cadences (multi-touch sequences of email, call, social steps), Email Templates with engagement tracking, and the integration plumbing into Lightning Dialer for voice plus the Outlook/Gmail integrations for email. Sales Engagement targets SDR and inside-sales teams running high-volume outbound or inbound motions. It is one tier above raw Lead management; it adds the workflow structure and tooling that lets a rep handle 80-100 prospects per day instead of 20. The feature evolved from the original High Velocity Sales (released 2018) into Sales Engagement (renamed 2022). The renamed product positions it as the canonical Salesforce sales-execution layer rather than a niche add-on. Pricing is typically per-user as a Sales Cloud add-on.

The Sales Price in Salesforce is the actual per-unit price that a sales rep records for a product on an opportunity, quote, or order line. It starts from the List Price stored in the price book entry, but a rep can change it to reflect a discount, a negotiated rate, or a customer-specific agreement. On the opportunity product record this value lives in the Sales Price field, stored in the API as OpportunityLineItem.UnitPrice. The Sales Price is a snapshot taken when the product is added to the deal. It does not track later changes to the underlying price book. That snapshot behavior is what lets a rep lock in the number a customer agreed to, even if the list price moves the next day.

Salesforce is a cloud-based customer relationship management (CRM) platform that companies use to manage their relationships with customers and prospects across sales, service, marketing, commerce, and analytics. It stores customer data in the cloud and gives sales reps, agents, marketers, and managers one shared view of every account, contact, and interaction. Salesforce is also a development platform, not only a packaged CRM. The same metadata-driven foundation that runs the standard CRM apps lets admins and developers extend, automate, and build entirely new applications. Founded in 1999, Salesforce popularized the Software-as-a-Service (SaaS) delivery model and grew into one of the largest enterprise software ecosystems in the world.

The Salesforce Administrator Certification (often called Admin or ADM-201 informally, though the exam code was retired years ago) is the foundational credential for Salesforce administrators. It validates baseline competency across the platform: user management, security, data management, automation, reports and dashboards, and the standard Sales Cloud and Service Cloud feature surface. The Admin cert is the most-held Salesforce certification globally and the prerequisite-style starting point for almost every other Salesforce credential track. The exam is 60 multiple-choice questions, 105 minutes, 65% passing score, $200 USD. Pass rates run around 50-60% on first attempt without prep; 80-90% with proper Trailhead-based study. Maintenance is required three times per year (Spring, Summer, Winter release modules); missing maintenance twice in a row revokes the credential. The Admin cert is what recruiters most commonly use as a hard filter for entry-level Salesforce admin postings, and it remains a useful credential signal even for senior admins who have moved on to architecture or development specializations.

The Salesforce Certified Agentforce Specialist credential is the proctored Salesforce certification that validates a candidate can design, build, and govern Agentforce agents in a Salesforce org. It tests topic design, Agent Action authoring, Atlas reasoning behavior, Data Library setup, Prompt Template construction, Einstein Trust Layer configuration, Testing Center workflows, and the safe rollout pattern for autonomous agents. The exam targets admins, developers, and architects whose job includes building or operating Agentforce agents in production. The credential is one of the newer additions to the Salesforce certification catalog, introduced as Agentforce moved from launch to broad adoption. It assumes basic Salesforce platform fluency (Sales Cloud or Service Cloud at a working-knowledge level) and at least three to six months of hands-on Agentforce work. Candidates who have only watched demos or completed Trailhead modules without building an agent typically struggle on the scenario-heavy questions. There is no required prerequisite cert, but Admin or Developer I helps with the underlying Salesforce platform questions.

The Salesforce AI Associate Certification is the entry-level credential for understanding artificial intelligence concepts as they apply to the Salesforce platform. Launched in 2023 amid the Einstein GPT and Agentforce push, it is designed for any Salesforce user (admin, developer, architect, business stakeholder) who wants foundational fluency in AI concepts, Einstein features, AI ethics, and how Salesforce''s AI products map to business problems. The exam validates conceptual knowledge rather than hands-on configuration skill. The exam is 40 multiple-choice questions, 70 minutes, 65% passing score, and currently free as a Salesforce-supported certification (a rare free cert; most Salesforce certifications cost $200). Salesforce intentionally priced AI Associate at zero to drive broad adoption ahead of the Agentforce-era platform shift. Pass rates are higher than the Administrator certification (around 60-70% on first attempt) because the exam is conceptual rather than configuration-heavy. The cert pairs naturally with hands-on Einstein product knowledge from Trailhead but does not require deep Apex or Einstein configuration experience.

Salesforce Anti-Money Laundering (AML) is the set of screening and compliance capabilities in Financial Services Cloud that help banks, lenders, and insurers detect and prevent money laundering during customer onboarding and ongoing monitoring. It runs identity verification, sanctions screening, adverse media checks, and politically exposed person (PEP) checks against applicants and customers, then stores the results on a structured Know Your Customer (KYC) data model inside the org. AML in Salesforce is not a single standalone product. It is delivered through the Know Your Customer framework, which connects to external Identity and Verification service providers and Screening service providers. Those providers do the actual list matching, and Salesforce records the outcome, the risk rating, and the audit trail so compliance teams can review and report.

Salesforce Anywhere was Salesforce's mobile-first collaboration product, designed to bring real-time team chat, document sharing, and Salesforce record collaboration into a unified mobile and desktop app. Launched around 2020 as a pandemic-era response to remote and distributed work, Salesforce Anywhere combined Quip-style document collaboration with Slack-style messaging in an integrated experience built around Salesforce CRM data. The product had a brief moment of strategic positioning before Slack's acquisition in 2021 fundamentally changed Salesforce's collaboration roadmap. After the Slack acquisition, Salesforce Anywhere's role narrowed substantially. Slack became the strategic collaboration product. Quip retained its document-centric position. Salesforce Anywhere capabilities were either folded into other products or quietly deprecated. Many of the unique Salesforce Anywhere features (alerts inside Salesforce, in-app collaboration on records) were absorbed into Salesforce mobile features and Lightning Experience surfaces. Anyone evaluating Salesforce collaboration today should focus on Slack, Quip, and the standard Salesforce Mobile App rather than Salesforce Anywhere as a distinct product.

A Salesforce API version is the numbered release of the Salesforce platform API that a piece of metadata, Apex class, trigger, or external integration is bound to. The number, written as a decimal like 64.0, tells the platform which set of features, fields, and behaviors to apply when that code or request runs. Every major release ships a new API version. Salesforce publishes three major releases each year (Spring, Summer, and Winter), and the API version number increases by one with each release. Because old versions keep behaving the way they always did, the version a component is saved against acts as a contract. It is one of the main ways Salesforce evolves the platform without breaking integrations that were built years ago.

The Salesforce Architect Certification is a tiered family of credentials for professionals who design enterprise Salesforce solutions. It starts with focused platform architect certifications in areas like data, integration, and identity, then ladders up to two cumulative senior credentials, Application Architect and System Architect. The track tops out at the Certified Technical Architect (CTA), which is earned by defending a live solution design in front of a panel rather than by sitting a multiple-choice exam. This is a current credential family maintained by Salesforce and surfaced through Trailhead. The lower tiers prove depth in a single domain. The upper tiers prove that you can combine those domains into a secure, scalable design that fits a real client landscape. Architects use these credentials to signal design authority on large programs, and employers use them as a shorthand for senior delivery skill.

A Salesforce Certificate and Key Pair is a cryptographic credential made up of a public certificate and a matching private key, both created and stored inside your org under Setup, in Certificate and Key Management. The certificate proves that a message, a SAML assertion, or a TLS connection genuinely came from your Salesforce org, while the private key stays protected so no one else can forge that proof. You use these credentials to sign single sign-on assertions, to authenticate outbound API callouts over mutual TLS, and to validate inbound API clients. Salesforce can generate a self-signed certificate for you, or you can upload one signed by a certificate authority. Either way, the private key never has to leave the platform unless you explicitly mark it as exportable.

A Salesforce certification is an official professional credential that you earn by passing a Salesforce exam, proving you have specific skills with a part of the platform. Salesforce groups these credentials around roles such as Administrator, Developer, Architect, Consultant, Marketer, and Designer, and they range from entry-level Associate exams up to senior Architect credentials. Each certification is tied to a particular product area or job. Passing the Platform Administrator exam, for example, shows you can configure and manage a Salesforce org. The credentials are not one-and-done. You keep them active by completing short release-aligned maintenance modules on Trailhead, so a current certification reflects current product knowledge.

Salesforce Commerce Cloud is the e-commerce platform on the Salesforce portfolio for building and operating online storefronts. It supports both B2C Commerce (consumer-facing retail and direct-to-consumer brands) and B2B Commerce (business-to-business sellers with complex catalogs, contract pricing, and approval flows). The platform provides product catalog management, shopping cart and checkout, order management, payment integration, AI-powered personalization, search, content management, and the integration surface to connect with the rest of Salesforce (Sales Cloud, Service Cloud, Marketing Cloud) for unified customer view. Commerce Cloud came to Salesforce through the 2016 Demandware acquisition (the original B2C product, now Salesforce B2C Commerce) and the 2020 absorption of CloudCraze (the B2B Commerce product, now Salesforce B2B Commerce on Lightning). The two products share the Commerce Cloud brand but run on different underlying technology stacks: B2C Commerce runs on the Salesforce-managed Commerce Cloud infrastructure, while B2B Commerce runs on the standard Salesforce platform alongside Sales Cloud.

Salesforce Commerce Cloud B2B is the business-to-business edition of Salesforce Commerce Cloud, designed for companies that sell to other businesses rather than directly to consumers. It supports the buying patterns specific to B2B: account-based purchasing where individuals buy on behalf of their employer, negotiated pricing that varies by customer and contract, bulk ordering with reorder workflows, complex approval flows for large purchases, and tight integration with Sales Cloud and Service Cloud for the rep-supported sales motion many B2B relationships still rely on. The product evolved from Salesforce CloudCraze (acquired in 2018) and was rebuilt on the Lightning Platform to align with the broader Salesforce architecture. It sits alongside Commerce Cloud B2C (the consumer-facing edition) as the two main commerce flavors Salesforce offers. Many enterprise customers operate both side by side: B2C for direct-to-consumer brands, B2B for selling to distributors, resellers, and large business buyers. The shared Salesforce data model means a single Account record can carry both a B2C customer relationship and a B2B purchasing relationship if the business spans both motions.

Salesforce Commerce Cloud B2C is the e-commerce platform Salesforce offers for retail brands and direct-to-consumer companies selling to end consumers. Originally Demandware (acquired by Salesforce in 2016), the product runs as a Salesforce-managed SaaS platform that hosts the storefront, the catalog, the cart, the checkout, the order management, and the merchant administration tools in a single integrated environment. It targets brands that sell through online channels to individual consumers at scale, with the operational features they need: high concurrent traffic capacity, CDN-cached storefront, multi-site multi-locale management, and the merchant tooling for daily merchandising operations. The product sits inside the broader Salesforce Commerce Cloud portfolio alongside B2B Commerce (on Lightning), but the two have very different architectures. B2C runs on the Salesforce-managed Demandware platform with its own developer tooling (Storefront Reference Architecture or PWA Kit) and its own data model. B2B runs on the standard Salesforce Lightning platform alongside Sales Cloud. Picking the right product depends on whether the use case is genuinely consumer-facing retail (B2C) or business-to-business selling (B2B); the answer drives the entire architecture.

Salesforce Connect is the Salesforce feature that lets you query and display data from external systems as if it lived in Salesforce, without actually importing or syncing it. The external data appears as External Objects (with API names ending in __x), behaves like custom objects in Salesforce UI and reports, but reads live from the source system on demand via OData, REST, or a custom adapter. The data never copies into Salesforce; every query hits the source. Salesforce Connect targets read-mostly integration scenarios where copying data into Salesforce would be expensive (large data volumes), stale (the source changes constantly), or compliance-restricted (the data cannot leave the source system). Typical use cases: an ERP order history surfaced on Account records, a data warehouse customer view embedded in CRM, or a partner inventory feed referenced from Cases. Write operations are supported (custom adapters) but slower than internal record updates because every write hits the external system synchronously. Most Salesforce Connect deployments are read-heavy by design.

A Salesforce Console is a type of app built for fast-paced, high-volume work, where users move between many records at once instead of opening them one at a time. It uses a tab-based workspace, an optional split view list panel, a footer utility bar, and keyboard shortcuts so agents and reps keep their context while they jump across related data. In Lightning Experience, a console is just a Lightning app whose navigation type is set to Console. Salesforce ships two ready-made console apps, the Service Console for support teams and the Sales Console for sellers, and you can also build your own. Console apps are common in contact centers and call centers, where speed across cases, contacts, and accounts matters more than slow exploration.

The Salesforce Console Integration Toolkit is a browser-based JavaScript API that gives developers programmatic access to the Salesforce console in Salesforce Classic. Code written with it can open primary tabs and subtabs, set tab titles, read tab IDs, refresh or close tabs, and run other console actions without a full page reload. It is a Classic-era tool. You load it into a Visualforce page or an allowlisted third-party domain, then call its methods from custom buttons, console components, or embedded pages. For Lightning Experience, Salesforce now provides the Lightning Console JavaScript API, which is the recommended path for new work.

The Salesforce Consultant Certification track validates expertise in designing and implementing solutions on a specific Salesforce Cloud. The track currently includes Sales Cloud Consultant, Service Cloud Consultant, Experience Cloud Consultant, Marketing Cloud Consultant, Education Cloud Consultant, Nonprofit Cloud Consultant, and Industries Cloud Consultant variants for specific industry products. Each variant has its own exam, prerequisites, topic weights, and target audience but they share the same overall pattern: prove that you can take a customer requirement and produce a well-architected Salesforce solution. Consultant certifications sit one tier above the Administrator and Platform App Builder certs in the credential ladder. They are aimed at consultants, solution architects, and senior administrators who design implementations rather than just configure them. The exam pattern is heavily scenario-based: read a customer business problem, pick the right Salesforce solution from four options. Pass rates run 40-55% on first attempt, lower than the Admin cert because the scenarios require judgment about trade-offs rather than configuration recall.

Salesforce CPQ (Configure, Price, Quote) is Salesforce's add-on product for managing complex sales quoting processes. It extends Sales Cloud to handle product bundles and configurations, tiered and conditional pricing, discount approvals, contract terms, and quote document generation. CPQ is the right tool any time the standard Opportunity Product line items cannot express what sales reps actually quote: bundled solutions, conditional add-ons, time-based pricing, volume discounts, and approval workflows for non-standard terms. The product was originally Steelbrick (acquired by Salesforce in 2015), evolved into Salesforce CPQ, and now sits under the Revenue Cloud product family alongside Billing and Subscription Management. CPQ adds a rich quoting workflow: product selection from a configurable catalog, automatic pricing with discount rules, bundle hierarchy with parent-child constraints, approval routing based on margin or discount thresholds, and generated quote documents in PDF or DOCX format. CPQ is licensed separately from Sales Cloud and is one of the more complex Salesforce products to implement, often requiring a specialized consulting partner.

Salesforce CRM Call Center is the framework in Salesforce that connects the platform to a third-party phone system, so agents can place and answer calls from a softphone that lives inside their Salesforce window. It ties each call to customer data, supports click-to-dial and screen pops, and can log call activity automatically against the right record. A call center is set up by importing an XML call center definition file that tells Salesforce which telephony system to talk to and how. This is older technology. The browser plugin model behind it gave way to Open CTI, and Open CTI itself is now in maintenance mode with a retirement date of February 28, 2028. New work should target Salesforce Voice (Service Cloud Voice).

Salesforce CRM Content is an older content management feature that stores business files in searchable repositories called libraries. It supports many file types, from presentations and documents to audio, video, and Google Docs, and lets people search across the file body, title, description, tags, and author name instead of digging through folders. CRM Content lives in Salesforce Classic. It is considered legacy. In Lightning Experience, its capabilities have largely been folded into Salesforce Files, where the same libraries and files appear under Files Home and the Libraries tab. New orgs should plan around Salesforce Files rather than building on the Classic CRM Content interface.

Salesforce Developers, reached at developer.salesforce.com, is the official developer portal and community for everyone who builds on the Salesforce Platform. It is the canonical home for product documentation, the API library, sample apps, blog posts, videos, and the forums where developers ask and answer questions. The site ties together the resources a builder needs across a project. You can read the Apex and Lightning Web Components guides, browse every REST and SOAP endpoint, sign up for a free Developer Edition org, and follow release-by-release reference docs. It sits next to Trailhead, which handles guided, hands-on learning.

Salesforce DX (Developer Experience) is the source-driven development toolset Salesforce introduced in 2017 to bring modern software engineering practices to the Lightning Platform. It bundles the Salesforce CLI, scratch orgs, source format metadata, unlocked packaging, and a set of conventions for using version control as the source of truth for Salesforce metadata. Before DX, the org was the source of truth and metadata moved through change sets or the Ant Migration Tool. After DX, the git repository is the source of truth and the org is rebuilt from it. The DX model rests on three pillars: source-driven development (your metadata lives in source files committed to git), scratch orgs (disposable orgs spun up from a definition file in under five minutes), and unlocked packages (versioned, deployable units of metadata that replace monolithic change sets). The CLI binds them together. Most modern Salesforce developer workflows, including CI/CD pipelines, automated testing, and AppExchange package development, run on top of Salesforce DX even when developers do not realize the underlying tooling is doing the work.

Salesforce Extensions for Visual Studio Code is an open-source pack of extensions that turns VS Code into a full development environment for the Salesforce Platform. It bundles tools for writing Apex, Lightning Web Components, Aura, Visualforce, and SOQL, plus an Apex Replay Debugger, an Org Browser, and a deep connection to Salesforce CLI for retrieving and deploying metadata. You install it from the Visual Studio Marketplace as the Salesforce Extension Pack. Behind the scenes it drives Salesforce CLI to talk to your orgs, scratch orgs, and sandboxes. It is the IDE Salesforce recommends for code-first development, and it replaced the retired Eclipse-based Force.com IDE.

Salesforce Feedback Management is a paid add-on that extends the native Salesforce Surveys feature so teams can collect, analyze, and act on customer feedback inside the CRM. It adds advanced survey capabilities on top of standard platform surveys, including merge fields, data maps that create or update records from responses, sentiment analysis, and higher response limits. The point of Feedback Management is to connect a survey answer to the customer record it came from. A CSAT or NPS score stops being a number on a chart and becomes operational data. Responses map onto contacts, cases, or custom objects, and a low score can kick off a follow-up task or an escalation through Flow. It is licensed in three tiers (Survey Response Pack, Feedback Management Starter, and Feedback Management Growth) and runs in Enterprise, Unlimited, and Developer editions.

A Salesforce Flow Orchestration is an automation that strings several flows together into one multi-step, multi-user process. It coordinates work that runs over hours or days, pausing between steps to wait for a person to finish a task, for an approval, or for a background flow to do its job. You build it in Flow Builder by choosing the Orchestration flow type. A regular flow runs start to finish in one go. An orchestration is different because it can stop, hand work to a named user or queue, and pick back up when that work is done. It groups the flows it runs into stages, so a long process like onboarding or a deal review has clear phases you can watch from start to finish. Since the Spring 2026 release wave, Flow Orchestration is a standard Flow type that no longer needs a separate add-on license.

Salesforce for Nonprofits is the umbrella name for Salesforce products built specifically for nonprofit organizations to manage fundraising, donor relationships, program delivery, grantmaking, and volunteer work. It is not a single feature. The name covers two distinct product lines: the older Nonprofit Success Pack (NPSP), a managed package layered on standard CRM objects, and Nonprofit Cloud, a newer suite of industry data objects that Salesforce now markets alongside Agentforce. The point of both products is the same. A nonprofit needs a system that tracks people, gifts, programs, and outcomes in one place, priced for a tight budget. Eligible organizations get heavily discounted or donated licenses through the Power of Us program, which is why so many charities run on Salesforce.

Salesforce Foundations is a Setup feature that gives existing customers a curated set of capabilities from Sales, Service, Marketing, Commerce, and Data 360 (formerly Data Cloud) at no additional cost. It is included with Enterprise, Unlimited, and Einstein 1 editions, and you turn it on from the Salesforce Foundations setup page rather than buying it separately. The point of Foundations is to let a team that started on one cloud try a useful slice of the others without a new contract. A Sales org gets basic email campaigns and a storefront. A Service org gets unified profiles and AI agents. Salesforce adds capabilities to the package each release, so it is worth checking even if your org is already mature.

Salesforce Go is a Setup-based feature discovery and implementation platform designed to help Salesforce administrators streamline configuration and drive user adoption. It bundles related features into curated sets organized around specific business objectives (Improve Sales Productivity, Increase Service Efficiency, Enhance Marketing Personalization), guiding admins through enabling, configuring, and rolling out each feature without requiring them to navigate the much broader Setup tree on their own. The product addresses one of the longest-running operational pain points in the Salesforce ecosystem: customers buy licenses for capabilities they never actually adopt because the configuration burden feels too high. A typical Enterprise Edition org pays for dozens of features that go unused because the admin team did not have the time or knowledge to set them up. Salesforce Go bridges that gap with prescriptive, guided implementation flows that take the admin from feature discovery through user-facing rollout, often in a single session. The result is more value extracted from existing license investments, which is also why Salesforce has invested heavily in the experience over the past few years.

Salesforce Government Cloud Plus is the highest-assurance edition of the Salesforce platform built specifically for United States federal, state, and local government agencies, defense organizations, and contractors that handle controlled unclassified information. It meets FedRAMP High authorization, Department of Defense Impact Level 4 (DoD IL4) authorization, and ITAR (International Traffic in Arms Regulations) compliance requirements. The infrastructure is dedicated, geographically isolated to the continental United States, and operated by U.S. citizens cleared at the appropriate level for sensitive data handling. The Government Cloud Plus product line sits above the standard Government Cloud (which meets FedRAMP Moderate) and serves customers with stricter security requirements: defense contractors building weapons systems, intelligence community agencies handling classified-adjacent data, federal agencies under the Controlled Unclassified Information (CUI) program. The functional capabilities of the platform are largely the same as the commercial Salesforce stack (Sales Cloud, Service Cloud, Experience Cloud, Platform), but the operational controls, personnel clearances, network isolation, and audit posture are significantly stricter. Customers pay a premium for these controls; the trade-off is the ability to operate Salesforce for workloads that the commercial cloud cannot serve due to compliance constraints.

A Salesforce Inbox is the set of email productivity features that Salesforce adds on top of the Outlook and Gmail integrations for Sales Cloud. With an Inbox license, sales reps can track when emails are opened, schedule messages to send later, insert their calendar availability, and use shared text shortcuts, all without leaving their email client. Inbox started as a separate paid product with its own desktop and mobile apps. Those standalone apps are older now, and the Inbox mobile app was retired in the Spring '25 release. The capabilities live on as a feature layer you switch on inside the Outlook and Gmail integrations, so the name still appears in Setup and on license assignments.

Salesforce Knowledge is the knowledge-base feature of Service Cloud. It provides the data model, publishing workflow, multilingual support, channel visibility, and search infrastructure that turn raw content into a customer-service deflection engine. The current generation is called Lightning Knowledge and runs on the KnowledgeArticleVersion object. The older Salesforce Classic Knowledge model still exists in legacy orgs and uses one custom object per article type, but Salesforce has not invested in it since 2019. Salesforce Knowledge sits at the intersection of three product surfaces: the Service Console where agents attach articles to cases, Experience Cloud where customers self-serve through a Help Center, and Einstein or Agentforce where AI retrieves articles to ground its answers. Enabling Knowledge is not just turning on a feature toggle. It requires license decisions, a record type strategy, data category design, channel governance, and an editorial process. Orgs that skip the design and just enable the feature end up with thousands of zero-view articles inside six months.

Salesforce Maps is a location intelligence add-on that plots Salesforce records on an interactive map so sales and field teams can see their data by geography. It turns address fields on accounts, leads, contacts, and custom objects into pins, then layers routing, proximity search, and territory planning on top of that map. The product answers questions that a list view cannot, like which customers sit within ten miles of a rep, where coverage gaps exist, and what the fastest order of visits is for a given day. Maps is a paid add-on rather than part of the base license, and it serves outside sales, field service, and operations teams who plan work around physical locations.

A Salesforce Maps Layer is a saved set of rules that tells Salesforce Maps which records or geographic areas to draw on an interactive map, and how to draw them. Each layer pulls from a defined source, applies filters, and renders the results as pins, colored regions, or third-party data points so field and sales teams can see their CRM data on a map. Salesforce Maps supports three layer kinds. Marker layers plot Salesforce records such as accounts, leads, and opportunities. Shape layers outline geographic areas like postal codes, counties, or hand-drawn territories. Data layers overlay non-Salesforce business, property, and demographic data sourced from third-party vendors.

Salesforce Marketing Cloud is the digital marketing platform Salesforce acquired from ExactTarget in 2013 and now markets as Marketing Cloud Engagement. It runs as a separate tenant from the core Sales and Service Cloud org, with its own data model, its own user accounts, its own API endpoints, and its own subdomain (mc.exacttarget.com). Marketing Cloud handles email, SMS, push notifications, ads, and journey-based multichannel orchestration. It targets the marketer persona rather than the salesperson or service agent who lives in core Salesforce. Marketing Cloud Engagement is one of three products in the broader Marketing Cloud family: Engagement (the original ExactTarget platform), Account Engagement (the rebranded Pardot for B2B), and Personalization (the rebranded Interaction Studio for real-time site personalization). The three products share branding but are technically distinct, with separate billing, separate UIs, and separate data models. Most enterprise Salesforce customers run at least two of them, often without realizing they are not the same product.

The Salesforce Mobile App is the official iOS and Android app that gives users a mobile-optimized view of their Salesforce org. It is downloaded from the App Store or Google Play, authenticates to a Salesforce org, and presents a touch-friendly UI for accessing records, viewing reports, running approvals, and using most Lightning Experience features from a phone or tablet. Many Salesforce users spend a meaningful portion of their workday in the mobile app, especially field-sales reps, service technicians, and on-the-go executives. The Mobile App is included free with every Salesforce license. It renders Lightning Experience pages with mobile-specific adaptations: touch targets, swipe gestures, scaled layouts, and offline support for the most common interactions. Admins configure mobile-specific behavior through Mobile Navigation menus, mobile-only Lightning pages (via Component Visibility on form factor), and the Salesforce Mobile Publisher product for organizations that want to deploy a branded, fully customized mobile app to App Store and Google Play under their own brand.

Salesforce Order Management is a platform that handles the full order lifecycle for commerce, from the moment an order is captured through fulfillment, delivery, payment capture, and post-purchase service like returns and exchanges. It gives a business one place to see and act on every order, no matter which channel created it. When an order arrives, Order Management creates an Order Summary record that tracks the order's current state and totals. Automated flows then break the order into Fulfillment Orders, route them to fulfillment locations, capture payment, and generate invoices. Service teams work the same records to process cancellations and returns.

The Salesforce Platform Developer Certification is the entry-level credential for developers building on Salesforce. The full name is Salesforce Certified Platform Developer I, commonly shortened to PDI or PD1. The exam validates working knowledge of Apex, Lightning Web Components, data modeling, the Lightning Platform, and the basics of automation and security. It is the natural next step after the Salesforce Administrator credential for developers, and the prerequisite for the more advanced Platform Developer II (PD2) certification. The exam is 60 multiple-choice questions, 105 minutes, 68% passing score, currently $200 USD (or one free voucher per individual via the Salesforce Trailblazer Free Cert program for eligible candidates). Pass rates hover around 30-40% on first attempt without prep, and 70-80% for candidates who complete the standard Trailmix. Salesforce releases periodic exam content updates aligned with major platform changes; check the current exam guide before scheduling because the topic weights shift release to release.

A Salesforce Record ID is the system-generated unique identifier that the platform assigns to every record the moment it is created. It comes in two forms: a 15-character case-sensitive version and an 18-character case-insensitive version that appends a 3-character checksum. The ID is the primary key Salesforce uses to find, query, relate, and link records across the database. Record IDs are immutable. Once assigned, an ID stays with that record for life and is never reused, even if the record is deleted and later restored from the Recycle Bin. The first three characters, called the key prefix, identify which object the record belongs to, so 001 always means Account and 003 always means Contact.

Salesforce Sales Cloud is the flagship CRM product from Salesforce, designed for sales teams to manage leads, accounts, contacts, opportunities, products, quotes, and forecasts in one cloud platform. It is the original product Salesforce launched in 1999 and remains the largest revenue line in the company's portfolio, used by sales organizations across every industry and company size from small businesses to global enterprises. Sales Cloud is licensed per user per month in editions that scale by feature depth: Essentials (small business), Professional (mid-market), Enterprise (the default for any serious deployment), and Unlimited (largest customers with the most demanding needs). Each edition adds capabilities like roll-up summary fields, custom Apex, more API calls, more storage, and access to certain features (Workflow, Approval Processes, Advanced Reporting). Sales Cloud is also the foundation product on top of which most other Salesforce clouds (Service, Experience, Commerce) are built.

Salesforce Service Cloud is the customer service product on the Salesforce platform. It provides the case management, omni-channel routing, agent console, knowledge base, entitlements, AI-powered support tooling, and field service capabilities that customer service organizations need to run their day-to-day operations at scale. The product targets every size of service team, from a single shared inbox at a small business to a global contact center with thousands of agents working across voice, chat, email, messaging, social, and self-service channels. Service Cloud is built on the same core Salesforce platform as Sales Cloud and the industry clouds, so it shares the Account, Contact, and Case data model with the rest of the org. Customers running multiple Salesforce clouds get a unified view of every customer across sales pipeline, support history, marketing engagement, and (for industry-specific orgs) clinical or financial context. Service Cloud is the most heavily-deployed service platform in the Salesforce portfolio.

Salesforce Service Oriented Architecture (SOA) is an architectural style where business logic is packaged as discrete, loosely coupled services that other systems call over the network. On the Salesforce platform, those services are usually Apex methods exposed through SOAP or REST, or integrations built so that Salesforce and external systems talk through well-defined contracts instead of direct, tangled dependencies. The idea is to treat each capability as a reusable service with a stable interface. A client calls the service without knowing how it works inside. Salesforce supports this with the webservice keyword for SOAP, the @RestResource annotation for REST, generated WSDL files, and callout classes that consume outside services. SOA is a design approach, not a single feature you switch on.

Salesforce Shield is the security-and-compliance add-on bundle for Salesforce that pairs three products together: Platform Encryption, Event Monitoring, and Field Audit Trail. It sells as an annual subscription on top of any Sales Cloud, Service Cloud, or Platform license and is the default purchase for enterprise customers in regulated industries (healthcare, financial services, government) who need stronger encryption-at-rest, deeper user activity logging, and longer field-history retention than the standard product provides. Shield does not change how the application runs day to day. End users see the same UI, admins see the same Setup, integrations call the same APIs. What Shield adds is what happens behind the scenes: encryption keys controlled by the customer, every API call and report run recorded for forensic review, and field changes preserved for up to ten years instead of the standard 24 months. Customers buy Shield when their compliance team requires controls beyond Salesforce's baseline, and they renew it as long as those controls remain a contractual or regulatory obligation.

Salesforce Surveys is a native platform feature for building, distributing, and analyzing surveys without leaving the CRM. You create surveys in a drag-and-drop builder, send them by email link, embed them on a webpage, or surface them after a chat or case closes. Responses land as records in Salesforce, so feedback sits next to the account, contact, or case it came from. The feature is included in Enterprise, Unlimited, and Developer Editions with a default allowance of 300 survey responses. Larger programs add capacity and advanced settings through Salesforce Feedback Management. Because surveys are records, you can report on them, automate follow-up with Flow, and update related records based on what a participant answers.

Salesforce Voice, formerly called Service Cloud Voice, is a native telephony product that brings phone calls into the Salesforce agent workspace next to chat, email, messaging, and other digital channels. It pairs a phone line from a telephony provider with the Service Console so service reps can take and place calls, see the full customer record, and let AI transcribe and assist in real time without leaving Salesforce. Voice is part of Agentforce Contact Center. Calls flow through Omni-Channel routing just like a chat or a case, supervisors can listen in or barge in, and Einstein turns the live transcript into next-best-action suggestions and an automatic wrap-up summary. Salesforce offers it across three telephony models, so you can run the line through Amazon Connect, a partner provider, or a Salesforce-managed setup.

A Sandbox is a separate Salesforce environment that copies the metadata (and optionally the data) from a production org for development, testing, training, or staging purposes. Every nontrivial Salesforce project uses sandboxes: developers build in one, QA tests in another, training happens in a third, and a final staging sandbox mirrors production for pre-deployment validation. Sandboxes prevent the catastrophic mistakes that would otherwise happen if every change had to be made directly in production. Salesforce offers four sandbox types, each tuned for a different stage of the development lifecycle. Developer sandboxes are smallest (200 MB data, refresh daily), best for individual feature work. Developer Pro sandboxes are larger (1 GB data, refresh daily), good for integration testing. Partial Copy sandboxes include a configurable subset of production data (5 GB), useful for UAT with realistic data. Full Copy sandboxes are a complete production replica including all data (matched storage), refresh every 29 days, and are the standard for staging environments. Each type has different storage allotments and refresh intervals that shape how teams use them.

A sandbox template is a saved, reusable definition that tells Salesforce which objects' data to copy from production when you create or refresh a Partial Copy or Full sandbox. Instead of cloning everything, you pick the objects you care about and Salesforce copies records only for those, keeping the sandbox smaller and faster to spin up. Templates live in Setup and can be reused across many sandboxes. A Partial Copy sandbox always needs one, because that is how it limits itself to roughly 10,000 records per selected object and 5 GB of attachments. A Full sandbox can use a template too, through the Object Data Included setting, when you want a complete metadata copy but only a slice of the data.

Save & New in Salesforce is a standard button on record-creation forms that saves the current record and immediately opens a new blank record of the same type, streamlining bulk data entry. The button is the bulk-entry counterpart to the standard Save button (which saves and returns to the record detail page) and the Cancel button (which discards the in-progress entry). For users entering many records of the same type back-to-back (a sales rep logging multiple calls, an admin creating multiple users, a support agent creating sibling Cases), Save & New eliminates the navigation overhead between each record. The button appears by default on standard object create pages in Lightning Experience and Salesforce Classic. It also appears on custom object create pages unless an admin removes it. Save & New can be hidden through Page Layout configuration, removed for specific record types or profiles, or replaced with a custom Quick Action that implements equivalent behavior. The default behavior is consistent across the platform: save the current input, redirect to a fresh creation form for the same object, optionally pre-populating fields based on the prior entry.

A Save As is a Salesforce action that creates a separate copy of the current report, dashboard, or list view under a new name, while leaving the original untouched. You open an existing item, make changes if you want, then choose Save As to store those changes as a brand new item instead of overwriting what you started from. The point of Save As is reuse. Rather than building a report or dashboard from a blank slate, you start from one that already has the right columns, filters, groupings, or components, then branch off your own version. The original keeps working exactly as it did, so other people who depend on it are not affected.

A Schedule in Salesforce refers to the time-based execution model that triggers a piece of automation, a forecast roll-up, a report, or a revenue allocation on a recurring calendar (daily, weekly, monthly, quarterly) or at a one-off future timestamp. The term covers several distinct features that all share the calendar-driven shape: Scheduled Apex (System.schedule), Scheduled Flows, Reporting Snapshot schedules, Dashboard schedule refresh, Revenue Schedules on opportunity products, and the older Workflow Time-Based Actions. Schedule is therefore a category, not a single feature. When a Salesforce admin or developer talks about "the schedule," the surrounding context tells you which Schedule they mean. A developer setting up overnight data cleanup talks about Scheduled Apex. A sales-ops person tracking installment billing talks about Revenue Schedules. A reporting analyst configuring a snapshot talks about the Schedule on the Reporting Snapshot. All three use the same calendar primitives but configure different platform behaviors.

A scheduled action in Salesforce is an automated action that runs at a set time relative to a record event instead of firing the instant criteria are met. The timing is usually expressed as an offset, such as 3 days after a Case is created or 1 hour before an Opportunity close date. Scheduled actions power time-based automation like reminders, follow-ups, and escalations. Today you build them with scheduled paths inside record-triggered flows. The same idea existed in the older Workflow Rules (time-dependent actions) and Process Builder (scheduled actions), both of which reached end of support on December 31, 2025.

Scheduled Jobs is a Salesforce Setup page that lists every job set to run on a timer in your org. It brings scheduled Apex classes, dashboard refreshes, report and analytic snapshots, and other timed processes together in one read-only monitor, so you can see what is scheduled, who scheduled it, when it last ran, and when it runs next. You reach it from Setup by typing Scheduled Jobs into Quick Find. The page does not let you create a schedule. It shows what already exists and gives you a Del link to cancel any job you no longer want. For an admin asking "why did this run at 3 a.m.?", this page is usually the first place to look.

A scheduling policy is a Salesforce Field Service configuration that tells the scheduling engine how to assign service appointments to mobile workers. It bundles together a set of work rules and service objectives, then the optimizer applies them to find the best resource and time slot for each job. A policy holds two kinds of settings. Work rules act as filters that drop any candidate who cannot do the work, and service objectives score the candidates who remain so the highest scorer wins. Dispatchers pick a policy when they book or optimize appointments, so the same org can run different policies for different situations.

Schema Builder is a Setup tool in Salesforce that shows the data model of an org as an interactive diagram. Objects appear as cards on a canvas, and the lookup and master-detail relationships between them appear as connecting lines. From the same canvas you can create custom objects, add custom fields, and define relationships by dragging elements, without clicking through separate Setup pages. It works as both a viewer and an editor. As a viewer it gives admins, developers, and architects a single picture of how standard and custom objects connect. As an editor it commits changes to the live org immediately, so it doubles as a fast way to build out a schema while you plan it.

Schema Settings is a Setup page in Salesforce that exposes a small but important set of org-wide toggles controlling how the data schema behaves. The settings here are not about a single object or field. They are global switches that decide whether the org supports external sharing models, whether users can truncate custom objects, whether deleting a master record sends its detail records to the Recycle Bin, and how field history capture is managed. Most of these toggles are one-way doors or have meaningful consequences across thousands of records. Schema Settings sits inside Setup under Schema Settings (older orgs) or Data Classification depending on release, and the permissions required to edit it are Customize Application plus, for some toggles, Modify All Data.

A Scratch Org is a temporary, source-driven Salesforce environment created on demand from a project's source code via the Salesforce CLI. It is the cornerstone of the Salesforce DX development model: spin up a fresh org, push the latest project source, run tests, then discard it. Scratch orgs live up to 30 days (configurable per definition file), are billed against a Dev Hub allocation rather than per-edition licenses, and start empty rather than copying production metadata or data. Scratch orgs solve problems that traditional Developer sandboxes cannot. Each scratch org represents a clean state, so developers test their feature against a known starting point rather than against the accumulated drift of a shared sandbox. The org definition file (.json) declares which features, settings, and edition to include, so the org matches exactly what production needs. Continuous Integration pipelines spin up scratch orgs to run automated tests, validate metadata, and tear them down within minutes. Scratch orgs are the standard for source-driven Salesforce development; legacy projects on older workflows often have not adopted them yet.

A screen pop is the automatic display of a Salesforce record or page on a service agent's screen the moment a call, message, or chat reaches them. The phone system passes the caller's number or other call data to Salesforce, which searches for matching records and opens the right one before the agent says hello. Screen pops live inside Salesforce computer-telephony integration (CTI) and Service Cloud Voice. An admin decides what pops by configuring a softphone layout or an Add Screen Pop action in an Omni-Channel flow. The result is that an agent starts every conversation already looking at the customer, not at an empty search box.

Search in Salesforce is the platform feature that lets users find records, files, articles, and conversations across the org by typing keywords into the global search bar (at the top of every page) or into object-specific search boxes. The platform runs a SOSL-based full-text search engine against a dedicated text index, applies stemming and synonym matching, respects record-level sharing, and returns results ranked by relevance and recency. The Search experience surfaces in several places: the global search bar in the Lightning header, lookup field searches when populating a record reference, Einstein Search (the AI-enhanced version that adds natural-language understanding), and developer-facing SOSL queries that programmatic features use to power custom search UIs. Behind every search box, the same underlying engine handles the work; configuration differences (which objects are searchable, which fields are indexed, what synonyms apply) shape what each user sees. Mature Salesforce orgs treat Search configuration as a first-class admin concern because search quality directly drives user productivity and adoption.

A Search Highlight is the bolded fragment of matched text that Salesforce shows under a search result to give the user context for why the record matched. The feature pulls a short snippet from a searchable text field on the record, places the matched terms in bold, and displays the snippet directly under the record's name and key fields in the global search results page. Search Highlights apply automatically to a small set of objects with rich text content: Cases, Salesforce Knowledge articles, Feed posts, Files, Tasks, and custom objects with searchable Long Text Area or Rich Text Area fields. Standard objects like Account and Opportunity do not get snippet highlights because their searchable fields are short labels, not narrative text. Where snippets do appear, they reduce the click-through time to the right record by letting users skim matches in the results page itself.

A Search Layout is the per-object configuration that controls which fields appear as columns when Salesforce displays the object in search results, list views, lookup dialogs, and recent-items panels. Each object has its own search layout settings managed in Setup, and each context (Global Search Results, Search Results, Lookup Dialogs, Lookup Phone Dialogs, Tab) can use a different set of fields and ordering. Search Layouts are the user-facing answer to "what should I see when this object shows up in a list." The fields visible on an Opportunity search result, for example, are not the same fields shown on the Opportunity record detail page; the search layout selects which subset to show, in which order, and the user sees only those columns regardless of the underlying record's data richness. Tuning search layouts is one of the highest-impact admin tasks because it directly affects how quickly users can identify the right record without clicking through.

A Search Phrase in Salesforce is the text string a user enters into the global search bar (or any object-specific search input) that the search engine tokenizes, normalizes, and matches against indexed fields across the org's data. The phrase travels through the platform's search pipeline: parsing, tokenization, fuzzy-match scoring, relevance ranking, then result presentation. Understanding how search phrases are processed matters because the way Salesforce's search engine interprets a phrase determines what records appear and in what order, which affects how users find information across the platform. Search phrases support several syntax patterns: simple keyword search (acme), multi-word phrases (acme manufacturing), exact-phrase matches with quotes ("acme manufacturing"), wildcards (acme*), Boolean operators (acme AND manufacturing OR distribution), and field-scoped queries (Industry:Manufacturing). The engine handles most phrasings sensibly, but power users can craft more precise queries with the advanced syntax. Salesforce's search runs across most indexed objects simultaneously in global search, with per-object scoping available through the search results page filters.

A Segment in Salesforce Data Cloud is a filter-based audience definition that produces a list of unified Individuals (or other DMO records) matching specified criteria. Segments are the bridge between raw unified data and downstream activation: marketers build a segment for "Individuals in California with Lifetime Value over $10,000 who opened an email in the last 30 days" and the same segment activates to Marketing Cloud Engagement, Google Ads, Meta Audiences, or any other connected destination. Segments are built declaratively in the Segment Canvas, a visual filter builder where users drag DMO attributes onto criteria nodes, combine with AND / OR logic, and preview the audience size in real time. Behind the scenes the segment runs as Data Cloud SQL against the unified profile. Segments materialize on a schedule (typically hourly, daily, or on-demand) and produce a versioned audience snapshot; downstream activations consume the snapshot. The combination of Identity Resolution feeding unified Individuals plus Segmentation producing targeted audiences is the heart of Data Cloud's marketing value proposition.

A semi-join is a SOQL query pattern that filters records in one object using a subquery against a related object placed inside an IN clause. The outer query keeps only the rows whose ID or foreign key field matches an ID returned by the inner subquery, so you fetch parents that have qualifying children without pulling the children themselves. A common example is selecting accounts that have at least one closed-lost opportunity: SELECT Id, Name FROM Account WHERE Id IN (SELECT AccountId FROM Opportunity WHERE StageName = 'Closed Lost'). The database resolves the relationship in a single round trip. Its mirror image, the anti-join, swaps IN for NOT IN to return records that have no matching related rows.

Send through External Email Services is a Salesforce Setup feature that lets an org route outbound emails (transactional, automated, and Send Email from records) through a third-party email service like Amazon SES, SendGrid, Mailgun, or Postmark instead of the built-in Salesforce email infrastructure. The feature gives the customer direct control over deliverability, tracking, sender reputation, and compliance with the same gateway their other applications already use. The feature is particularly relevant for customers with strict deliverability requirements (financial services confirmations, healthcare notifications, government communications) or for those who have invested in a third-party email infrastructure and want a single sending platform across all their applications. Once configured, the outbound email flow goes Salesforce → external service → recipient, with the external service handling MX routing, sender authentication, suppression lists, and delivery analytics. The Salesforce UI for sending email looks the same; the change is entirely in the delivery path.

Service in Salesforce refers to the customer service side of the platform, the tools and data model that let support teams capture, route, and resolve customer requests. It is delivered through Service Cloud, the product built around the Case object and a workspace where agents handle questions across email, phone, chat, and messaging. In practice, "Service" is the umbrella for everything a support organization touches in Salesforce. That includes cases, knowledge articles, entitlements and milestones, omni-channel routing, and the Service Console agents work from. Where Sales Cloud is organized around closing deals, Service is organized around helping the customer after the sale.

A Service Appointment is a Salesforce object that records when and where work gets done for a customer, including the scheduled time, the assigned worker, and the location. It is the unit the scheduler and dispatcher work with every day, and it sits at the center of Field Service alongside related products like Salesforce Scheduler, Intelligent Appointment Management, and Virtual Care. Each appointment usually hangs off a parent record, most often a work order or work order line item, but the parent can also be an account, asset, opportunity, lead, or another object. The appointment carries its own time window, status, duration, and territory, so the work to be done (on the parent) stays separate from the commitment of when a resource shows up to do it.

A Service Channel is a Salesforce object that defines a category of routable work inside Omni-Channel. Each Service Channel ties a specific sObject (Case, LiveChatTranscript, MessagingSession, custom object) to a Routing Configuration that decides how the work is matched to agents. The Service Channel is what makes Omni-Channel work-type-aware: a Cases channel and a Chats channel can use different routing rules, different capacity weights, and different presence categories, all running in parallel. Salesforce ships standard Service Channels for the platform's built-in work types: Cases, Chats, Leads, Live Messages, Voice Calls. Custom Service Channels can be created for any custom object, which turns Omni-Channel into a generic routing engine for whatever Salesforce-tracked work the team handles. A Service Channel is the lowest-level routing primitive; without one, work of a given type cannot be routed through Omni-Channel. Configuring Service Channels correctly is the first step in any Omni-Channel rollout.

Service Cloud is Salesforce's customer support and service product, built around managing customer interactions across phone, email, chat, social media, messaging apps, and self-service portals. It is the second-largest Salesforce product after Sales Cloud and the foundation for support, customer success, field service, and contact center operations in tens of thousands of orgs. Service Cloud bundles the Case object (the central record for a customer issue), Console UX (a workspace optimized for handling multiple Cases simultaneously), Omni-Channel Routing (intelligent assignment of Cases and other work items to agents based on capacity and skills), Knowledge (article management for self-service and agent assistance), Service Catalog (forms for submitting service requests), Live Agent / Chat / Messaging (real-time channels), CTI integration (telephony), and Field Service Lightning (mobile field-service workers). Each capability is licensed separately or bundled in Service Cloud editions. Like Sales Cloud, Service Cloud comes in Starter, Pro Suite, Enterprise, Unlimited, and Einstein 1 Service editions.

Service Cloud Reports are the reports and dashboards that measure customer service performance on Salesforce, built mostly on the Case object and related support records. They track case volume, resolution time, agent productivity, milestone and SLA compliance, channel mix, and customer satisfaction so service leaders can see how the support operation is actually running. The term covers two things that work together. First, the standard and custom report types Salesforce ships for support data, such as Cases, Case History, and Case Lifecycle. Second, the prebuilt service reports and dashboards you can install from Setup as a starting point, then adapt to your own queues, record types, and metrics.

Service Cloud Voice is a Salesforce feature that brings phone calls directly into the Service Console, so agents handle voice alongside chat, email, and other channels in one place. It pairs a built-in softphone with real-time call transcription and AI recommendations, and it routes calls through Omni-Channel like any other work item. Salesforce also markets this product as Salesforce Voice. It runs on a cloud telephony provider rather than on-premises phone hardware, with Amazon Connect as the most common backend. Because the conversation is transcribed live, Einstein and Agentforce can surface knowledge articles and next steps while the call is still active.

The Service Console is the Salesforce Lightning app purpose-built for customer support agents who need to work multiple cases simultaneously without losing context. It uses a tabbed workspace layout where each case opens as a primary tab with sub-tabs for related records (the contact, the account, the related knowledge article). Agents can switch between four or five cases at a time, keeping each one's state intact, including unsaved typing, scroll position, and the open record relationships. The console is the daily-driver UI for any Service Cloud-licensed agent. Service Console is a Lightning App, configured in the Lightning App Builder, with components like Highlights Panel, Compact Case Feed, Knowledge sidebar, and Utility Bar widgets (softphone, chat, notes). It coexists with Sales Console (a sibling app with the same tabbed framework, tuned for opportunity workflows) and with standard Lightning apps (single-record-at-a-time, no tabs). The console UX is what justifies the Service Cloud per-user license premium. Without it, agents either juggle browser tabs or lose context on every record switch.

A Service Contract is a Salesforce Service Cloud object that represents a customer support agreement between your company and a customer. It records the terms of that agreement, such as the coverage period, the products or assets included, and the support a customer has paid for. The object has been part of the API since version 18.0. Service contracts sit at the top of Salesforce entitlement management. They hold contract line items for covered products and connect to entitlements that define the actual service-level rules agents follow. When a contract is in place, support reps can see what each customer is owed instead of guessing.

Service Optimization is the Salesforce Field Service capability that solves the dispatch problem: given a set of work appointments and a set of mobile workers with skills, locations, and schedules, assign each appointment to the best-fit worker and time slot so the field service operation meets its KPIs. The engine considers travel time, skill match, working hours, customer windows, service level agreements, and cost preferences in a single optimization pass and returns a schedule that minimizes the configured objective. Service Optimization is delivered as an add-on engine within Salesforce Field Service (the product that used to be called Field Service Lightning). The engine runs on demand or on a schedule, taking the current open appointments and worker schedules as input and writing a proposed schedule back to the platform. Dispatchers review the proposal, adjust as needed, and release. The optimizer is the difference between a 30-tech operation that can plan one day at a time and a 300-tech operation that needs to plan a full week with thousands of constraints in seconds.

A Service Resource is a Salesforce record that represents an individual worker or a service crew that can be assigned to service appointments. It lives in the ServiceResource object and is shared by Field Service, Salesforce Scheduler, and Workforce Engagement. Each Service Resource links a Salesforce user (or a crew) to the scheduling engine and carries the attributes that scheduling depends on: resource type, skills, service territory membership, operating hours, and capacity. When you assign work to a person in Field Service, you are really assigning it to their Service Resource record.

A Service Setup Assistant is a guided setup tool in Salesforce that walks an administrator through configuring Service Cloud features step by step. It lives inside Service Setup and turns a long manual checklist into a sequence of prescriptive flows, each one enabling a feature and applying default objects, queues, permission sets, and page layouts along the way. The goal is speed without losing best practice. Instead of researching how to enable Email-to-Case or Omni-Channel from scratch, an admin clicks through short flows that ship with sensible defaults. The assistant is non-intrusive, so any configuration that already exists in the org stays untouched while new features are layered on top.

A Service Territory is a Salesforce Field Service object that represents an area where field work is performed, such as a city, region, or functional zone. It groups the mobile workers who cover that area, the operating hours they keep, and the addresses the scheduler uses to plan routes. Territories anchor scheduling and dispatch. When a work order or service appointment falls inside a territory, Salesforce matches it to resources assigned to that territory and respects the hours and rules defined there. Territories can be geographic, functional, or virtual.

A Session ID in Salesforce is the unique authentication token issued to a user after they sign in. The token represents an active session and is sent on every subsequent API call to prove identity. The Session ID is the user's bearer credential: anyone holding it can act as that user until the session expires or is revoked. Salesforce issues a Session ID through every login channel: the standard username and password login, SAML or OpenID Connect single sign-on, OAuth 2.0 web server and client credentials flows, and the Apex UserInfo.getSessionId() method inside an active interactive context. The token expires based on the session settings configured at the org or profile level; the default is 2 hours of inactivity and 12 hours absolute. Refresh tokens (issued in OAuth flows) let an application request a new Session ID without re-authenticating the user.

Session Management is a Setup page in Salesforce where administrators view and end active user sessions across the entire org. It lists each session with the user, the session type, the login type, the time it started, and the source IP address, plus a Remove action that ends the session on demand. You reach it from Setup by entering Session Management in the Quick Find box. The page covers browser sessions, OAuth and JWT access token sessions, and mobile app sessions. Removing a session forces that connection to authenticate again, which makes the page the place where security teams cut off a suspicious or stale login.

Session Settings is the Setup page in Salesforce where admins configure how user sessions behave: how long a session stays active, when it requires re-authentication, what triggers an automatic logout, what cookies and tokens are set, whether IP changes invalidate the session, and whether high-assurance actions require step-up MFA. The page is found at Setup, Security, Session Settings, and it is the single most consequential security configuration in any Salesforce org. Session settings interact with three other security surfaces: Login IP Ranges (which restrict which networks can authenticate), Password Policies (which govern credential lifecycle), and Identity Verification (which adds multi-factor steps). Together they form the org's authentication and session security posture. The defaults are intentionally permissive for new orgs to avoid breaking customer experience. Most production orgs need to tighten the defaults: shorter session timeout, MFA requirement, force logout on session timeout, lock sessions to IP. The session settings page is where each of these decisions becomes a checkbox or a dropdown.

Session Timeout is the inactivity period after which Salesforce ends a user's session and requires re-authentication. The platform tracks user activity (page interactions, API calls) and resets the timer on each interaction. When the timer elapses without activity, the session is invalidated and any subsequent API call or page load returns a 401 Unauthorized error or redirects the browser to the login page. Session Timeout is one of two timers Salesforce applies to every session. The inactivity timeout (Timeout Value in Session Settings) is what most admins mean by "session timeout"; it runs from the last user activity. The absolute timeout (Maximum Session Length) runs from session creation regardless of activity. Either timer expiring terminates the session. The inactivity timeout is configurable from 15 minutes to 24 hours; the absolute timeout from 1 hour to 24 hours. Profile-level overrides can tighten either timer for sensitive user populations.

Set Up CRM Analytics for Manufacturing is a guided Setup wizard that deploys a pre-built CRM Analytics app containing dashboards, datasets, and dataflows tailored to Manufacturing Cloud. The app reads from standard Manufacturing Cloud objects such as Sales Agreement, Account Forecast, and Account, then enriches them with order and product data to give sales operations a starting view of demand, revenue, and agreement performance without building anything from scratch. The wizard is intended to compress what would otherwise be several weeks of dashboard design and dataflow authoring into a single afternoon of configuration. It is the right starting point for any org rolling out Manufacturing Cloud where the analytics team wants a baseline before customizing. The deployed dashboards are fully editable, so most orgs treat the wizard output as the foundation rather than the final state.

Setter Methods in Salesforce Apex are methods on a controller class that receive values from user input on a Visualforce page or from external code that assigns to a property. They follow the naming convention set[PropertyName]() (set followed by the capitalized property name) and accept one parameter of the type the property holds. The platform invokes setters automatically as part of the Visualforce lifecycle: when a user submits a form on a Visualforce page, the platform deserializes the form fields into the corresponding controller properties by calling the setter for each. Setters paired with getters (get[PropertyName] methods that return the property value) implement the JavaBean property pattern that Visualforce expects. Modern Apex also supports the shorter automatic property syntax (public String name with get and set blocks), which the compiler expands into equivalent getter and setter methods. Lightning Web Components do not use Apex setters in the same way; the framework relies on @api-decorated properties for parent-to-child data flow and on JavaScript setters for internal component state.

A setting in Salesforce is an individual configuration option in the Setup menu that controls how the platform, a feature, or the user experience behaves for the whole org. The word "Settings" (capitalized) usually refers to the broad family of these pages that administrators open from Setup to turn capabilities on, define policies, and tune default behavior without writing code. Settings are grouped into sections such as Company Settings, Security, User Management, Feature Settings, and platform tools. Each page owns a narrow slice of behavior, like the fiscal year, password rules, or whether a Sales feature is active. Most settings are org-wide and declarative, which is why they sit at the center of nearly every admin task.

Setup is the Salesforce administration area where admins, developers, and architects configure every aspect of an org. Access happens through the gear icon in the top-right of the Lightning Experience header, which opens a sidebar navigation organized by category: Administration (Users, Profiles, Permission Sets, Roles), Platform Tools (Apps, Objects, Process Automation, Flow, Apex), Settings (Company Information, Single Sign-On, Login Hours), and many more. Every configuration change an admin can make on the platform happens inside Setup. Setup is also the navigation root for the search-driven Quick Find bar that admins use to jump to any configuration page without browsing the tree. Typing the name of a feature (Profiles, Flow, Sharing Settings, Workflow Rules) into Quick Find opens the right Setup page in one keystroke. Mature Salesforce admins live in Quick Find rather than the tree; the keystroke-driven navigation is the difference between fast and slow Salesforce work.

Setup Home is the landing page of the Salesforce Setup menu in Lightning Experience. It is the screen you reach when you click the gear icon in the top corner and choose Setup, and it gives you one place to start any administrative task in your org. The page combines a Quick Find search box, a tree of setup nodes grouped into Administration, Platform Tools, and Settings, an Object Manager tab, a Recent Items list, and a carousel of quick-access tiles. Salesforce also surfaces recommendations and status messages here so admins can spot work that needs attention before opening individual pages.

Setup with Agentforce (Beta) is an experimental Salesforce feature that wraps the Setup interface in a natural-language chat. Admins ask the agent to create custom fields, build flows, configure permission sets, and adjust org settings in plain English. The agent reads the request, generates the corresponding metadata change, shows a preview of what will be created or modified, and applies it on confirmation. Work that historically required twenty clicks across multiple Setup pages collapses to one sentence and one approval. The feature is a Beta as of mid-2026, which means it ships in production orgs behind a feature flag, accepts feedback as the primary signal, and may change behavior between releases. Only a subset of Setup actions is supported, and complex multi-step configurations (deploying a managed package, configuring SSO) still require the traditional UI. The right way to think about Setup with Agentforce is as a fast path for the routine 80 percent of admin work, not a replacement for hands-on Setup expertise.

A Share Group is a set of users that gains access to records owned by high-volume Experience Cloud users (formerly called High-Volume Portal Users). It is configured as a child of a Sharing Set in Setup, Digital Experiences, Settings. The Share Group extends the same record access the Sharing Set grants to external community users out to internal Salesforce users, partner users, or other community user groups. Share Groups exist because high-volume external users do not participate in the role hierarchy. Records they own cannot be shared upward through hierarchy roll-up, and they cannot be added to normal sharing rules. The Share Group is the bridge: it lets the internal customer-service team or the partner administrators reach those records by membership in the group, without forcing the external users into a role-based sharing model that does not scale to community sizes.

A Shared Activity is a single task or event in Salesforce that is related to more than one contact at the same time. With the feature turned on, one meeting or call can link to up to 50 contacts and one lead, instead of forcing you to log a separate record for each person. The feature exists because a real meeting usually has more than one attendee. Shared Activities keeps that reality in your data. One activity record shows up in the timeline, related lists, and reports for every contact it touches, so you do not lose history or count the same conversation many times.

Sharing is the Salesforce record-level access framework that decides which users can read or edit which individual records. It sits one layer above field-level security (which controls columns) and one layer below profile and permission set object permissions (which control whole-object access). Where profiles decide whether you can see Accounts at all, Sharing decides which specific Account records you can see. The framework is layered. Org-wide defaults set the baseline access for an object. Role hierarchy grants upward visibility to managers. Sharing rules open access to defined groups based on owner or criteria. Manual sharing lets owners grant per-record access. Teams and territories grant deal-specific or geographic access. Apex managed sharing handles cases the declarative tools cannot cover. Every layer can only widen access from the OWD baseline. Nothing in this stack can revoke access that profiles or permissions grant directly.

A Sharing Group in Salesforce is a system-managed group that the platform creates and maintains automatically to implement record-level sharing rules, role-based sharing, territory assignments, and similar declarative sharing configurations. Sharing Groups are not directly user-facing; admins do not create them through the UI. They exist behind the scenes, populated and adjusted by the platform whenever sharing settings change, to make sharing rule evaluation efficient at query time. Knowing that Sharing Groups exist matters in three contexts. First, performance troubleshooting: a Sharing Group recalculation triggered by a sharing rule change or a role hierarchy adjustment can lock the affected records and degrade performance for hours. Second, governor limit awareness: row-cause grants tied to Sharing Groups count against the sharing data volume that drives platform limits. Third, certification exams: Salesforce Architect exams (Sharing and Visibility, System Architect) include questions about Sharing Groups and the recalculation behavior.

The Sharing Model in Salesforce is the complete record-level access architecture that determines which users can see and modify which records across the org. It is not a single feature but a layered system combining Organization-Wide Defaults (OWD), Role Hierarchy, Sharing Rules, Manual Sharing, Apex Managed Sharing, Account Teams, Opportunity Teams, Case Teams, and territory-based sharing. Each layer adds permissions on top of the layers below; permissions are additive, not subtractive, with limited exceptions. The sharing model works alongside but separately from profile-level permissions. Profiles say "this user can read Accounts in general"; the sharing model says "this user can read this specific Account record." Both must permit the access for a user to see a record. Designing the sharing model is one of the most consequential decisions in a Salesforce implementation because it shapes who can do what across every object in the org. Mature orgs invest significant architectural effort in the sharing design and audit it regularly as the business evolves.

A Sharing Rule in Salesforce is an org-wide configuration that grants record access to a set of users based on either record ownership or record criteria. The rule sits inside the broader Salesforce sharing model, layered between Organization-Wide Defaults (the base access level) and Manual Sharing (record-by-record grants). Sharing Rules grant access; they cannot restrict it. Once a Sharing Rule fires, the users it targets get access at the level the rule specifies, regardless of role-hierarchy position or other sharing mechanisms. Sharing Rules exist because Organization-Wide Defaults are intentionally restrictive in most Salesforce orgs. Setting Account or Opportunity to Private OWD locks every record to its owner; only Role Hierarchy access and Sharing Rules open that lockdown back up. Without Sharing Rules, every cross-team visibility need (a manager seeing a peer-team's deals, a service rep seeing a sales rep's Account, a finance user seeing every renewal Opportunity) requires either Role Hierarchy gymnastics or hundreds of manual Share clicks. Sharing Rules are the structured layer that makes those access patterns repeatable.

Sharing Settings is a Setup page in Salesforce where administrators define the organization-wide default (OWD) access level for each object and create the sharing rules that extend access beyond those defaults. The OWD section sets the baseline visibility every user has to records they do not own, choosing from levels like Private, Public Read Only, and Public Read/Write per object. The page works as the floor of the record-level security model. Role hierarchies, sharing rules, manual shares, and Apex sharing all stack on top to grant more access. None of those tools can take access below what the OWD sets, so Sharing Settings is where you decide how locked down each object starts.

A Chatter Share is an action on a feed post that re-surfaces that existing post into a different feed, such as a Chatter group, your own profile feed, or your followers. It does not copy the text into a brand-new post. It places a reference to the original post into a new audience so people outside the original scope can see it, while the original stays where it was written. Share sits alongside the other reactions you can take on a post. A Comment adds a reply that stays attached to the original post. A Like is a lightweight reaction. A Share moves the post itself into a new feed context and links back to the source, so reactions and comments stay anchored to the original rather than being duplicated.

Shift Management in Salesforce is the Workforce Engagement feature that lets contact center supervisors create, assign, and manage agent work shifts. Each Shift record specifies the start time, end time, location, channel assignments, and the agent assigned to work it. The platform supports recurring shifts (the same Tuesday-to-Saturday schedule every week), one-off shifts (a Saturday overtime shift for a peak event), and shift swaps (an agent trades their Friday shift with a colleague Saturday shift). The Shift Management surface lives in the Service Console for both agents (who see their personal schedule) and supervisors (who see team-wide coverage). The feature sits inside the broader Workforce Engagement Management product alongside forecasting (predicting work volume), capacity planning (translating forecast into headcount), and intraday management (real-time adjustment when reality diverges from plan). Shift Management is where the capacity plan becomes the actual schedule that agents work. Without it, supervisors manage shifts in spreadsheets and the contact center scales poorly past 30 to 50 agents.

A shift pattern is a reusable Salesforce record that defines a repeating sequence of shifts, so schedulers can generate many shifts at once instead of building each one by hand. The pattern is measured in days, and it points to shift templates that supply the actual start time, end time, and other details for each day in the cycle. Shift patterns are part of the shift scheduling tools shared by Field Service and Workforce Engagement. A scheduler defines a pattern once, like three morning shifts and two evening shifts across a week, then applies it to a worker or to open demand and repeats it as many cycles as needed.

Shift Scheduling in Salesforce is the suite of capabilities for planning, assigning, and managing work shifts across teams that staff service centers, field operations, or any business function organized around scheduled time blocks. The feature lives primarily inside Workforce Engagement Management for service center scheduling and inside Field Service for technician scheduling, with overlap in the underlying Shift object that both products use. The configuration spans several Setup areas: Workforce Engagement Settings for service center forecasting and scheduling, Field Service Settings for technician territories and operating hours, and the Shift object itself for the records that represent each work assignment. Done well, Shift Scheduling answers two questions reliably: who is working when, and is the staffing level matched to demand. Done poorly, it becomes a source of agent frustration and unfilled coverage gaps.

A Shift Template is a reusable Salesforce record that stores the shape of a working shift, so admins do not rebuild the same details every time they schedule one. It holds defaults like the start time, end time, job profile, service territory, and time slot type. When you create shifts from the template, those values copy onto each new Shift record automatically. Shift Templates live in Field Service, Workforce Engagement, and Salesforce Scheduler, which all share the same underlying scheduling objects. The template defines what a single shift looks like. A Shift Pattern then references one or more templates to define how shifts repeat over days and weeks. The two work as a pair to turn manual roster building into generated records.

Show/Hide Details is a Salesforce report viewing option that toggles whether the individual record rows behind a grouped report appear or stay hidden. When details are hidden, the groupings, subtotals, grand total, record counts, and summary formulas still show, but the underlying detail rows disappear from view. It is a display setting applied at run time, not a change to how the report is built. The same report can be read as a high-level summary one moment and as a full record-level list the next, just by flipping the toggle.

The Sidebar is the column that runs down the left side of most Salesforce Classic pages. It gives users quick access to links and commands, and it holds standard pieces like Recent Items, the Create New shortcut, Messages and Alerts, Custom Links, and any custom components an admin adds. This is a Classic-era feature. It is available in Salesforce Classic in all editions except Database.com, and it has no direct equivalent in Lightning Experience. Lightning splits the same jobs across the navigation bar, the App Launcher, and the utility bar, so the Sidebar mostly matters today for orgs still on Classic or teams planning a migration.

Single Sign-On Settings is the Setup page in Salesforce where admins configure SAML and OpenID Connect (OIDC) integrations that let users log into Salesforce with credentials from an external identity provider (Okta, Azure AD, Google, OneLogin, ADFS, others). The page lets the admin upload the identity provider's certificate, define the SAML attribute mapping, set the entity ID and login URL, and turn SSO into the primary or only login path for the org. Once configured, users land in Salesforce already authenticated, with their identity verified by the external provider. Single Sign-On Settings is the bridge between Salesforce and the enterprise identity stack. Most large organizations centralize authentication in an external identity provider for compliance, user lifecycle management, and security policy enforcement. SSO Settings lets Salesforce participate in that central identity model. Beyond convenience, SSO is the prerequisite for many enterprise policies: forced MFA at the IdP level, conditional access based on device posture, automated deactivation when users leave the company. The Salesforce login screen becomes a portal to the IdP, not a standalone credential gate.

Site.com was a Salesforce drag-and-drop web content management system used to build branded, dynamic websites hosted on the Salesforce platform without writing code. It targeted marketing teams and admins who needed public-facing pages tied to Salesforce data but did not have web developers on hand. Salesforce retired Site.com as an actively developed product line and folded its core capabilities into Experience Cloud (formerly Community Cloud). Sites built on the original Site.com runtime are still supported on existing orgs, but no new investment goes into the platform. New public-facing site projects should be built on Experience Cloud's LWR (Lightning Web Runtime) or Aura template, not on Site.com.

Salesforce Sites (originally Force.com Sites) is a platform feature for building public web pages that anyone on the internet can open without logging in. The pages are hosted on Salesforce itself, run on a branded company domain, and can read and write the org data you choose to expose. Sites serve unauthenticated visitors through a guest user. You decide exactly what that guest user can see and do, then publish pages built with Visualforce and Apex. Common uses include lead capture forms, event registration, knowledge lookups, and simple landing pages that feed information straight into your org.

Sites and Domains is the centralized Setup area in Salesforce for managing every custom domain, hostname, and site configuration the org exposes to the public internet. It consolidates the configuration that used to live across multiple separate Setup pages (Sites, Domains, My Domain, Custom URLs, Site.com) into a single management surface where admins can register custom domains, attach them to Experience Cloud sites or Salesforce Sites, configure SSL certificates, and manage URL redirects. The page is the gateway for any work that exposes a Salesforce-hosted asset on a customer-branded URL: a community at community.acme.com instead of acme.force.com, a self-service portal at help.acme.com, or a public website built on Salesforce Sites at www.acme.com/products. Each domain registered here participates in the org's overall domain hierarchy with Distinct DNS, SSL, and routing configuration. Misconfigured domains are the single most common cause of broken sites in Salesforce.

A Skeleton Template in Salesforce is a bare page structure that supplies only the outer framework of a page, such as the HTML, head, and body tags, with no built-in Salesforce header, sidebar, navigation, or default styling. Developers reach for it when they want full control over the markup and design of a page rather than inheriting the standard Salesforce chrome. The idea shows up in two older places. In Visualforce, you build a skeleton by turning off the platform UI and stylesheets on the apex:page tag. In the legacy Site.com builder, a page template defined the reusable shell, and a near-empty template acted as the skeleton starting point. Both approaches predate Lightning Web Runtime and Experience Builder, so the term is treated as legacy today.

A Skill in Salesforce is a standard object that represents a specific competency, certification, or capability, such as an HVAC certification, fluency in Spanish, or a security clearance. Salesforce defines the Skill object as a category or group of agents or service resources used in Field Service, Omni-Channel routing, and Workforce Engagement. The object is lightweight: each record mainly stores a label, an API name, and an optional description. Skills become useful when you attach them to work and to people. A work item (a service appointment or a case) declares which skills are required, and a person (a service resource or an agent) declares which skills they hold. The matching engine then assigns the work only to qualified people. This is the backbone of skills-based scheduling in Field Service and skills-based routing in Omni-Channel.

Slack is Salesforce's enterprise collaboration platform, acquired in 2021 for $27.7 billion and now positioned as the conversational layer across Salesforce's customer engagement stack. Slack organizes work around channels (topic-based or team-based conversation spaces), direct messages, threads, and shared apps. Salesforce-Slack integration brings CRM data into channels, Agentforce agents into conversations, automated notifications from Salesforce records, and a unified work surface where the company's data and discussions coexist. Slack is licensed separately from base Salesforce, with editions ranging from free to Enterprise Grid for the largest deployments. The Salesforce-Slack integration is bidirectional: Salesforce-side features include Slack notifications from Flow, Sales Engagement integration, Service Cloud channel integration, Agentforce in Slack, and Slack-Salesforce app connections. Slack-side features include rich CRM card displays, slash commands that act on Salesforce records, and channel-based deal rooms or case rooms that link to specific records. The combined platform is Salesforce's strategic play to become the primary work surface for sales, service, marketing, and IT teams.

Slack Apps Setup is the Salesforce Setup-area page where admins install, configure, and manage the suite of Slack apps that integrate Salesforce with Slack: the core Salesforce-for-Slack app, the Slack Sales Elevate app, the Slack Service Cloud app, the Agentforce in Slack app, and any third-party AppExchange-distributed Slack apps. Each app has its own configuration: OAuth credentials, channel mappings, user provisioning rules, and feature toggles. Slack Apps Setup is the single entry point for all of them. The page lives under Setup, Quick Find, Slack Apps Setup. It exposes a list of installed Slack apps with status indicators (Connected, Not Connected, Needs Update), per-app configuration links, and a deployment health check. For orgs running multiple Slack integrations (a common enterprise pattern), this page is the operations dashboard for the Slack-Salesforce surface area. Without it, admins would have to navigate to each app's settings independently, scattered across Setup; with it, the integration is configurable and monitorable from one screen.

Slack Channels for Records is the Salesforce-Slack integration feature that automatically creates a dedicated Slack channel for a specific Salesforce record (Opportunity, Case, Account, custom object) and keeps it in sync. Teams collaborating on the deal or case work in the channel; the channel header shows record fields, key links, and record-status updates posted as messages. The integration bridges Salesforce structured data and Slack conversational collaboration without admins having to manually create channels per record. The feature is part of the Slack-Salesforce native integration that shipped alongside the 2021 Slack acquisition. Each record-channel link is configured via a Salesforce object setting and an admin-provided channel naming template. When a record meets the trigger criteria (Opportunity stage flips to Negotiation, Case priority is set to Critical), the Salesforce-Slack app creates the channel, invites the right users, posts initial context, and pins the record URL. Subsequent record updates surface as channel messages; channel discussions surface as Activity entries on the record. The integration is Salesforce-native (not a third-party app) and is included with Slack-Salesforce connected orgs.

A Snippet in Salesforce Marketing Cloud Engagement is a reusable block of content you build once in Content Builder and reference in many emails, templates, landing pages, and mobile messages. In the Content Builder editor it appears as the Code Snippet block type, which holds custom HTML and AMPscript that you save to your content library and drop into any message. The point of a snippet is one source of truth for repeated content. A legal disclaimer, a header, a footer, or a preference-center link lives in a single snippet, and every message that references it shows the current saved version. Update the snippet once and the change reaches everywhere it is used, so you never hand-edit dozens of emails.

SOAP (Simple Object Access Protocol) is the XML-based messaging protocol that powers the Salesforce SOAP API, the platform's original integration channel. SOAP defines how clients send strongly-typed XML requests to a service and receive XML responses, with the contract described by a WSDL (Web Services Description Language) file. Salesforce publishes two WSDLs: the Enterprise WSDL (typed to the org's exact schema) and the Partner WSDL (generic across all orgs). Salesforce's SOAP API offers the same core capabilities as the REST API (create, read, update, delete, query, search) but in a verbose XML format that older middleware platforms still expect. SOAP was the only Salesforce API until REST API launched in 2010; many integration platforms standardised on SOAP long before REST became the default. SOAP remains fully supported in 2026 and is the right choice when the integrating tool only speaks SOAP or when the org needs the strict type checking that WSDL contracts provide.

The Salesforce SOAP API is the original programmatic interface to the Salesforce platform, released in 2003 and still in active use today. It exposes Salesforce data and metadata through XML-based SOAP envelopes and is described by a WSDL document that admins download from Setup. Most enterprise integration platforms (MuleSoft, Informatica, Boomi, IBM Integration Bus) consume the SOAP WSDL and generate strongly-typed client code that calls into Salesforce. SOAP API splits into two WSDLs. The Enterprise WSDL is strongly typed to the connected org's schema (objects, fields, relationships are specific to that org) and is appropriate for client code that targets one Salesforce environment. The Partner WSDL is loosely typed (uses generic sObject references) and is appropriate for ISV tools that need to work across many customer orgs without recompiling. Both authenticate via OAuth (recommended) or username/password (legacy). The newer REST API is the modern default for most integrations, but SOAP remains in production for legacy patterns and for tools that prefer its strongly-typed model.

An sObject (short for Salesforce Object) is the Apex data type that represents a row of Salesforce data. Every standard object like Account or Contact, and every custom object like Invoice__c, has a matching sObject type in Apex. When you query a record, build one to insert, or pass record data between methods, you are working with an sObject. There is also a generic sObject type with a lowercase first letter in writing but the same SObject class underneath. The generic type can hold a record of any object, which lets you write code that does not know its object type until runtime. Specific types such as Account give you compile-time field checking. Both share the same DML and method surface, so the choice is about how much type safety you want.

Social Determinants of Health (SDoH) is the Salesforce Health Cloud data model that captures the non-clinical factors influencing a patient's health outcomes: housing stability, food security, transportation access, financial strain, education, employment, social support, and community safety. The model is built on a set of standard objects (HealthCloudGA__SDoHIndicator__c and related) that record each domain's status, severity, and source for every patient or member. Social Determinants of Health surfaced in U.S. healthcare policy around 2018 and became a Health Cloud first-class data model in the Winter 21 release. Care teams use it to identify patients whose clinical care is being undermined by social conditions (a diabetic patient skipping medication because they cannot afford it, an elderly patient missing appointments because they have no transportation), then connect them to community resources (food banks, transportation services, financial assistance programs). The data model also feeds risk stratification, care plan personalization, and value-based-care reimbursement analytics.

A softphone is a software based phone interface inside Salesforce that lets a service agent make, answer, and control calls without a physical desk phone. It lives in the utility bar of a Lightning console app and shows call controls such as answer, hold, transfer, and end, along with caller details and call logging.

A Softphone Connector in Salesforce Open CTI is the JavaScript layer that links the in-browser softphone widget displayed inside the Service Console to the telephony vendor underlying phone system. The Connector receives call events from the phone system (incoming call, hold, transfer, hangup), surfaces them in the softphone widget, and sends commands back (answer, end, mute, transfer) when the agent clicks the corresponding button. It is the bridge between the Salesforce UI and the vendor WebRTC, SIP, or proprietary signaling stack. The Softphone Connector is implemented by the phone vendor, not by Salesforce. Each vendor that integrates with Service Cloud through Open CTI (Cisco, Genesys, Avaya, Mitel, Five9, NICE, Aircall, Talkdesk, RingCentral) ships their own Connector as part of their AppExchange package. The Salesforce side calls the Open CTI JavaScript API; the Connector implements the vendor-specific business logic. From the agent perspective, the Connector is invisible; it just shows up as the softphone widget that works.

A Softphone CTI Adapter in Salesforce was a browser plugin (a desktop-installed binary) that connected a user deskphone or softphone software to the Salesforce UI. The Adapter delivered screen pops for incoming calls, click-to-dial outbound calling, and call logging directly into Salesforce records. It was the original mechanism for tying telephony into Salesforce, dating from the late 2000s. The Adapter has been retired in favor of Open CTI, a JavaScript-based API that lets phone vendors integrate with Salesforce through a Lightning component or a Visualforce page rather than a desktop binary. Open CTI runs entirely in the browser, supports modern phone systems (cloud-based softphones, WebRTC), and does not require user-level installation. Existing Softphone CTI Adapter deployments still work on some browsers but no new investment goes into the technology; every new phone integration should use Open CTI instead.

Software as a Service (SaaS) is the cloud delivery model where the vendor hosts the application, runs the infrastructure, and gives customers access through a web browser or API on a subscription basis. The customer does not install, patch, or operate any software; they sign up, log in, and use the application. Salesforce pioneered the model commercially in 1999 and remains the canonical example of an enterprise SaaS platform. SaaS sits in a three-tier cloud taxonomy alongside Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). SaaS provides a finished application (Salesforce Sales Cloud, Slack, Google Workspace). PaaS provides a runtime that customers build their own apps on top of (Salesforce Platform, Heroku, AWS Elastic Beanstalk). IaaS provides raw compute and storage (AWS EC2, Google Compute Engine). Salesforce uses all three tiers internally and resells multiple PaaS and SaaS products built on its own platform.

A Solution is a standard Salesforce object that stores a detailed description of a customer issue along with the resolution for that issue. Support agents attach solutions to cases so the same fix can be reused across many similar problems, and the records are searchable from the Solutions tab. Solutions are a legacy feature. They were the original knowledge layer in Salesforce Classic, and Salesforce now steers new work toward Salesforce Knowledge (Lightning Knowledge), which offers richer articles, versioning, and multi-channel publishing. Solutions still function in orgs that have the feature, but they are not the recommended path for new builds.

A Solution Manager in Salesforce is the user role in the legacy Solutions feature responsible for reviewing, editing, publishing, and curating Solutions before they become visible to support agents and customers. Solutions are the older predecessor to Salesforce Knowledge: short articles that document the resolution to a recurring customer issue, linked to Cases for reuse across the support team. The Solution Manager owns the quality of the Solutions catalog, deciding which solutions get published, which need rewriting, and which should be retired. The Solutions feature was the dominant Salesforce knowledge management tool through the early 2010s, before Salesforce Knowledge replaced it as the strategic direction. Solutions remain available in Salesforce Classic for backward compatibility, but the feature is deprecated and receives no new investment. Most orgs that still use Solutions are either small Service Cloud customers who never migrated or large orgs in mid-migration to Salesforce Knowledge. The Solution Manager role survives in legacy contexts but is rarely set up in new orgs.

SOQL (Salesforce Object Query Language) is the query language used to read records from the Salesforce database. It looks similar to SQL SELECT statements but is purpose-built for the multi-tenant Salesforce platform: queries always start from a single sObject, joins use relationship traversal syntax instead of JOIN clauses, and the language has no DML or DDL surface. SOQL queries return strongly-typed sObject results that Apex, Flow, and integration code consume directly. SOQL is the data-access foundation for everything custom in Salesforce. Apex classes embed inline SOQL: List<Account> accts = [SELECT Id, Name FROM Account WHERE Industry = ''Tech'']. REST and SOAP APIs accept SOQL strings in query endpoints. Reports and list views run SOQL under the hood. The query language supports relationship traversal up to five levels deep, aggregate functions (COUNT, SUM, AVG, MIN, MAX), grouping with GROUP BY, sub-selects, sub-queries via parent-to-child and child-to-parent traversal, and filtering with WHERE clauses that follow familiar SQL semantics. Mastery of SOQL is non-negotiable for any developer or architect serious about Salesforce.

SOSL (Salesforce Object Search Language) is the full-text search language for Salesforce records. Where SOQL queries one object and returns typed records, SOSL searches across multiple objects at once using a single text expression, returning matching records from each object as a separate list. It is the same engine that powers the global search bar at the top of the Salesforce UI, and it is the right tool whenever a user or integration needs to find records based on free-text matching rather than exact field filters. A SOSL statement looks like: FIND {Acme} IN ALL FIELDS RETURNING Account(Id, Name), Contact(Id, FirstName, LastName), Opportunity(Id, Name). The search expression goes inside curly braces and supports wildcards, phrase matching with quotes, boolean operators (AND, OR, NOT), and proximity operators. The RETURNING clause lists the objects to search and the fields to return for each. SOSL queries hit a precomputed text index, which makes them much faster than equivalent LIKE-based SOQL on text fields, but the index has its own freshness lag (typically a few seconds after a record is saved).

A Source Report in Salesforce is the existing tabular or summary report that feeds rows into a Reporting Snapshot. The snapshot engine runs the source report on a schedule, takes the resulting rows, and writes a copy of the data to a custom Salesforce object as a point-in-time snapshot. The source report is therefore the query layer in the snapshot architecture; the custom object is the storage layer where trend analysis runs against the historical copies. Source reports are the only data source Reporting Snapshots accept. They cannot run directly on SOQL, on external systems, or on an Apex method. Whatever data you want to capture historically must first be a runnable Salesforce report. This constraint shapes how teams design their snapshot programs: build the report you want to capture, lock its filters, then point a Reporting Snapshot at it.

Source-driven development is a Salesforce development approach where the version control system, not the org, holds the authoritative copy of your metadata. Your Apex, Lightning Web Components, objects, and configuration live as files in a Git repository, and orgs are treated as environments you build from that source. This model is the foundation of Salesforce DX. Developers retrieve metadata in source format, work locally, and push or deploy those files into scratch orgs or sandboxes for testing. Because the repository is the single source of truth, teams get history, code review, branching, and continuous integration on Salesforce work the same way other software teams have had them for years.

Special Terms in Salesforce CPQ are non-standard pricing, contractual clauses, or commercial exceptions attached to a quote, order, or contract that go beyond the standard agreement language. They cover everything from negotiated discount tiers, payment schedules, volume commitments, and renewal protections on the pricing side, to non-standard liability caps, indemnification language, and SLA commitments on the legal side. Special Terms exist because real B2B deals rarely fit a one-size-fits-all template, and they need to be tracked separately so finance, legal, and operations can honor them through the lifecycle of the customer relationship. The mechanism for storing Special Terms varies by org. Some use a Long Text field on the Quote or Opportunity. Some use a related Special Terms object with structured fields per clause. Sophisticated orgs use Salesforce CPQ Contract Terms with Clause Library integration, which gives finance a structured catalog of pre-approved clauses that sales can select from rather than free-text. The choice depends on how much governance the legal team wants and how often Special Terms are negotiated.

Stage Duration in Salesforce opportunity management is a calculated metric (sometimes a custom field, sometimes a real-time formula, sometimes a reporting summary) that captures how long an opportunity has been sitting in its current stage. The number is the difference between the current date and the date the opportunity last moved into its current stage, expressed in days, hours, or whichever time unit the business cares about. Stage Duration is one of the most operationally useful sales metrics because stalled deals (opportunities lingering in one stage well beyond the team's average) are leading indicators of pipeline rot and dropped follow-up. The metric is not a standard out-of-the-box field on the Opportunity object; it is implemented either through a custom field updated by automation (Apex trigger on Stage change, Flow that captures the stage entry date), through a real-time formula (DATEVALUE(NOW()) minus a captured stage-entry date), or through a custom report calculation. Each implementation has trade-offs in accuracy, performance, and reporting flexibility. The right pattern depends on how the org uses the metric and how often it is queried.

Stage History in Salesforce is the record of every Stage transition an Opportunity has gone through over its lifetime, stored in the OpportunityHistory standard object and surfaced through the Opportunity History report type. Each time a user changes an Opportunity's Stage, Amount, Probability, Close Date, or Forecast Category, Salesforce creates a new OpportunityHistory record capturing the new values, the previous Stage, the user who made the change, and the timestamp of the save. Stage History is the canonical source for time-in-stage analytics: how long deals sit at Discovery, which stages get skipped, how often deals move backward from Proposal to Discovery, what amount adjustments happen during negotiation. Sales operations teams build dashboards on the OpportunityHistory object to answer questions standard Opportunity reports cannot, because the live Opportunity record only shows the current state, not the history of how the deal got there.

A standard object is a pre-built database table that ships with every Salesforce org. Account, Contact, Lead, Opportunity, and Case are the best known examples. Each one arrives with predefined fields, relationships, and behaviors that model a common business concept, so you do not have to build the foundation of a CRM from scratch. You can extend a standard object with custom fields, validation rules, page layouts, and automation, but you cannot delete it or change its API name. That permanence is the point. Most of the platform, and most of the apps on AppExchange, assume these objects exist and are wired to behave a certain way.

Standard Price is the default unit price assigned to a Product in the Standard Price Book. Every active Product in a Salesforce org has exactly one Standard Price record per currency. The Standard Price is the platform's baseline price for the product, the value that custom Price Books can override but cannot bypass. The Standard Price Book is provisioned automatically when an org enables Products. It is not deleteable and acts as the parent for every Product's price record. A product that does not have a Standard Price cannot be added to any custom Price Book; Salesforce requires the Standard Price as a prerequisite. In multi-currency orgs, the Standard Price exists once per active currency, so a Product priced in USD and EUR has two Standard Price records under the Standard Price Book.

The Standard Price Book is the default Salesforce price book that ships pre-installed in every org and holds the canonical list price for every product. It is created automatically when Products are first enabled, cannot be deleted, and acts as the master source for the Standard Price field on every PricebookEntry. Custom price books (regional, channel, partner-discount) reference the standard price book for their list price baseline. Every product in Salesforce must have a Standard Price Book entry before it can be added to any custom price book. The standard entry establishes the product's canonical list price; custom price books then create their own PricebookEntry records with a different sales price for a specific channel, geography, or segment. Quotes, Opportunities, and CPQ all read from price books, and the standard book is the gravitational center of that pricing model.

State and Country/Territory Picklists is a Salesforce Setup feature that replaces the standard free-text Mailing State, Billing State, Shipping State, and corresponding Country fields on Account, Contact, Lead, Person Account, and User records with controlled picklists of ISO-standard values. The feature improves data quality by preventing the kind of free-text variation that turns "CA," "Calif," "California," and "calif." into four separate values that need cleanup before any geographic analysis works. Once enabled, every existing record in the org is scanned and the state and country values are mapped to their picklist equivalents wherever possible. Records with unmappable values (typos, abbreviations Salesforce does not recognize) are flagged for admin review. After cleanup, the picklist becomes the only way to enter state and country data, which permanently solves the data-quality problem at the source rather than requiring ongoing cleanup downstream.

A Statement in Salesforce Billing is a record that summarizes the financial activity on a billing account over a defined period: opening balance, new invoices issued, payments received, credits applied, and the closing balance the customer owes. It is the consolidated, customer-facing equivalent of a bank statement, and it covers every transaction posted to the account between the cycle start and cycle end dates. The Statement object is part of Salesforce Revenue Cloud Billing (and the legacy Salesforce Billing managed package that preceded it). Each Statement record links to a billing account, a list of Invoice Line items, a list of Payment records, and any Credit Memo records applied during the period. The platform supports both customer-facing PDF rendering through the Statement Template and internal reporting through standard report types over the Statement object.

A static resource is a file you upload to Salesforce so your code can reference it by name. Static resources hold the supporting assets that custom UI needs, such as JavaScript libraries, CSS stylesheets, images, fonts, and ZIP or JAR archives that bundle several related files together. Once uploaded, a static resource is served by Salesforce and pulled in from Visualforce pages, Aura components, and Lightning Web Components. Each resource can be up to 5 MB, and a single org can hold up to 250 MB of static resources in total.

Status in Salesforce is a field on a record that tracks where the record sits in its lifecycle. Status fields appear on most standard objects (Cases, Leads, Tasks, Solutions, Activities, Service Appointments) and on custom objects whenever an admin needs to track a record's progression through defined stages. The field is almost always a picklist with a controlled list of values, making the lifecycle predictable for reporting and automation downstream. Status is one of the most-referenced fields in Salesforce automation. Validation rules check status values to block edits in the wrong stage. Workflow rules, processes, and flows fire on status changes. Approval processes route records based on status. Service Cloud Entitlements use Case Status to drive milestone timers. Picklist Value Sets let admins share a status value list across multiple fields on different objects, keeping the lifecycle definitions consistent across the org's data model.

Stemming in Salesforce search is the automatic reduction of search terms to their root word form so that queries match across variants. A search for running matches records containing run, runs, runner, and ran. A search for invoices matches records containing invoice. The platform performs this reduction at both index time (when records are added or updated) and query time (when a user submits a search), so the algorithm sees the root form on both sides of the comparison. Stemming is one of several linguistic features the Salesforce search engine applies by default, alongside tokenization, lowercasing, stop-word removal, and synonym expansion. The combined effect is that users do not have to type the exact word form that appears in a record to get a match; the platform handles the linguistic variation for them. This is a strict requirement for good user experience in any system where humans search for records they did not write themselves.

Storage Usage is a Setup page in Salesforce that shows how much of your org's data storage and file storage is currently consumed. It reports your total allocation, the amount used, the percentage remaining, and a breakdown of which record types and which users account for the largest share. You reach it by entering Storage in the Quick Find box in Setup and selecting Storage Usage. The page is read-only. It does not change anything on its own. Its value is diagnostic: it tells an administrator where storage is going so they can decide what to archive, delete, or move before the org runs low on space.

A Subflow is a Flow Builder element that invokes another flow from inside the current flow. The called flow runs as a child in the same transaction. Input variables pass data into the called flow; output variables return data back. The parent flow waits for the subflow to finish, then continues from the element that follows. Subflows are the modularity primitive of declarative Salesforce automation. They let teams build flow logic the way developers build code: small reusable units called from larger orchestrating flows. The result is fewer copies of the same logic, faster maintenance when the logic changes, and clearer parent flows that read like a table of contents rather than a wall of elements.

A Subscriber in Salesforce is a customer org that has installed a managed package from the AppExchange or from a private package distribution. The Subscriber org receives updates and patches from the package publisher (the ISV) through the standard managed-package upgrade mechanism and retains its own data and configuration on top of the metadata the package provides. Salesforce tracks Subscribers on the publisher side through the License Management Application (LMA), where each Subscriber appears as a License record linked to a Package record and an Account record. The LMA gives the publisher visibility into who has installed the package, which version they are running, when the license expires, and whether the install is a sandbox or production. This is the foundation of every AppExchange business model.

A Subscriber Organization in Salesforce is a customer Salesforce org where a managed package from the AppExchange (or a private package distribution) has been installed. The Subscriber Org is the consumer side of the ISV-customer relationship; the Publisher Org (or License Management Org) is the producer side. The Subscriber Organization holds the installed package metadata, the Subscriber-created customizations on top of it, the data created by users in the org, and the License record that tracks the relationship back to the Publisher. The term is mostly used from the Publisher's perspective. When an ISV says we have 800 Subscribers, they mean 800 separate Salesforce orgs have installed their managed package. From the Subscriber Organization own perspective, the term rarely comes up; the org just sees an Installed Packages list and the package functionality. Understanding the distinction matters when troubleshooting, when planning upgrades, and when reading any Salesforce documentation aimed at ISVs.

A Success Plan is the tier of support, guidance, and resources that Salesforce attaches to your subscription to help you adopt its products and get value from them. Every Salesforce license comes with a plan, and you can upgrade to higher tiers for faster support and more hands-on help. The plans run from Standard (included with every license) up through Premier, Premier Plus, and Signature. Each step adds quicker response times, expert coaching, and proactive services. Success Plans sit alongside the product itself, so the same org can be served by very different levels of support depending on what the customer pays for.

A Suggested Article is a Salesforce Knowledge article that Service Cloud surfaces to an agent automatically while they work a case, instead of making the agent search for it. Salesforce compares the text on the case against the text in published Knowledge articles and shows the closest matches inside the Knowledge component on the case record. There are two engines behind the feature. The classic version uses keyword search and turns on automatically when you enable Lightning Knowledge. The smarter version, Einstein Article Recommendations (now also branded as Agentforce Article Recommendations for Cases), trains a model on which articles agents actually attached to similar cases in the past.

A Summary Field, more precisely called a Roll-Up Summary Field, is a read-only field on the master object in a master-detail relationship that automatically calculates an aggregate value from its related detail (child) records. It can count those child records or compute the sum, minimum, or maximum of a field on them, and it recalculates on its own whenever a child record is added, changed, or removed. Because the calculation runs on the platform, you get a live total on the parent record with no Apex, no Flow, and no scheduled job. The trade-off is the relationship requirement: a roll-up summary needs a true master-detail link, not a lookup, so the choice affects how you model the data.

A Summary Report is one of the four Salesforce report formats. It groups rows of data by the values in one or more fields, then calculates subtotals for each group and a grand total for the whole report. You pick the format in the report builder, alongside Tabular, Matrix, and Joined. The format answers questions that involve "how much" or "how many" broken down by a category. Think pipeline by stage, cases by status, or opportunity amount by owner. A Summary Report sits one step above a plain list, because it adds grouping and aggregation while still showing the underlying detail rows.

A Superbadge is a Trailhead credential that proves practical, scenario-based mastery of a Salesforce skill area, awarded only after the learner completes a multi-step hands-on challenge against a real Trailhead Playground. Each superbadge takes between 4 and 20 hours of focused work, requires specific prerequisite modules to be finished first, and validates that the learner can apply the concepts under realistic business pressure rather than just recall theory. Superbadges occupy the top tier of the Trailhead reward hierarchy, above the trail badges earned by completing standard modules. They are checked automatically against the playground org through a validation engine, which means there are no questions to game; either the learner built the configuration correctly or the badge does not appear. Salesforce also recognizes specific superbadge combinations as Superbadge Super Sets, which often map directly to certification exam topics and count toward maintenance credit on existing certifications.

Supervisor Disconnect is the contact center action in Salesforce Service Cloud Voice (and several Omni-Channel voice integrations) where a supervisor monitoring an agent's live call removes themselves from the line without ending the call between the agent and the customer. The supervisor's audio leg is closed and the call continues normally with the remaining parties; the action is logged on the call record and the supervisor's monitoring session is timestamped as ended. The disconnect is technically a one-party drop, not a call termination. It comes up most often in monitoring scenarios (silent monitor, whisper coach, barge-in) where the supervisor joined to coach or observe. When the supervisor disconnects, any whisper-coaching audio they sent to the agent stops, the customer never hears the supervisor leaving, and the agent regains full control of the call. Reporting captures the supervisor's start and end timestamps so quality teams can measure coaching coverage.

A Survey in Salesforce is a standard object that represents a single survey definition: its name, status, default language, and the metadata that drives the survey-taking experience. It is the central record in Salesforce Surveys, the click-based feedback tool included with the platform, and in the paid Salesforce Feedback Management add-on. Each Survey record is the parent of a related data model that captures everything from questions to individual answers. In the API the object is simply named Survey. One Survey owns its versions, pages, questions, and choices, while related objects track who was invited, who responded, and what each person answered. Because every channel writes back to the same records, an admin can analyze email, web, QR-code, and Flow-triggered responses together. Surveys are available in Enterprise, Unlimited, and Developer editions.

A Survey Question in Salesforce (SurveyQuestion in the API) is a standard object representing a single prompt within a Survey - the actual question that respondents answer. Each Survey Question record holds a parent SurveyId (or SurveyVersionId), a parent Survey Page, a Name (the question text), a QuestionType (Single Select, Multi Select, Free Text, Long Text, Numeric, Rating, Slider, NPS, Date, Time, File Upload, Image, Ranking), an order/sequence within its page, an IsRequired flag, and validation settings. For choice-based questions, related SurveyQuestionChoice records hold the available answer options; for matrix and ranking question types, additional metadata structures support sub-questions and order. The Survey Question is where the substance of every survey lives - choosing the right question types, ordering, and required flags directly determines completion rates and data quality. Survey Questions can be referenced across multiple Survey Versions, enabling year-over-year comparison of the same metric (a CSAT question on the 2025 survey can be the same Survey Question on the 2026 survey, supporting longitudinal trend analysis).

A Survey Question Response in Salesforce, called SurveyQuestionResponse in the API, is a standard object that records one respondent's answer to one question on a survey. It is the row-level fact behind every Salesforce Surveys analysis. When a person finishes a five-question survey, the platform writes one SurveyResponse record (the whole submission) and five SurveyQuestionResponse records (one answer each). Each record links up to its parent SurveyResponse, to the SurveyQuestion it answers, and back to the Survey and Survey Version. The answer itself lands in a field that depends on the question type. A choice picks up a ChoiceId, free text fills a text field, a rating or NPS score fills a numeric field, and a date question fills a date field. Because the answer can sit in different places, reading this object well means knowing the question type first.

A Survey Response is the standard Salesforce object (API name SurveyResponse) that records one participant's submission to a Salesforce survey. It captures the status of the response, where the participant was when they answered, and when they finished, and it links back to the survey, the survey version, and the invitation that was sent. The Survey Response is the parent record for a set of Survey Question Response records, which hold the actual answer to each question. Because every submission becomes a real CRM record, you can report on it, automate from it, and analyze it next to the contacts, cases, and accounts it relates to.

A sync in Salesforce is a process that keeps records consistent between Salesforce and another system, so a change made in one place shows up in the other. The "other system" might be a Microsoft or Google mailbox, a Data Cloud activation target, a marketing platform, or a custom backend reached through an API. Sync is an umbrella term, not a single feature. Different jobs call for different mechanisms. Email and calendar run on Einstein Activity Capture, which replaced the retired Lightning Sync. Segment data flows out through Data Cloud activations. Record changes stream to outside systems through Change Data Capture. Each pattern has its own direction, timing, and limits.

Syndication Feeds in Salesforce are Atom or RSS web feeds that publish record data from a Salesforce Site or Experience Cloud page so that external applications, blog readers, and news aggregators can subscribe to updates without making direct API calls into the org. The feature wraps a SOQL query in a feed channel definition and exposes the result at a public URL with the Salesforce-managed RSS or Atom XML structure. Syndication Feeds were a heavier-used feature in the late 2000s and early 2010s when RSS was a primary content-distribution channel. In 2026 they remain in the platform but are a low-investment area. Most modern integrations replace Syndication Feeds with REST API endpoints, Platform Events, or Salesforce Connect external objects, since those technologies offer authentication, finer access control, and richer payloads. Existing feeds continue to serve and rarely need attention; new use cases rarely justify them.

System Administrator is the default Salesforce profile that grants the highest level of access to an org: every Setup page, every record across every object, every administrative permission, and the ability to modify metadata, write Apex, manage users, and change configuration. The profile ships with every Salesforce edition and is the starting point for the first user provisioned on a new org. From there, the System Administrator is responsible for managing every other user, setting up the data model, building automation, configuring security, and operating the platform on behalf of the business. The profile carries significant blast radius: a System Administrator can delete every record in the org, modify or remove every metadata component, change every user permissions, and export data wholesale. Mature orgs treat System Administrator access as a privileged credential, granted sparingly, audited regularly, and protected through multi-factor authentication and login IP restrictions. The role is critical but the privilege level should not be the default for everyone on the admin team; permission sets and narrower profiles often suffice.

The System Log is the developer-facing debug log inside the Salesforce Developer Console that captures everything happening on the platform during a single Apex execution, from SOQL queries to DML operations to flow steps. Each entry is timestamped and tagged with the type of activity (USER_DEBUG, SOQL_EXECUTE, DML_BEGIN, METHOD_ENTRY, LIMIT_USAGE_FOR_NS), giving developers a turn-by-turn replay of what the platform did and how much of the governor budget each step consumed. System Log refers specifically to the live log view inside the Developer Console. The same captured records appear as ApexLog rows in the data model and can be downloaded, queried, or exported through the Tooling API. Most developers use the System Log tab interactively (open the console, run Anonymous Apex, watch the log appear in real time), while ops teams pull the ApexLog records into external observability tools when they need to investigate production issues offline.

A System Overview is a Setup page in Salesforce that gives administrators a single, high-level summary of how much of the org's resources are in use compared to the limits the edition allows. It groups usage into sections such as Schema, API Usage, Business Logic, User Interface, Most Used Licenses, and Portal Roles, so you can spot a resource filling up before it becomes a problem. The page reads from the same allocations that govern the platform, then shows each metric as a current count next to its ceiling. You reach it from Setup by typing System Overview into Quick Find. It is available in both Lightning Experience and Salesforce Classic, in every edition except Personal Edition.

System Testing in the Salesforce development lifecycle is end-to-end validation of a complete Salesforce implementation against business requirements before it is promoted to production. The work covers every layer of the org: standard and custom configuration, Apex triggers, Lightning Web Components, Flows, declarative automation, integrations with external systems, security and sharing, and the end-user workflows that tie them together. The goal is to catch defects that escape unit and component testing and only surface when the pieces interact. System Testing sits between Unit Testing (developer-owned, narrow scope) and User Acceptance Testing (business-owned, validation of fit). It is usually run in a Full Sandbox or Partial Copy Sandbox by a dedicated QA team, with a documented test plan that mirrors the production user journeys. Many Salesforce orgs underestimate the effort and ship integration bugs to UAT or production as a result.