Salesforce terms starting with S

Software as a Service - the delivery model Salesforce pioneered where CRM software is hosted in the cloud and accessed via web browser, with no local installation required, automatic updates, and subscription-based pricing.

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.

Sales Cloud Everywhere is a Setup feature that extends Sales Cloud functionality beyond the Salesforce interface, allowing sales reps to access CRM data, log activities, and manage their pipeline from any web page they visit, including prospect websites, LinkedIn, and Gmail, through a browser extension.

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.

In Salesforce price books, the specific price assigned to a product within a custom price book, which may differ from the list price in the standard price book to reflect discounts, region-specific, or customer-specific pricing.

Salesforce is a cloud-based customer relationship management (CRM) platform that enables companies to manage relationships with customers and prospects across sales, service, marketing, commerce, and other business functions. Founded in 1999, it pioneered the Software-as-a-Service (SaaS) model with a multi-tenant architecture, and has since expanded into a comprehensive ecosystem of cloud products, development tools, and an extensive partner marketplace (AppExchange).

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 a compliance solution for financial services organizations that enables identity verification, sanctions screening, and adverse media checks for applicants and customers directly within Salesforce. It integrates with third-party AML compliance platforms to help organizations detect, prevent, and report money laundering activities in accordance with regulatory requirements.

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.

The version number of the Salesforce API that a piece of metadata, Apex code, or integration is configured to use, determining which platform features and behaviors are available (e.g., API version 59.0).

The Salesforce Architect Certification track is Salesforce's top-tier credential family for architects who design and lead enterprise Salesforce implementations. It culminates in the Certified Technical Architect (CTA), earned via a review board defense rather than a written exam. The path builds through Application Architect and System Architect - each requiring five domain architect certifications (e.g., Data Architect, Sharing and Visibility Architect, Integration Architect, Identity and Access Management Architect, Development Lifecycle and Deployment Architect) - before candidates can register for the CTA board.

A Salesforce Certificate and Key Pair is a cryptographic credential managed in Salesforce Setup under Certificate and Key Management, used to authenticate API integrations, sign SAML assertions for single sign-on, and establish secure TLS/SSL connections with external systems. Salesforce generates the certificate and private key pair, and administrators can export the certificate to share with external service providers.

Salesforce Certifications are globally recognized professional credentials offered by Salesforce that validate expertise in specific Salesforce domains such as Administration, Development, Architecture, Marketing Cloud, and AI. Professionals earn certifications by passing proctored exams, and they span multiple levels from Associate and Administrator to Architect credentials, providing a structured career advancement path.

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 user interface designed for high-volume, fast-paced work environments (like support centers), featuring a tab-based workspace, split views, utility bar, and keyboard shortcuts for efficient multi-record navigation.

The Salesforce Console Integration Toolkit is a browser-based JavaScript API that provides programmatic access to the Salesforce Service Cloud Console in Salesforce Classic, enabling developers to manipulate tabs, control console UI behavior, and execute asynchronous calls. It is used through custom buttons, Visualforce pages, and JavaScript code to extend and customize the console experience for service agents.

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 a feature that integrates Salesforce with Computer Telephony Integration (CTI) systems, enabling agents to make and receive calls via a softphone embedded in Salesforce while accessing real-time customer data. It uses call center definition files (XML) to configure connections with various CTI vendors and supports automatic call logging, screen pops, and click-to-dial functionality.

Salesforce CRM Content is an enterprise content management feature that helps organizations organize, share, and manage business documents and files through searchable content libraries. It supports all file types and enables powerful searches across document content, metadata, titles, descriptions, tags, and author names, providing a more structured alternative to attaching files directly to individual records.

Salesforce Developers (developer.salesforce.com) is the official developer community and portal that provides comprehensive documentation, APIs, tools, sample code, and forums for building applications and integrations on the Salesforce platform. It serves as the central hub for developer resources including Apex, Lightning Web Components, REST/SOAP APIs, and Salesforce CLI documentation.

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 extension pack that provides a full-featured development environment for building on the Salesforce platform within VS Code. It includes tools for Apex development with IntelliSense, Lightning Web Component authoring, SOQL query building, debugging with replay, and integration with Salesforce CLI for deploying to orgs, scratch orgs, and sandboxes.

Salesforce Feedback Management is a solution for collecting, analyzing, and acting on customer feedback across multiple channels, extending the native Salesforce Surveys feature with advanced capabilities. It enables teams to gather CSAT and NPS survey data, map responses directly to Salesforce records, trigger automated follow-up actions, and create personalized customer experiences based on feedback insights.

Salesforce Flow Orchestration enables administrators to create multi-user, multi-step automated processes that can pause and wait for approvals, external data, or assigned work before continuing. It organizes flows into sequential or parallel steps grouped by stages, providing visibility into long-running business processes. As of February 2026, Flow Orchestration became a standard Flow type available without requiring an add-on license.

Salesforce for Nonprofits (formerly known as the Nonprofit Success Pack/NPSP, now Nonprofit Cloud) is a suite of purpose-built applications designed for nonprofit organizations to manage fundraising, donor relationships, program delivery, grantmaking, and volunteer coordination. It provides nonprofit-specific data models for constituent tracking, donation management, outcome measurement, and case management.

Salesforce Foundations is a Setup feature that provides existing Salesforce customers with access to a curated set of capabilities from Sales, Service, Marketing, Commerce, and Data Cloud at no additional cost. It extends the core platform with cross-cloud features to help organizations unify their customer experience.

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.

Salesforce Inbox was an email productivity add-on for Sales Cloud that integrated with Gmail and Outlook to help sales reps automatically log emails, track email opens and link clicks, schedule meetings, and create Salesforce records directly from their inbox. It has been retired, with its core capabilities now incorporated into Sales Cloud's standard email integration features and Einstein Activity Capture.

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 brings geographic visualization and territory management directly into Salesforce. It helps sales and field service teams visualize customer data on interactive maps, design optimized routes, plan territories based on geography and revenue potential, and perform proximity searches to identify nearby accounts or leads.

Salesforce Maps Layers are visual overlays within Salesforce Maps that display collections of Salesforce records (such as accounts, leads, or opportunities) as color-coded location pins on an interactive map. They enable users to visualize geographic patterns in their CRM data, plan routes, and derive location-based insights for territory management and field operations.

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 manages the complete order lifecycle from capture through fulfillment, returns, and refunds, built on an event-driven architecture. It connects commerce, service, and logistics systems with pre-built integrations to Commerce Cloud and native support for Sales and Service Clouds, providing a unified view of order status across all channels.

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 a system-generated unique identifier assigned to every record in a Salesforce org. It is available in both a 15-character case-sensitive format and an 18-character case-insensitive format (which includes a 3-character checksum suffix). Record IDs are immutable and serve as the primary key for accessing, querying, and relating records throughout the platform.

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 approach that enables developers to build loosely coupled, discrete services on the Salesforce platform using Apex for integration with external web services, internal systems, and composite services. It supports building scalable on-demand applications through API-driven integrations and service-based design patterns.

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 feature that enables organizations to create, distribute, and analyze surveys to gather customer and employee feedback directly within Salesforce. Survey responses are automatically linked to customer records, eliminating manual data entry and enabling automated follow-up actions based on feedback scores like CSAT and NPS.

Salesforce Voice, also known as Service Cloud Voice, is a native telephony solution that integrates phone calls directly into the Salesforce agent workspace alongside chat, email, and messaging channels. It provides AI-powered real-time call transcription, supervisor monitoring, and unified omnichannel visibility, enabling agents to handle calls without leaving the Service Console.

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.

Sandbox Templates define which object data is copied from production when creating or refreshing a Partial Copy Sandbox. Administrators select up to 10,000 records per object and choose specific objects to include, allowing teams to create focused test datasets that are smaller than a full copy but still representative of real data patterns.

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 Salesforce feature available in reports, dashboards, list views, and other components that creates a copy of the current item with a new name, preserving the original while allowing modifications to the duplicate.

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 a time-based automated action that executes at a specified interval before or after a trigger event, such as a record creation date or a field value change. Used within Flow Builder and previously in Process Builder and Workflow Rules, scheduled actions enable administrators to automate follow-ups, reminders, escalations, and other time-sensitive business processes without writing code.

Scheduled Jobs is a Setup page that displays all jobs scheduled to run at specific times, including scheduled Apex classes, scheduled Flows, scheduled reports, scheduled dashboards, and scheduled analytics. Administrators can view the schedule, next execution time, and status of each job.

In Salesforce Field Service, a configuration that defines rules for the scheduling optimizer, specifying priorities like minimizing travel time, respecting skill requirements, and balancing workload when assigning work orders to service resources.

Schema Builder is a Setup tool that provides a visual, drag-and-drop interface for viewing and modifying the data model of a Salesforce org. It displays objects, fields, and relationships as an interactive diagram, allowing administrators to create new objects and fields and define relationships without navigating between multiple Setup pages.

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.

In Salesforce CTI and Service Cloud Voice, the automatic display of a record or page on an agent's screen when an incoming call is received, showing caller information from matching Salesforce records for faster service.

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.

In Salesforce SOQL, a query pattern that uses a subquery in the WHERE clause to filter parent records based on criteria in a child object, such as selecting accounts where related opportunities meet certain conditions.

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.

In Salesforce Field Service, an object that defines a type of work your company provides (like installation, repair, or maintenance), linked to service territories, skills, and work types for scheduling purposes.

A Salesforce Field Service object that represents a scheduled appointment for field work at a specific location and time, linked to a work order, service resource, and service territory for dispatch and tracking.

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 is a Setup area providing pre-built report templates and dashboards for monitoring customer service metrics. These reports cover Case volume, resolution times, agent performance, SLA compliance, customer satisfaction scores, and other key service KPIs.

A Service Cloud feature that integrates telephony directly into Salesforce, providing agents with a built-in softphone, real-time transcription, AI-powered recommendations, and call recording within the Service Console.

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 Salesforce Service Cloud object that represents a formal support agreement between your organization and a customer, defining the terms, coverage, and entitlements for service over a specified period.

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 Salesforce Field Service object that represents an individual worker (technician, agent, or contractor) who can be assigned to service appointments, with attributes including skills, location, capacity, and availability.

Service Setup Assistant is a guided Setup wizard that walks administrators through the essential steps of configuring Service Cloud for their organization. It provides a checklist-based approach to enabling features like Case Management, the Service Console, Knowledge, Omni-Channel routing, and customer self-service portals.

A Salesforce Field Service object that defines a geographic region where services are delivered, containing service resources, operating hours, and work rules that govern how work is scheduled and dispatched in that area.

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 where administrators view and manage all active user sessions in the org. It provides details on each session including the user, login time, IP address, session type, and the ability to revoke individual sessions for security purposes.

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.

Settings in Salesforce Setup refers to the broad collection of configuration pages organized under the Setup menu where administrators control how the platform and its features behave for the entire org. These are grouped into categories such as Company Settings (company info, fiscal year, business hours), Security Settings (password policies, session settings, field-level security), User Management Settings, Feature Settings (Sales, Service, Marketing feature controls), Platform Settings (custom code, API, environments), and many more. Each individual settings page controls specific aspects of the platform's behavior.

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 that provides a centralized overview of the org's health, recent setup changes, and recommended actions. It includes links to the most commonly used setup pages, the setup search bar, and widgets showing adoption metrics, feature recommendations, and release updates.

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 Salesforce feature that allows a single event or task to be related to multiple contacts simultaneously (up to 50), creating a shared activity record rather than requiring separate activities for each contact.

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 where administrators define the organization-wide default (OWD) access levels for each object and create sharing rules to extend access beyond the defaults. OWD settings control the baseline visibility (Private, Public Read Only, Public Read/Write) for records across the org.

In Chatter, Sharing (as an action on a feed post) lets a user re-surface an existing post to another audience - a Chatter group, a record's feed, or their own profile feed - so people outside the original post's scope see it. Unlike a Comment (which stays on the original post) or a Like (which is a reaction), Sharing propagates the post to a new feed context while preserving a reference back to the original.

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.

In Salesforce Workforce Engagement (Shift Management), a reusable template that defines a recurring pattern of shifts over a set period, automating the creation of consistent agent schedules week over week.

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 in Salesforce Workforce Engagement (and Field Service) is a reusable definition of shift details - start/end times, meal breaks, job profile, territory, skills needed - that admins apply when generating recurring shifts. Rather than recreating the same shift structure every week, the template captures the shape once and the scheduling engine stamps actual Shift records from it as needed. Templates pair with Shift Patterns (which define the recurrence cadence) to drive automated scheduling.

A toggle option in Salesforce report views that shows or hides the individual record rows behind summary or matrix report groupings, letting users switch between seeing aggregated totals and detailed record data.

In Salesforce Classic, the left panel of the interface that displays recent items, shortcut links, messages, custom components, and quick-create options, providing navigation and contextual information alongside the main content area.

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 (Force.com Sites) is a feature that allows you to create public-facing web pages hosted on the Salesforce platform, accessible without login, that can display Salesforce data through Visualforce pages.

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 minimal HTML/Visualforce template structure that provides the basic page framework (such as HTML doctype, head, and body tags) without predefined content or styling. It is used as a starting point when developers want full control over the page layout and markup rather than using a standard Salesforce template with built-in headers and sidebars.

A Skill in Salesforce is a standard object that represents a specific competency, certification, or capability that can be assigned to a Service Resource (a field-service technician) or used as a routing criterion for Omni-Channel work distribution. Each Skill record holds a MasterLabel, an optional DeveloperName, and a Description; the actual mapping of skills to resources lives on the ServiceResourceSkill junction object, which captures effective start and end dates and a SkillLevel rating. Skills are the foundation of skills-based work assignment in two distinct Salesforce features: Field Service uses Skills to ensure service appointments are dispatched only to technicians qualified to perform the work (HVAC certification, language fluency, security clearance), and Omni-Channel uses Skills (modeled in a related but separate framework) to route Cases, Leads, or Chats to agents whose skill profiles best match the work requirements. The same vocabulary of skills can drive both systems, giving service organizations a unified competency model across digital channels and on-site work.

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.

In Salesforce Marketing Cloud and Email Studio, a reusable block of content (text, HTML, images) that can be inserted across multiple email templates and content areas, enabling consistent messaging without duplication.

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 (Salesforce Object) is the Apex representation of a Salesforce standard or custom object. In Apex code, sObject is the generic data type that can represent any record, and specific sObjects like Account, Contact, or MyCustomObject__c are strongly-typed subtypes. Developers use sObjects to create, read, update, and delete records programmatically.

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.

In Salesforce CTI and Service Cloud Voice, a software-based phone interface displayed in the Salesforce utility bar that allows agents to make, receive, and manage calls without a physical phone, featuring click-to-dial and call controls.

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 Salesforce Knowledge-predecessor object (primarily used in Classic) that stores answers to common customer questions, searchable by agents and customers, largely replaced by Salesforce Knowledge articles in Lightning.

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.

A Salesforce DX development methodology where the source of truth for metadata lives in a version control system (like Git) rather than in the org, enabling modern DevOps practices with scratch orgs and CI/CD pipelines.

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 comes included with every Salesforce org. Standard Objects like Account, Contact, Opportunity, Case, and Lead provide the foundational data model for CRM processes. They come with predefined fields, relationships, and behaviors, though administrators can customize them with additional fields and configurations.

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.

Static Resources is a Setup page for managing files uploaded to Salesforce that can be referenced in Visualforce pages, Lightning components, and other customizations. Static resources can include JavaScript libraries, CSS stylesheets, images, and ZIP archives containing multiple files, with a maximum size of 5 MB per resource.

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 that displays the org's data storage and file storage consumption, broken down by object. It shows how much of the total allocation is used, which objects consume the most storage, and helps administrators identify opportunities to archive or delete data to stay within limits.

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.

In Salesforce Customer Success or Industries, a structured plan that outlines goals, milestones, and activities to guide a customer through adoption, implementation, or optimization of Salesforce products.

In Salesforce Service Cloud, a Knowledge article that is automatically recommended to an agent based on the case's subject, description, or other field values, surfaced through Einstein Article Recommendations or suggested articles settings.

A Summary Field, also known as a Roll-Up Summary Field, is a read-only field on a master object in a master-detail relationship that automatically calculates aggregate values from related child records. It supports functions including COUNT, SUM, MIN, and MAX, and can include filter criteria to limit which child records are included in the calculation.

A Salesforce report format that groups records by row values and includes summary fields (sum, average, min, max) at each grouping level, useful for totaling data by categories like region or stage.

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 (Survey in the API) is a standard object in Salesforce Surveys (and the more advanced Salesforce Feedback Management product) that represents a single survey definition - its name, current status, default language, and the metadata that drives the survey-taking experience. Each Survey is the parent of a rich data model: Survey Versions track changes over time, Survey Pages organize the survey into sections, Survey Questions define individual prompts (multiple choice, single select, free text, NPS, rating, ranking, slider, file upload), Survey Invitations track who was asked to take the survey through which channel, and Survey Question Responses capture each individual answer when a respondent completes the survey. Surveys can be sent through email, embedded in Experience Cloud sites, triggered automatically by Flow when a Case is closed (CSAT) or an Opportunity is won, or distributed through public links - with all responses centralized in the same data model regardless of distribution channel for unified analysis.

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 (SurveyQuestionResponse in the API) is a standard object that captures a single respondent's answer to a single Survey Question. Each Survey Question Response record holds a parent SurveyResponseId (the completion record for that respondent's full survey submission), a SurveyQuestionId, a ChoiceId for choice-based questions (or null for free-text and other types), the literal text or numeric value the respondent provided, a CompletionDate, and references back to the parent Survey, Survey Version, and Survey Subject. Survey Question Responses are the row-level data that populate every Salesforce Surveys analysis - when a respondent completes a five-question survey, Salesforce creates one Survey Response record plus five Survey Question Response records. Aggregating Survey Question Responses by Survey Question reveals the distribution of answers (50% chose Option A, 30% Option B, 20% Option C); aggregating across Survey Versions reveals trends over time. Survey Question Responses also link to the parent record (Case, Account, Contact) through Survey Subject, enabling cross-object reporting like 'average CSAT for Cases owned by each agent in the past quarter'.

A Salesforce object that stores an individual respondent's answers to a Salesforce Survey, including their responses to each question, submission timestamp, and any associated record like a case or contact.

In Salesforce, Sync is the process of keeping records consistent between Salesforce and external systems - email, calendars, ERPs, marketing platforms - so a change in one place is reflected in the other. Modern Salesforce syncs run on Einstein Activity Capture (for email and calendar, replacing the retired Lightning Sync), Data Cloud Activations (for unified-profile data), Marketing Cloud Connect (for campaign sync), and custom integrations via the Platform Event, Change Data Capture, and REST/Bulk APIs.

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.

System Overview is a Setup page that provides a high-level summary of the org's usage against key platform limits, including API calls, storage, custom objects, rules, flows, and other configurable components. It helps administrators monitor the org's capacity and avoid hitting governor limits.

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.