Salesforce terms starting with E

Education Cloud is Salesforce's industry-specific solution for higher education, K-12 schools, and continuing education. It provides a data model and tooling for managing the student lifecycle from recruitment through enrollment, retention, and alumni engagement. Education Cloud sits on top of the core Salesforce platform with vertical-specific objects (Student, Education Program, Course Connection, Affiliation), pre-built apps (Student Recruitment, Student Success, Advancement), and integrations with student information systems (SIS), learning management systems (LMS), and CRM. The product has two generations. The first, built around the Education Data Architecture (EDA) managed package, mirrored NPSP's approach: extend standard objects through a community-maintained package. The second, the rebuilt Education Cloud launched in 2023, uses dedicated objects similar to how Nonprofit Cloud replaces NPSP's Opportunity-as-Donation pattern with Gift Transaction. New deployments default to the rebuilt version; existing EDA orgs continue to run but face an eventual migration.

Education Data Architecture (EDA) is the open-source managed package that extends standard Salesforce objects to support higher education and K-12 use cases. Maintained by Salesforce.org and the higher-ed community, EDA adds the data model, page layouts, validation rules, and triggers that institutions need to track students, courses, programs, affiliations, and relationships. Until 2023, EDA was the foundation for Salesforce Education Cloud; the rebuilt Education Cloud now uses dedicated platform objects instead, but EDA remains widely deployed and continues to receive updates. EDA installs into a standard Salesforce org and adds custom objects (Course, Course Offering, Course Connection, Education History, Affiliation, Behavior Involvement, Term, Plan Requirement, and others), along with extensions to Contact, Account, and Opportunity. The package is free, version-controlled on GitHub, and follows a release cadence aligned with the Salesforce platform releases (typically three major releases per year). Institutions either install directly from the AppExchange or pull from the GitHub repo for self-managed deployments.

Einstein is Salesforce's umbrella brand for artificial intelligence features and products built into the platform. Launched in 2016, Einstein has evolved from a set of predictive ML features (Lead Scoring, Opportunity Scoring) into a comprehensive AI platform covering predictive analytics, generative AI, large language model orchestration, and autonomous agents. Today, Einstein encompasses Sales Cloud Einstein, Service Cloud Einstein, Marketing Cloud Einstein, Einstein Discovery, Einstein for Developers, Agentforce, Prompt Builder, Model Builder, and several dozen feature-specific AI capabilities. Each Einstein feature integrates with the relevant Salesforce cloud: Sales Cloud Einstein adds Lead Scoring, Opportunity Scoring, Conversation Insights, and Activity Capture to the sales workflow. Service Cloud Einstein adds Case Classification, Article Recommendations, Bots, and Reply Recommendations. Einstein Discovery brings ML-based predictive modeling for any object. Agentforce represents the newest layer: autonomous AI agents that take action across the platform. Einstein is the marketing name; the underlying technology stack includes Salesforce's hosted LLMs, partner-provided models (OpenAI, Anthropic, Google, Cohere via Einstein Trust Layer), and the Salesforce-specific orchestration tooling.

Einstein Activity Capture (EAC) is a Sales Cloud feature that automatically syncs email and calendar activity from connected mailboxes (Microsoft 365, Google Workspace) into Salesforce and matches each activity to the relevant Account, Contact, Opportunity, or Lead. Reps connect their email and calendar once; from then on, sent emails, received emails, accepted meetings, and meeting invitations flow into Salesforce without manual logging. The matching engine uses email addresses, domains, and meeting attendee lists to associate each activity with the right CRM records. EAC is one of the highest-ROI quiet features in Sales Cloud because it eliminates the manual activity logging that reps universally avoid. Before EAC, rep activity in CRM reflected what reps remembered to log, which was a fraction of reality. With EAC, the activity dataset reflects what actually happened, which is what every downstream Einstein feature (Activity Capture-derived Deal Insights, Relationship Insights, Conversation Insights pairings) needs to work. EAC is also where the most common adoption complaints live, usually around what is shared with whom.

Einstein Article Recommendations is the Service Cloud feature that suggests Salesforce Knowledge articles to a support agent based on the open case. When an agent loads a case, Einstein analyzes the case description, subject, and any prior comments, scores every accessible Knowledge article for relevance, and surfaces the top matches in a sidebar component. The agent can attach the article to the case or insert its content into a reply with one click, cutting the search time that traditionally ate the first minute of every case. The feature ships with Service Cloud editions that include Einstein, runs on a Salesforce-managed model that needs no per-org training, and uses the org's actual Knowledge base as the candidate pool. Its impact is bounded by Knowledge hygiene; a well-curated Knowledge base with good titles and current content makes the recommendations sharp, while a stale base with vague titles makes them noisy. The most common rollout failure is not the feature but the unwillingness to invest in Knowledge cleanup before turning it on.

Einstein Autofill Setup is the Salesforce Setup page where administrators configure Einstein's ability to suggest or automatically populate field values on records based on machine learning predictions. The feature reads patterns from existing records in the org (an Account's Industry usually tracks with its Company Size and Website), trains a model on the available signal, and offers Einstein-suggested values inline on record-create and record-edit pages. The autofill itself can run in two modes: suggested (the field shows a pre-filled value the user can accept, edit, or clear) or applied (the value is written automatically when the record saves). Most teams start in suggested mode to validate accuracy before letting the platform write fields without confirmation. Autofill is one of several Einstein features that compete for the same problem of cutting data-entry overhead; Einstein Case Wrap-Up, Einstein Activity Capture, and the newer Setup with Agentforce all reduce manual typing through different mechanisms.

Einstein Automate is Salesforce's branded automation portfolio: a collection of tools rather than a single product. It combines Flow (the platform's declarative automation engine), MuleSoft Composer (no-code integration), RPA via MuleSoft RPA (automating legacy UI interactions), AI Builder (custom AI-driven decisions), Einstein Bots (conversational automation), and various integrations into Salesforce processes. Launched in 2020 and refined since, Einstein Automate is the marketing umbrella that frames Salesforce's automation story for low-code and AI-augmented workflows. In practice, Einstein Automate is rarely something you turn on as a single feature. It is the set of automation capabilities Salesforce ships across the platform, packaged under one name for sales and marketing. When you build a Flow that calls an external API via MuleSoft Composer, then triggers an Einstein Bot for customer chat, you are using Einstein Automate even if no single product label appears in the UI. The brand matters mainly for executive discussions, AppExchange positioning, and Salesforce-sales conversations.

Einstein Bot is Salesforce's chatbot product for automating Tier 1 customer interactions on chat, messaging, and voice channels. It uses natural-language understanding to interpret user input, routes the conversation through dialog steps, calls Apex or Flow actions when needed, and hands off to a human agent when the bot reaches its limits. Einstein Bots predate Agentforce and remain in production at thousands of orgs for high-volume routine customer interactions like order status, password reset, and FAQ deflection. A bot has a definition (the dialog tree), intents (categories of user input), entities (extractable data like dates, amounts, IDs), variables (state held during the conversation), and actions (Apex methods or Flows the bot invokes). Bots run on Live Chat (web chat widgets), Messaging channels (WhatsApp, SMS, Apple Messages for Business, Facebook Messenger), and Service Cloud Voice with speech-to-text. Salesforce is steering new bot work toward Agentforce, but Einstein Bots remain supported and continue receiving incremental improvements.

Einstein Case Classification is the Service Cloud feature that auto-predicts and populates picklist field values on incoming Cases. Admins pick which fields to classify (Type, Reason, Priority, Sub-Type, custom picklists), Salesforce trains a per-field model on the org's historical Cases where the field was set, and the model fills the field on new Cases at create-time. Downstream routing, assignment rules, and reports run against the predicted values without waiting for an agent to read and categorize the case manually. The feature is one of the longest-running Einstein for Service capabilities and pays back fastest on orgs with high case volume and consistent historical labels. It runs as a Salesforce-managed model with no per-org tuning required beyond field selection. The biggest source of disappointment is label inconsistency in the training data; teams that audit and standardize historical case classifications before turning the feature on get accurate predictions, while teams that skip the audit get the same inconsistency baked into every new case.

Einstein Case Routing is a Service Cloud feature that uses a trained classification model to predict the right queue, agent skill, or owner for an incoming case based on the case content and historical routing decisions. The model trains on the case Subject and Description text plus selected related fields, learns the patterns that drove past routing assignments, and applies those patterns to new cases at creation or update time. The prediction lands on the case (typically as a recommended queue or skill) and feeds into Omni-Channel skills-based routing or a flow that performs the actual assignment. Einstein Case Routing is one of a small family of Service Cloud Einstein features that automate the cognitive work of case intake. It pairs naturally with Einstein Case Classification (which fills Type and Reason fields), Einstein Case Wrap-Up (which drafts a closing summary), and Einstein Reply Recommendations (which surfaces draft responses to the assigned agent). Together the four features cover the lifecycle from case creation to closure, removing the manual sorting work that pulls agent time away from actual customer problem-solving.

Einstein Case Wrap-Up is the Service Cloud feature that suggests closure-time field values when an agent is wrapping up a Case. The model reads the case description, comments, email threads, chat transcripts, and any related Knowledge attachments, then recommends values for closure fields like Status, Resolution Code, Root Cause, and similar custom picklists. The agent reviews, accepts or edits, and saves. The aim is to keep closure data clean and consistent without forcing the agent to remember every picklist option on every case type. The feature is the closure-time sibling of Einstein Case Classification (which acts at intake) and shares the same training-data-quality dependency. Clean historical closures produce sharp suggestions; inconsistent historical closures train a model that confidently recommends the wrong values. The biggest single rollout decision is which closure fields to suggest; a focused set of three or four fields outperforms a long list that becomes noise.

Einstein Conversation Insights is a Sales Cloud feature that ingests recorded sales calls, transcribes them, identifies key moments (mentions of competitors, pricing, objections, action items), and surfaces the highlights in Salesforce on the related Account, Opportunity, or Contact record. The product is sometimes called ECI in internal docs. It connects to call recording sources (Zoom, Microsoft Teams, Sales Dialer, and several partners), pulls the audio, runs speech-to-text and entity detection, and writes the resulting Insight records linked to the relevant CRM record. Conversation Insights sits at the intersection of revenue intelligence and AI-assisted coaching. Sales managers use it to spot patterns across the team's calls (which reps handle pricing objections well, which calls mention a competitor we should learn about). Reps use it to find a specific moment in a past call without re-listening to the full hour. The product is competitive with Gong and Chorus and shares much of the same value proposition: turn the hidden data inside sales calls into searchable, reportable, coachable signal.

Einstein Deal Insights is a Sales Cloud feature that analyzes the activity, engagement, and history of an open Opportunity and surfaces signals about deal health: stalled activity, single-threading risk, engagement decay, and similar patterns observed across past won and lost deals. The insights appear on the Opportunity record as a panel of cards with a short narrative (Activity is below the win-rate benchmark for deals at this stage) and, where applicable, a recommended next step. The signals are derived from email, calendar, and CRM activity, mixed with historical pattern data. Deal Insights belongs to the Revenue Intelligence family of Sales Cloud Einstein features. It pairs naturally with Einstein Opportunity Scoring (which rates the probability of close) and Pipeline Inspection (which gives managers a portfolio-level view of pipeline health). Where Opportunity Scoring tells the rep this deal is at 45 percent probability, Deal Insights tells the rep why and what to do about it. The split matters because a score without diagnosis cannot drive action; the rep needs to know whether the score is low because of stage stagnation, single-threading, weak engagement, or something else.

Einstein Discovery is the AutoML platform inside Salesforce that builds predictive models on the org's data without requiring data science expertise. The user supplies a dataset (a Salesforce object, a CSV upload, or a CRM Analytics dataset), picks a target variable to predict (Will the deal close? Will the case violate SLA? What is the expected lifetime value?), and Einstein Discovery automatically builds, evaluates, and deploys a regression or classification model. The output is a Story: a queryable model with explanations of which variables drive the prediction. Einstein Discovery is the AI surface that bridges raw Salesforce data and operational decisions. Predictions can be embedded in record pages (showing the predicted score directly on the Account or Opportunity), referenced from Flow and Apex (using the prediction to drive automation), and called from Einstein Next Best Action strategies (ranking recommendations by predicted acceptance). The platform handles model retraining, drift detection, and explanation generation. Discovery sits inside the broader Einstein suite alongside Einstein Prediction Builder, Einstein Bot, Einstein Search, and Agentforce.

Einstein Engagement Scoring is the Marketing Cloud Account Engagement (Pardot) feature that uses machine learning to score Lead and Contact engagement on a 1-100 scale predicting marketing-ready and sales-ready behaviour. The scores complement the traditional rule-based Pardot Score (which adds points for emails opened, pages visited, forms filled) by adding ML-driven predictions: which Leads will likely convert based on observed patterns across the org's history, not just a manual point tally. Engagement Scoring is one of three Einstein products inside Marketing Cloud Account Engagement, alongside Einstein Behavior Scoring and Einstein Lead Scoring (the Pardot-side version, distinct from the Sales Cloud Einstein Lead Scoring). The three scoring products overlap conceptually; Salesforce has not fully unified them. Engagement Scoring uses prospect activity data (emails, web visits, form submissions, asset downloads); Behavior Scoring uses behavioral signals over time; Lead Scoring uses fit-based attributes. Most orgs end up using one or two, not all three, and reconciling the scoring strategy is a Marketing Ops decision.

Einstein Language was the Salesforce-hosted natural language processing API that exposed three pretrained models to developers: Einstein Intent (classify a text snippet into a custom intent set), Einstein Sentiment (label a text snippet positive, negative, or neutral), and Einstein Named Entity Recognition (extract people, places, organizations, and other entities from text). It was part of the Einstein Platform Services family, accessed via REST API with a connected app and a JWT-signed token, and aimed at custom apps that needed NLP without owning the ML pipeline. Einstein Language was retired in late 2024 and replaced by newer Einstein NLU capabilities embedded in Einstein Bots, Service Cloud Einstein features, and the Einstein Trust Layer's text-processing pipeline. For new projects, the right path is the embedded NLU inside the consuming feature (Einstein Bots for intent, Einstein Case Classification for case routing, Einstein Sentiment in Service Cloud for case and chat scoring) or, for custom requirements outside those features, a foundation model via Prompt Builder or Bring Your Own Model in Einstein Studio. Documentation references and Trailhead modules still refer to Einstein Language; the underlying API is not currently accepting new connected apps.

Einstein Lead Scoring is the Salesforce machine learning feature that ranks Leads on a 1-99 score predicting which ones are most likely to convert into Opportunities. The model trains on your org's own historical Lead data: which Leads converted, which fields they had populated, how long they took, what Lead Source brought them in. The output is a score field plus an explanation panel showing the top factors driving each Lead's score, so reps can see why one Lead is hotter than another. The feature is part of Sales Cloud Einstein, an add-on license tier above standard Sales Cloud. Einstein Lead Scoring is one of several scoring products (Opportunity Scoring, Account Recommendations, Activity Capture). It is the most mature and the easiest to deploy, because it requires no configuration beyond enabling it; the model auto-trains on the org's existing data and starts producing scores within 24-48 hours. Orgs without enough historical conversion data (under a few hundred converted Leads in the last six months) cannot use it; the model needs training examples.

Einstein Next Best Action (NBA) is the Salesforce recommendation engine that surfaces personalized action suggestions to users based on rules, data, and AI-predicted scoring. A user looking at an Account in the Service Console might see suggestions like "Offer warranty extension", "Schedule follow-up call", "Send retention discount", each tied to the rules and the predicted likelihood that the customer will respond. The engine combines a Strategy (the rules and branching logic) with optional Einstein Discovery predictions to rank the recommendations. NBA is built on three concepts: Recommendations (the individual items shown to the user), Strategies (the branching logic that selects which Recommendations are eligible), and Action Strategies (the runtime objects deployed to a Lightning page). The recommendations render in the Einstein Next Best Action Lightning component, dropped onto the record page in App Builder. Each recommendation includes a label, description, and an action (accept, reject, mark as completed). NBA is the bridge between the data Salesforce holds about a customer and the next concrete step a salesperson, agent, or marketer should take.

Einstein Opportunity Scoring is the Sales Cloud Einstein feature that ranks open Opportunities on a 1-99 score predicting which ones are most likely to close as Won. The model trains on the org's own historical Opportunity data: which deals closed-won, which closed-lost, what fields they had populated, what activity preceded each outcome. Reps see the score on every Opportunity, along with a Top Positive Factors panel explaining what is driving the prediction. Opportunity Scoring is the sibling feature to Einstein Lead Scoring, sharing the underlying Einstein Discovery ML platform but trained on Opportunity outcomes instead of Lead conversions. It is the most operationally useful Einstein Sales feature for late-stage pipeline reviews: a Forecast Call where every Best Case Opportunity has an Einstein score above 80 deserves more confidence than one where most Best Case deals score under 30. The score is recalculated daily as Opportunity fields change, so it stays current through the deal cycle.

Einstein Platform is the umbrella Setup area in Salesforce that hosts the configuration surfaces for the org's Einstein AI capabilities: Prediction Builder, Einstein Discovery, Einstein Bots, Einstein for Service, Einstein for Sales, Einstein Vision, Einstein Language, and the newer Agentforce family. It is less a product than an organizing label; admins navigate to Setup, Einstein Platform to find per-feature setup pages, monitor usage and quota, and review the Einstein Activity log that captures every model call across features. The Einstein Platform area predates the Atlas Reasoning Engine and the modern Agentforce capabilities. Salesforce has been adding new AI capabilities under the Einstein brand for years; the Platform label is the consolidation point that anchors them in Setup. The newer Einstein Setup guided experience overlaps significantly with the Platform area; most teams use Einstein Setup for initial enablement and the Platform area for ongoing configuration of specific features.

An Einstein Prediction is the scored output of a machine learning model that Salesforce trains on the org's own records to forecast a specific future outcome. Predictions appear as a number, a probability, or a category on a record field, and they update as the underlying record data changes. Built-in Einstein Predictions include Einstein Lead Scoring, Einstein Opportunity Scoring, Einstein Forecasting, and Einstein Case Classification. Custom Einstein Predictions are built through Einstein Prediction Builder by picking a target field, defining the training data filter, and letting Salesforce train and deploy a model. The defining property is that Einstein Predictions live on Salesforce records and run on Salesforce data. Unlike LLM-generated text, a prediction is a deterministic score from a discriminative model; the same inputs produce the same output. Predictions surface in list views, reports, dashboards, flows, and Apex without requiring custom integration. The cost is bounded by the org's edition; built-in predictions are usually included, while custom Prediction Builder predictions count against a per-edition quota of how many models the org can have active.

Einstein Prediction Builder is the lightweight, admin-friendly predictive modeling tool inside Salesforce that builds simple binary or numeric predictions on a single Salesforce object without requiring a separate dataset or CRM Analytics licensing. The admin picks an object (Account, Case, Opportunity), picks a field to predict (Will this case escalate? Will this opportunity close?), and Einstein Prediction Builder builds a model on the org's historical data automatically. The deployed prediction can be referenced from Flow, Apex, and Lightning record pages. Prediction Builder is intentionally simpler than Einstein Discovery. It works on a single object (no joining datasets), supports binary classification (Yes or No) and numeric regression (a number), and uses a guided UI without exposing model internals. The trade-off is reduced flexibility: complex feature engineering, cross-object joins, and bias-aware variable exclusion all require Einstein Discovery instead. Prediction Builder is the right starting point for "will this case escalate" or "will this opportunity convert" questions where the data is on a single object and the admin wants a deployed prediction without learning AutoML concepts.

Einstein Product Recommendations is the Salesforce Commerce Cloud feature that powers product carousel recommendations across the storefront. It analyzes shopper behavior (page views, searches, cart activity, purchase history) plus catalog metadata, and selects products to surface in carousels on product detail pages, cart pages, category pages, homepages, and order confirmation pages. Each carousel uses one of several recommender strategies (Customers Also Bought, Recently Viewed, Top Sellers, Complete the Set, Recommended for You), and merchandisers pick the strategy per placement without writing code. Product Recommendations is the workhorse personalization feature inside the Commerce Cloud Einstein bundle. It pays back fastest of any Einstein commerce feature because the carousels are visible to every shopper on every visit, and the recommendations refresh as shopper behavior changes. The biggest leverage admins have is choosing the right strategy per placement and respecting business rules (out-of-stock filtering, merchandiser-pinned items) that the algorithm should not override.

Einstein Relationship Insights (ERI) is a Sales Cloud feature that scans external sources (news, the web, public profiles) to surface relationship signals about Accounts, Contacts, and Leads in the CRM. The product flags newsworthy events (executive changes, acquisitions, funding announcements), maps relationship paths between people in the org and people at the target account, and presents the signals as a research card pinned to the record. Reps use ERI to walk into a sales meeting informed about the customer without spending the prep time on Google. Relationship Insights is one of the older Sales Cloud Einstein features and has gone through several rebrands. The core promise has stayed the same: turn the unstructured signal scattered across LinkedIn-style relationship data, news feeds, and public business directories into a structured panel inside Salesforce. Adoption tends to be highest in enterprise sales motions where deal cycles are long and the cost of walking into a meeting cold is high. For SMB-focused sales motions with short cycles, the feature can feel heavyweight.

Einstein Reply Recommendations is the Service Cloud feature that suggests pre-written reply text to agents handling chat, messaging, and case email conversations. The model trains on the org's historical conversations that led to resolution, learns which reply patterns work for which inbound message types, and surfaces three suggested replies in the agent's sidebar at runtime. The agent can click to insert a reply (with or without editing) or write their own response from scratch. The feature does not auto-send; the agent always reviews before the message goes to the customer. Reply Recommendations is the conversation-time sibling of Article Recommendations and Case Wrap-Up in the Einstein for Service stack. It pays back fastest on high-volume channels (Messaging, Live Chat) where shaving 30 seconds off each reply compounds across thousands of conversations per day. Its quality depends on training data; teams that train on cleanly resolved conversations with good agent reply patterns get sharp suggestions, while teams that train on the full history of every conversation (resolved or not, well-handled or not) get noisy suggestions agents quickly learn to ignore.

Einstein Sales is the Setup area in Salesforce that hosts the AI-powered configuration surfaces for Sales Cloud: Einstein Lead Scoring, Einstein Opportunity Scoring, Einstein Activity Capture, Einstein Deal Insights, Einstein Forecasting, Einstein Conversation Insights, Einstein Account Insights, and the Sales-specific Agentforce SKU. It is an organizing label inside Einstein Platform rather than a single product. Admins navigate to Setup, Einstein Sales to find per-feature configuration pages, monitor usage, and review which features are active for their edition. The Einstein Sales features predate the modern Agentforce era but continue to ship with Sales Cloud at Enterprise+ editions where they are included. Most of the features train on the org's own historical Sales Cloud data (closed Opportunities, converted Leads, activity history) and surface predictions or signals directly on records, list views, and dashboards. The newer SDR Agent and Sales Coach (from Agentforce for Sales) sit alongside the older Einstein Sales features and use much of the same data foundation.

Einstein Search is the AI-driven global search experience in Salesforce that personalizes results, supports natural language queries, and surfaces relevant records, files, and knowledge directly in the search bar. It runs on top of the standard Salesforce search index, layering personalization (based on the user's recent records and access patterns), query understanding (interpreting phrases like my open opportunities or cases from yesterday), and instant results in the search box dropdown before the user even hits enter. Einstein Search is part of the Lightning Experience and is enabled in Setup at the org level. Once on, it replaces the legacy global search behavior for all users without changes to underlying search indexing, sharing rules, or field-level security. The performance gain is most visible to sales and service users who search constantly throughout the day: less typing, fewer false positives, and natural-language filters that previously required navigation to a list view. Einstein Search is one of the most underused features in the Lightning Experience because it ships off by default in some editions.

Einstein Search Dictionaries is the Salesforce configuration feature that lets admins define synonyms, abbreviations, and equivalent terms so global search returns the same records regardless of how the user phrases the query. Mapping "acct" to "Account", "IBM" to "International Business Machines", or "qty" to "quantity" means both query forms find the same records. Dictionaries apply across the Lightning global search bar, list-view searches, Experience Cloud search, and any search that uses the Einstein Search engine. Dictionaries are managed per language; each org maintains separate dictionaries for English, French, German, and so on, scoped to the languages the org uses. The configuration is no-code: admins add term mappings in Setup, the index picks them up automatically, and search behavior changes within minutes. The feature is one of the cheapest improvements to global search quality, and one of the most underused; orgs that invest in dictionary curation see immediate measurable improvements in zero-result rates.

Einstein Send Time Optimization (STO) is a Marketing Cloud Engagement feature that uses machine learning to determine the best time to send a marketing message to each individual contact. The model trains on historical engagement data (opens, clicks, conversions across send times) and predicts a per-recipient window when the message is most likely to be opened or acted on. When a journey or send is configured to use STO, the platform queues each message for delivery at the recommended time for that recipient rather than blasting the whole list at a single moment. Send Time Optimization is one of the more measurable Einstein features in Marketing Cloud because the lift shows up directly in open rates and click rates. A campaign that sends at 9 AM in the marketer's time zone reaches some recipients at 6 AM local, some at midnight, and some at noon. STO reshapes that distribution so each contact gets the message at their personal best window. The lift is modest per send (typically 5 to 15 percent on open rate) but compounds across the program because every send benefits.

Einstein Setup is the guided Setup experience in Salesforce that walks administrators through enabling and configuring the org's Einstein AI features. It surfaces the available features in one place, recommends which to enable based on the org's data and usage patterns, and runs activation wizards for each. Where Einstein Platform is the organizing tree of per-feature pages, Einstein Setup is the curated tour that helps admins discover and turn on the right features without already knowing what they are. Einstein Setup is most useful for new orgs or new admins joining an existing org. It shows which Einstein features the edition includes, which are enabled, which have outstanding setup steps, and which would benefit the org based on data volume and current configuration. Experienced admins who know their feature set tend to bypass Einstein Setup and go straight to specific Einstein Platform nodes; both surfaces are valid entry points and write to the same underlying configuration records.

The Einstein Trust Layer is the Salesforce-managed runtime layer that sits between customer data and the foundation model when any generative AI feature is invoked. It performs four primary jobs on every prompt: data masking (replacing PII with placeholders before the prompt leaves the Salesforce boundary), dynamic grounding (injecting authoritative source data so the model has the right facts in context), toxicity and bias detection (filtering responses for harmful content), and zero-retention auditing (logging the prompt and response so the customer has a full record of what the model saw and said). The Trust Layer is the architectural reason Salesforce can call out to third-party LLMs (in-house, OpenAI, Anthropic, others) without exposing customer data to those providers' training pipelines. The masking happens before the request leaves the Salesforce boundary. The unmasking happens after the response returns. The provider sees a tokenized prompt without recognizable names, emails, or account numbers. The contract with each model provider also forbids retention or training on customer prompts. The Trust Layer enforces in software what the contract promises on paper.

Einstein Vision was the Salesforce-hosted computer vision API in the Einstein Platform Services family. It offered four pretrained model types accessible via REST: Image Classification (label an image from a custom class set), Object Detection (identify and bounding-box objects in an image), Visual Search (find visually similar images from an indexed set), and the OCR endpoint for extracting text from images. Custom apps consumed the API by HTTP, sending image bytes or URLs and receiving JSON predictions, then writing the result back into Salesforce records as needed. Einstein Vision was retired alongside Einstein Language in late 2024 as the Einstein Platform Services family wound down. Salesforce's visual AI capabilities now live inside specific surfaces (Field Service for image-based diagnosis, Commerce Cloud Einstein for product recommendations from images, Files for visual search inside the org) rather than as a generic API. For custom computer vision needs outside those surfaces, the modern path is Bring Your Own Model in Einstein Studio with a vision model trained externally and registered for use through prompt templates or flows.

Email Address Internationalization (EAI) is a Salesforce org setting that allows email addresses to contain non-Latin characters in both the local part and the domain. When enabled, the platform validates and accepts addresses like 用户@example.com or josé@empresa.es in any field defined as an Email type, and processes those addresses correctly when sending and receiving mail through the standard delivery channels. Without EAI, email fields silently reject non-ASCII characters and surface a validation error to the user. The setting matters because real customer data includes addresses in scripts beyond the ASCII range. CRM data imported from systems in China, Japan, Korea, the Middle East, or parts of Latin America regularly contains internationalized addresses, and the absence of EAI causes either silent data loss during imports or hard rejections that break sync jobs. Salesforce ships EAI off by default in most editions because the underlying SMTP infrastructure has historically required ASCII addresses, and enabling it changes how the platform validates every Email field across every object.

An Email Alert is a Salesforce automation component that sends a pre-configured email when triggered by a Workflow Rule, Process Builder, Flow, or Approval Process. Each Email Alert pairs an Email Template with a list of recipients and the underlying object that triggers the message. When the rule, process, or flow fires the alert, Salesforce merges the template with data from the triggering record and sends the email to the configured recipients. Email Alerts are how Salesforce automation produces customer-facing communication without writing Apex. The configuration lives in Setup, then Email Alerts: pick the object (Case, Lead, Opportunity), pick the email template (Classic Email Template, Lightning Email Template, or Visualforce Email Template), and define the recipients (Roles, Users, Groups, Email Field on the record, Email Address). The alert is then available to Workflow Rules, Process Builder actions, Flow Send Email elements, and Approval Process actions. A single Email Alert can serve multiple automations, so well-named alerts become reusable building blocks.

Email Approval Response is the Salesforce feature that lets approvers approve or reject approval requests by replying to the notification email with specific keywords, rather than logging into Salesforce. When an Approval Process notification reaches the approver's inbox, they can reply with keywords like APPROVE, APPROVED, YES, REJECT, REJECTED, or NO in the message body, and the platform processes the response automatically. Comments included in the reply are captured as approval comments on the resulting ProcessInstanceStep record. Email Approval Response speeds the approval cycle for mobile and email-heavy approvers who want to clear the queue without opening Salesforce. The feature is enabled per org in Setup, then Process Automation Settings. Once on, every Approval Process that sends email notifications gets the email-response capability automatically; no per-process configuration is needed. Approvers see standard formatting instructions in the notification email reminding them how to reply.

Email Attachments are files attached to inbound or outbound email messages handled by Salesforce, stored either as ContentDocument records (under Enhanced Email) or as Attachment records (legacy mode). The platform handles attachments differently depending on whether the email was sent from a Salesforce-native channel (List Email, Email-to-Case, Outlook/Gmail integration), received through Email Services, or imported from a connected mail client. Across all these paths, the attachment is preserved as a file linked to the relevant EmailMessage record, and remains accessible from the Activity Timeline on related records. Storage of email attachments counts against the org's Files allocation, not Data storage. Default maximum attachment size depends on the channel: outbound List Email sends up to 25 MB per email, Email-to-Case ingestion handles up to 25 MB per inbound message, and Apex email handlers cap at 25 MB per inbound message split across all attachments. The platform automatically MIME-decodes attachments on inbound mail and re-encodes on outbound, so administrators rarely need to deal with the encoding directly.

Email Delivery Settings is the Salesforce Setup page that controls org-wide outbound email behavior, including the Access Level (No Access, System Email Only, All Email), Bounce Management, deliverability address verification, and the Compliance BCC Email feature. The page is the master switch for whether Salesforce will send mail at all, and what kind of mail. Sandbox orgs default to System Email Only; production orgs default to All Email. Misconfiguration here is the most common reason a sandbox refresh "loses email" overnight. The settings affect every email send across the org: Apex Messaging.SingleEmailMessage and MassEmailMessage calls, Workflow Email Alerts, Flow Send Email actions, List Email and Quick Send, Email-to-Case auto-responses, and any AppExchange package that sends mail. The Access Level toggle is org-wide, with no per-user, per-profile, or per-object override. Once set, all outbound email channels obey it.

Email Footers are the org-wide blocks of text appended to outbound mail from Salesforce, configured through the Email Footers Setup page. Two kinds exist: a general email footer attached to mail sent through Apex, Workflow, Flow, and the standard composer, and a mass email footer that appends to List Email and legacy Mass Email sends. Each footer is plain text, capped at 32 KB, and applied unconditionally to its respective send category across the entire org. The feature exists for compliance, not branding. Most organizations use email footers to satisfy regulatory disclaimer requirements: CAN-SPAM addresses, GDPR data-handling notices, financial services compliance text, healthcare HIPAA boilerplate. The text is not a marketing signature; that lives in per-user signatures on the User record. The footer is the small-print legal text appended to every outbound send.

Email Message in Salesforce refers to the EmailMessage object, which stores every email sent to or from a Case (or other supported object) as a record. The object is a child of Case (and supported parents) via the ParentId field, and each EmailMessage holds the From, To, Cc, Bcc, Subject, HTML body, text body, attachments, and metadata about the conversation thread. Email-to-Case, the Lightning Email Composer, automated case responses, and Marketing Cloud Engagement journeys all create EmailMessage records. EmailMessage is the queryable representation of email in Salesforce, separate from Email Templates (the content blueprint) and Email Alerts (the automation trigger). When an agent sends a reply from a Case feed, the platform creates an EmailMessage with status Sent. When a customer replies to that thread, Email-to-Case captures it as another EmailMessage with status New. Reports against EmailMessage power agent productivity dashboards, response-time SLAs, and email-volume analytics.

An Email Notification in Salesforce is an automated message dispatched by the platform to inform users about a system event, record change, task assignment, approval step, or any business condition an administrator has configured. It is the most common form of out-of-band communication the platform produces, and every org sends thousands of them per day across automation tools, system events, and user-driven actions. Email notifications are produced by several different mechanisms inside Salesforce, each with its own configuration surface and delivery limits. The same notification might originate from a Flow, a Workflow Rule, an Approval Process, a Case Assignment Rule, an Apex method, or a built-in platform event such as a password reset. Understanding which mechanism sent which email is the first step in debugging delivery, formatting, and reputation issues.

Email Services is the Salesforce framework that lets the platform receive inbound email and process it through Apex code. Each Email Service is a configuration linking a generated Salesforce email address to an Apex class implementing the Messaging.InboundEmailHandler interface. When mail arrives at the address, the platform parses the headers, body, and attachments, constructs an InboundEmail object, and invokes the Apex handler. The handler returns an InboundEmailResult indicating whether to acknowledge or reject the message. Email Services predate Email-to-Case and remain the foundation for custom inbound email processing. Where Email-to-Case is a packaged feature for converting mail into Case records with limited customization, Email Services is the raw building block: any inbound email logic that does not fit the Email-to-Case model lands here. Common uses include parsing structured email from external systems (purchase orders, automated notifications), building custom case routing logic, and integrating with mail-based workflows that Email-to-Case cannot handle.

Email Studio is the email marketing tool inside Salesforce Marketing Cloud Engagement (formerly known as ExactTarget). It is where marketing teams design, build, test, schedule, and send mass marketing emails: newsletters, promotional campaigns, transactional confirmations, abandoned-cart sequences, and other automated email programs. Email Studio operates on Subscribers (people on your marketing lists), Data Extensions (custom relational tables of subscriber attributes), and Content Builder assets (reusable email content blocks). Email Studio is a separate product from Salesforce Sales Cloud's email features (Email Alert, EmailMessage), aimed at marketing operations rather than sales or service. A Marketing Cloud Engagement license is required; sending volume is the primary pricing factor. Email Studio integrates with Journey Builder for sequence-based campaigns and with Salesforce CRM (via Marketing Cloud Connect) for synchronized Lead and Contact engagement.

An Email Template is a reusable blueprint for the content of an outgoing email in Salesforce: subject, body, merge fields, attachments, and HTML styling. Templates are stored as records and referenced by Email Alerts, Process Builder and Flow Send Email actions, Approval Process notifications, manual record sends, and (in Marketing Cloud Engagement contexts) marketing campaigns. The same template can serve a hundred different sends; updating it once propagates the change everywhere it is used. Salesforce supports three template types for the platform email (separate from Marketing Cloud's Content Builder). Classic Email Templates date to pre-Lightning Salesforce and remain widely used. Lightning Email Templates were introduced in 2018 with a modern editor, rich formatting, and easy merge-field insertion. Visualforce Email Templates are programmatically generated via Apex and Visualforce markup, supporting complex content beyond what the visual editors can produce. Choosing the right type is mostly a function of complexity and existing template inventory.

Email to Salesforce is a per-user feature that lets each Salesforce User send or BCC mail to a generated personal Salesforce address, automatically logging the message as an EmailMessage record against matching Contacts, Leads, or other records in the org. The feature exists so that sales reps using their corporate inbox (Outlook, Gmail, Apple Mail) can capture customer email in Salesforce without installing the full Outlook or Gmail integration. Each user enables the feature individually, receives a unique address like 12345abc@auto.salesforce.com, and adds that address as a BCC on outbound mail or forwards inbound mail to it. The feature predates the modern Outlook and Gmail integrations and the Inbox product, but remains useful when the integrations are not feasible: users on unsupported mail clients, occasional capture from mobile, or partner organizations where IT has not approved the integration. Logged emails appear in the Activity Timeline of the matching record, threaded with prior conversations, and remain queryable through the EmailMessage object like any other Enhanced Email record.

Embedded Service is the Salesforce feature that puts service capabilities (chat, Knowledge search, case submission, video calls, appointment booking) into an external website through a small JavaScript snippet. Customers on your marketing site, e-commerce store, or help center can start a chat, find a Knowledge article, file a case, or schedule a service appointment without leaving the page or logging into anything. The embedded experience is configured in Salesforce and renders on the external site via the snippet, with bidirectional data flow back to Service Cloud. Embedded Service is part of Service Cloud and Service Cloud Voice; it requires a license and lives at Setup, then Embedded Service Deployments. Each deployment defines the configuration: which channels are available, what languages, which agents handle the requests, how the widget looks. Multiple deployments can target different sites or audiences (a B2B portal versus a consumer site), each with its own visual style and routing rules.

Embedded Service Deployments is the Setup page where Salesforce admins configure each instance of Embedded Service for an external site. Each deployment is a discrete configuration: which channels are enabled (chat, messaging, appointments), which Salesforce queues handle the work, what the widget looks like, which audiences see it. Multiple deployments can coexist in one org, each targeting a different host site, audience, or use case (one for B2B partners, one for consumer customers, one for the help center). The page lives at Setup, then Embedded Service Deployments. From here you create, edit, and clone deployments; generate the JavaScript embed snippet for each; and monitor deployment status. Cloning is the common workflow: build one deployment, get it right, then clone it for variants (a different region, a different language, a different brand). The underlying configuration is metadata, so deployments can be source-controlled and migrated through Salesforce DX.

Enablement Lite Settings is the Salesforce Setup configuration page for the entry-level version of Sales Enablement, the in-app training and onboarding product. The Lite tier ships free with Sales Cloud and Service Cloud and provides a limited subset of the full Enablement features: basic in-app guidance, simple milestones, and the My Performance widget on Lightning home pages. Enablement Lite is the introduction to the broader Enablement platform that organizations can later upgrade by purchasing the full Enablement license. The Settings page itself is short. It controls org-wide enablement of the feature, the home page widget visibility, and the global on/off for in-app guidance. Configuration of actual programs, milestones, and exercises happens elsewhere, but everything starts at this page. Administrators looking to introduce structured rep onboarding without buying additional licenses use Enablement Lite as the on-ramp.

Encrypted Data at Rest is the Salesforce platform capability that stores stored data on disk in an encrypted form, distinguishing it from data in transit (which uses TLS) and data in memory (which is unencrypted while being processed). The platform encrypts all customer data at rest by default using AES-256, with the encryption keys managed by Salesforce as part of the trusted-platform model. Customers who need additional control over the keys can layer Shield Platform Encryption, Bring Your Own Key (BYOK), or Cache-Only Key Service on top of the default encryption. The distinction matters for compliance audits. Most regulatory frameworks (HIPAA, PCI DSS, GDPR, SOC 2) treat at-rest encryption as a baseline requirement, and Salesforce satisfies the baseline through its built-in encryption without any customer action. Customers seeking stronger guarantees, like the ability to revoke access to their data by destroying their own key, need the Shield-tier options that provide customer-managed key material.

An Encryption Key in Salesforce is the cryptographic material used to encrypt and decrypt data stored at rest. The platform uses a two-tier key hierarchy: tenant secrets (the customer-specific master keys) and data encryption keys (the per-record or per-field keys actually applied to ciphertext). Tenant secrets are generated under one of three management models depending on the customer license: Salesforce-managed (the default included with every org), Customer-generated through Bring Your Own Key (BYOK), or Customer-hosted through the Cache-Only Key Service. Keys rotate on a customer-defined schedule with no service interruption: existing data remains decryptable with prior keys while new writes use the current key. The platform stores key generation dates, rotation events, and usage in audit logs available to compliance teams. Destroying a customer-managed key permanently invalidates the data encrypted with it, including for Salesforce itself, which is the strongest guarantee of customer control over data access.

Encryption Key Management in Salesforce is the set of features that controls how data encryption keys are generated, stored, rotated, and revoked for Shield Platform Encryption. The default approach uses tenant secrets generated by Salesforce inside its Hardware Security Modules (HSMs); the platform handles key generation, storage, and automatic rotation without admin intervention. The advanced approach is Bring Your Own Key (BYOK), where the customer's security team generates the keys outside Salesforce, uploads them, and retains revocation rights. Salesforce never sees the BYOK key material in cleartext; it derives data encryption keys (DEKs) from the customer's tenant secret and uses those for actual encryption. Encryption Key Management requires Shield Platform Encryption, which is a paid add-on. Beyond BYOK, the Cache-Only Key Service lets customers keep keys entirely outside Salesforce (in AWS KMS, Azure Key Vault, or a custom KMS), with Salesforce fetching them per-encryption-operation. This is the highest-control model and is used by regulated industries (financial services, healthcare, government) that require key custody as part of their compliance posture.

Encryption Settings is the Salesforce Setup page where administrators manage Shield Platform Encryption: tenant secrets, field-level encryption assignments, file encryption, search index encryption, and key rotation. The page is the single control plane for everything Shield-related in the org. It is visible only when the Shield Platform Encryption license is provisioned; without the license, the equivalent page shows only the default Salesforce-managed encryption status and provides no configuration options. The page is split into sub-tabs covering Key Management (tenant secrets and rotation), Advanced Encryption Settings (event monitoring and feature toggles), Encryption Statistics (counts and progress of encryption jobs), and the specific encryption assignment screens for fields, files, and other data types. Administrators move between these tabs to enable a field for encryption, run a mass encryption job, rotate the tenant secret, and verify encryption coverage across the org.

Enhanced Bot is the modern Salesforce Einstein Bot type and the strategic successor to the classic Bot Builder experience. Introduced in 2022, Enhanced Bots use an improved NLP model, support multi-language conversations within a single bot definition, integrate with Einstein GPT for generative responses, and include Conversation Repair, the auto-detection feature that flags broken conversations and suggests Dialog improvements. New bots default to Enhanced; Classic remains for legacy compatibility but is no longer receiving major features. The Enhanced Bot Builder UI organizes Dialogs, Topics, Intents, and Entities into a more intuitive structure than Classic. Topics group related Dialogs (Order Management Topic, Account Management Topic). Conversation Repair runs automatically against the bot's conversation logs and identifies utterances the bot failed to handle well, suggesting fixes in the form of new training utterances or Dialog branches. Multi-language support lets one Enhanced Bot handle English, Spanish, French, and other supported languages from a single configuration rather than per-language bot clones.

Enhanced Email is the Salesforce setting that stores inbound and outbound email as EmailMessage records and attachments as ContentDocument files, replacing the legacy model that stored email as Activities with Attachment records. The change unifies email handling under a single object model accessible through Lightning, queryable through SOQL on the EmailMessage object, and reportable through standard report types. Enhanced Email has been on by default in new orgs since 2017 and is the foundation for every modern email feature: Email-to-Case threading, the Email Composer in Lightning, the Outlook and Gmail integrations, and the Activity Timeline display of email on records. The setting is org-wide and one-way: enabling cannot be reversed without a Salesforce support case. The activation rewrites the underlying storage model for all subsequent email, which is why Salesforce treats it as a permanent migration. Existing email Activity records from before activation remain accessible but in their original storage; new email lands under EmailMessage. Most orgs created after 2017 never need to think about Enhanced Email because it is already on; older orgs with legacy data may still have a mix of both storage models.

Enhanced Knowledge Settings is a transitional name used in some Salesforce documentation for the configuration options available specifically with the Lightning Knowledge feature set, as distinguished from the older Classic Knowledge settings. The phrase covers options like rich text body field configuration, channel selection per record type, the modern article search and ranking model, and the per-record-type page layouts that Lightning Knowledge introduced. The term appears mainly in Help articles discussing the differences between the legacy and modern Knowledge stacks. Enhanced Knowledge Settings is closely related to and often used interchangeably with Knowledge Settings (the broader Setup page). The Enhanced qualifier was added during the period when both Classic and Lightning Knowledge coexisted in production orgs and admins needed clear documentation distinguishing the two configuration models. In current documentation, the term is fading; most modern Salesforce Help articles use Knowledge Settings or Lightning Knowledge Settings without the Enhanced qualifier. The functional meaning is the same: org-wide configuration for the Lightning Knowledge feature.

An Enterprise Application is the broad category of software designed to support the operations of large organizations: customer relationship management (CRM), enterprise resource planning (ERP), human capital management (HCM), supply chain, accounting, marketing automation, and so on. Salesforce itself is an enterprise application, specifically a SaaS CRM that competes with SAP CRM, Microsoft Dynamics 365, Oracle CX, and HubSpot. The defining traits: multi-user concurrent access, integration with other enterprise systems, role-based access control, audit logging, and operational scale that consumer applications do not need. In Salesforce vocabulary, the term shows up in a few contexts. The AppExchange categorizes apps as Enterprise versus consumer or small-business. Salesforce's own product lineup (Sales Cloud, Service Cloud, Marketing Cloud, Industries clouds) is positioned as the enterprise application suite. Salesforce DX and second-generation packaging build the developer tooling that lets engineering teams produce enterprise-grade applications on the platform. The category is broad; the implementation details vary widely by industry, organization size, and process maturity.

Enterprise Edition is the mid-tier Salesforce edition, sitting between Professional Edition (smaller deployments, fewer features) and Performance or Unlimited Editions (larger, more storage, more integrations). It is the most common edition for medium-to-large organizations buying Salesforce: full API access, sandboxes, Workflow Rules and Flow, custom objects, Apex code, and most platform features. The pricing scales per-user-per-month, and the feature set covers the needs of most CRM, Service, and Marketing implementations without forcing customers up to the higher tiers. Enterprise Edition is what most discussions of Salesforce implicitly assume. Trailhead modules, AppExchange apps, and most third-party integrations are designed around Enterprise''s capabilities. Customers outgrow Professional Edition (which lacks API, sandbox, and Apex) when they need customization or integration; they upgrade to Performance or Unlimited when they need higher storage, more sandboxes, or premium support. Enterprise sits in the broad middle that fits a wide range of customer profiles.

The Enterprise WSDL is a Web Services Description Language (WSDL) document Salesforce generates per org that describes the SOAP API endpoints for that specific org's schema. Unlike the Partner WSDL (which is generic and supports any org), the Enterprise WSDL embeds your org's exact field names, data types, and custom objects. This makes it strongly typed: code generated from an Enterprise WSDL knows that Account.Industry is a Picklist, that Opportunity.Amount__c is a Currency, and that your custom MyObject__c has these specific fields. The trade-off is that the Enterprise WSDL must be regenerated whenever the schema changes. Salesforce orgs that integrate via SOAP API typically download the Enterprise WSDL once, generate strongly-typed client classes (in Java, .NET, Apex), and use those classes to call the API. The Enterprise WSDL is generated on demand from Setup, then API. For long-lived integrations with stable schemas, the Enterprise WSDL is the right choice; for tooling that must support many orgs, the Partner WSDL''s generic approach is necessary.

An Entitlement in Salesforce is a record that defines the level of customer support a person or account is allowed to receive, typically tied to a service contract, product warranty, or subscription tier. Entitlements drive case routing, milestone enforcement (response time, resolution time), and the visible "what service do you owe this customer" answer that service agents need at the moment a case opens. The Entitlement object is the backbone of Service Cloud's contract-aware support workflows. Each Entitlement record links to an Account (or Contact, or Asset), defines a Start Date and End Date for service eligibility, references an Entitlement Process that controls milestones, and counts cases consumed against any per-period or lifetime case allowance. When a service agent opens a case, the Entitlement field on the case tells the agent whether the customer has 4-hour response SLAs, 24-hour business-day support, or no contract entitlement at all. Without entitlements, every customer gets best-effort handling; with entitlements, the case routing engine knows exactly what was promised.

An Entitlement Contact is the junction record linking a specific Contact to an Entitlement, restricting which individual people at a customer Account can use that Entitlement when opening Cases. The standard model is: an Entitlement belongs to an Account; any Contact on that Account can theoretically reference it. With Entitlement Contacts active, only Contacts explicitly added to the Entitlement Contact list are eligible to use it. This is how enterprise service contracts enforce named-user support: the contract covers 5 named technical contacts, not the entire 200-person Account. The Entitlement Contact list lives as a related list on the Entitlement record. Adding a Contact creates an EntitlementContact junction record. The Case form filters the Entitlement picklist based on the Contact selected: pick the customer's main Contact and only the Entitlements they are named on appear. Without Entitlement Contacts, every Account Contact can use every Account Entitlement. Most B2B service teams enable this restriction; B2C and small-business deployments often skip it because the per-contact precision adds configuration burden without operational value.

Entitlement Management is the Service Cloud feature that lets a customer-support organization track contractual service-level agreements (SLAs) and the customer-facing rights (entitlements) tied to product purchases, service contracts, or assets. The feature provides the data model (Entitlement, ServiceContract, ContractLineItem, EntitlementContact, MilestoneType records), the SLA timer engine (Entitlement Processes with milestones), and the UI surfaces (case page Entitlement field, Milestone tracker, Entitlement Processes setup) needed to model and operate against contractual support obligations. Entitlement Management sits at the intersection of three concepts. An Entitlement is the customer's right to receive support (linked to an Account, a Contact, or an Asset). A Service Contract is the broader contractual agreement that contains multiple Entitlements. An Entitlement Process is the SLA timer that runs on each Case matched to an Entitlement. Together they let a Service Cloud team enforce "platinum customers get 1-hour response, gold customers get 4-hour response, silver customers get next-business-day response" with platform-tracked compliance and escalation actions when SLAs are missed.

An Entitlement Process is the SLA timer engine inside Service Cloud's Entitlement Management feature. It defines the milestones a case must hit, the time allowed for each milestone, the business hours used to measure elapsed time, and the actions triggered when a milestone completes, succeeds, or violates its target. The entitlement process is what turns a written SLA (respond within 2 hours, resolve within 24 hours) into clock-driven automation that pages the on-call team when the clock runs out. Entitlement processes attach to one or more entitlements, which themselves attach to accounts, contacts, assets, or service contracts. When a case is created and matched to an entitlement, the entitlement process clock starts. Milestones tick down against the business hours profile, fire workflow rules, send emails, escalate to other queues, and mark the case as compliant or in violation. The whole machinery is invisible to the customer and central to any contractual obligation a Salesforce-using company has agreed to.

Entitlement Settings is the Setup page in Salesforce where admins enable and configure the broader Entitlement Management feature: the master toggle to turn on the feature, the auto-population behavior, the contact verification policy, the lookup filters that decide which entitlements match a case, the milestone tracker layout, and the default Entitlement Process applied to new entitlements. The path is Setup, Service, Entitlement Settings. All decisions on this page apply org-wide and rarely change after the initial Service Cloud rollout. Entitlement Settings is the single configuration surface that controls how the entire Entitlement Management feature behaves. Without enabling it, the Entitlement, ServiceContract, ContractLineItem, and EntitlementContact objects are not available. Once enabled, the feature unlocks the SLA timer engine, the case-level entitlement field, and the milestone tracking. Most admins configure this page once during rollout and revisit only when adding new support tiers or adjusting the auto-population logic.

An Entitlement Template is a reusable pattern in Salesforce that defines a standard set of fields for new Entitlement records. When an admin creates an Entitlement Template, they specify the Entitlement Process, the default Term (in days), the per-case usage limits, the type of work covered, and any other field defaults. New Entitlements created from the template inherit these field values, so a salesperson or operations user can spin up a Gold Tier entitlement on a new account with one click instead of filling in 10 fields manually. Entitlement Templates are most useful in B2B service operations with many customer accounts and a small set of repeated support tiers (Platinum, Gold, Silver). Without templates, every new entitlement requires repeating the same field values, with the inevitable typos and mismatched processes. With templates, the operations team selects the tier, the platform fills in the rest, and the entitlement is consistent across customers. Templates also pair with Service Contracts: a Service Contract Line Item can reference an Entitlement Template, automatically generating the right entitlement when the contract activates.

An Entity in Salesforce is the general term for any data structure that can hold records: standard objects (Account, Contact, Case), custom objects (MyCustom__c), external objects (__x), platform events, and a few special metadata types. The term comes from database vocabulary where entity is the abstract concept that table makes concrete. Salesforce uses Entity in API documentation (the SOAP API has EntityDefinition for object metadata), in error messages (FIELD_NOT_FOUND on entity Account), and in the Tooling API where EntityDefinition and EntityParticle return metadata about objects and fields. Entity is the broader category that includes everything an object is plus things that are not quite objects (platform events, settings hierarchies, big objects). For most everyday work, the platform uses object as the user-facing term and entity for the abstract-metadata layer. Understanding both helps when reading API documentation or building Apex that introspects metadata: EntityDefinition has fields like DurableId, QualifiedApiName, DeveloperName, and IsCustomizable that work across every entity type.

An Entity Relationship Diagram (ERD) is a visual representation of an org's data model: the entities (objects), their fields, and the relationships between them. In Salesforce, ERDs are used to document the schema, plan changes, communicate the data structure to non-technical stakeholders, and audit cross-object dependencies. Salesforce''s Schema Builder is the platform''s built-in ERD tool, showing a drag-and-drop graph of objects with their relationships; third-party tools (Lucidchart, draw.io, ER/Studio) generate richer ERDs from the org''s metadata via the Tooling API. ERDs use standard notation: entities as boxes with fields listed inside, relationships as lines between boxes with crow''s-foot notation showing cardinality (one-to-one, one-to-many, many-to-many). In Salesforce, master-detail and lookup relationships have distinct visual treatments. Architects sketch ERDs before building anything; admins maintain them as living documents that update with each schema change.

An Enumeration Field in Salesforce is a field whose value is restricted to a predefined list of options. Picklists, Multi-Select Picklists, and the Apex enum keyword all express this idea. The platform stores enumeration fields as text values but enforces that only the configured options can be saved. Reports filter on them cleanly; validation rules reference them precisely; integrations send and receive them as strings. They are the platform''s primary tool for keeping data consistent when free-form text would produce variation (Industry: Tech, Technology, Tech and Software, Technology Industry, IT, Information Technology). In Apex, the enum keyword declares a programmatic enumeration: enum Status {New, InProgress, Closed}. These integrate with the Apex type system and prevent typos at compile time. At the database layer, the equivalent is a Picklist field with a controlled value set: defined once in Setup, referenced by every record on that object. Multi-Select Picklists extend the idea to multiple-value-per-record selections, with caveats about reporting and sorting that catch new admins.

Environment Hub is the Salesforce Setup feature that lets a Salesforce ISV or large customer enroll multiple connected Salesforce orgs under a single hub org, providing single sign-on across them, a unified view of org status, and centralized management of sandboxes, packaging orgs, and partner-managed orgs. The hub is intended for partners who maintain dozens of orgs (Partner Business Org, packaging org, test orgs, customer-facing demo orgs) and need a way to switch between them without separate logins. It is also used by large customers running multiple production orgs across business units or geographies. The hub org sits at the center; member orgs connect through OAuth and trust the hub for SSO. Once connected, a user authenticated in the hub can click through to any member org without re-entering credentials. Environment Hub also provides links for org creation, deletion, and basic provisioning. The feature is free with the Partner Developer Edition that ISVs receive when they enroll in the Partner Program, and available with extra licensing for non-partner enterprises.

The Error Console in Salesforce is the umbrella concept for the diagnostic surfaces where errors appear during development and troubleshooting: the browser''s developer console for client-side JavaScript errors, the Developer Console''s Problems tab for Apex compile errors, the System Log for runtime exceptions, the Email Logs page for email delivery failures, and the API Usage page for integration errors. There is no single Error Console button in Salesforce; the term describes a category of diagnostic views that developers, admins, and integration engineers consult when something fails. The most common error consoles by use case: for Apex code, the Developer Console''s Logs tab (catching debug logs and runtime errors); for Lightning Web Components, the browser''s developer tools console (catching client-side errors); for integrations, the Setup, then API Usage page combined with the Apex Trigger logs; for emails, Setup, then Email Logs. Each surface focuses on a specific failure mode; together they cover the platform''s troubleshooting needs.

An Event in Salesforce is a calendar item: a meeting, a call, a demo, a customer onsite, or any other interaction scheduled at a specific time. The Event object holds Subject, StartDateTime, EndDateTime, Location, ShowAs (Free, Busy, Tentative, Out of Office), and the polymorphic WhoId and WhatId fields that tie the Event to a Lead or Contact and to an Account, Opportunity, Case, or custom object. Events surface in Salesforce list views, on the Activity Timeline of related records, and in any calendar app (Outlook, Gmail) connected to Salesforce through Einstein Activity Capture or one of the Lightning Sync products. Event is the synchronous half of the Activity abstraction in Salesforce. Where Task captures an async to-do with a due date, Event captures a scheduled session with a start time and an end time. Both objects share the same WhoId and WhatId polymorphic structure and surface together on the Activity Timeline of any related record. Reps in field-heavy roles (account executives, customer success, field service) create more Events than Tasks; reps in inside-sales roles (SDRs, BDRs, AMs) create more Tasks than Events. Most enterprise Salesforce orgs eventually need reporting that combines both, which is where the polymorphic complexity of Activity reporting starts to bite.

Event Manager is the Salesforce Setup page that consolidates configuration for all event-driven integration features the platform supports: Platform Events, Change Data Capture, Flow Orchestration Events, and the supporting infrastructure for subscriptions, replay, and channel management. The page is the operational surface for event-driven architecture on Salesforce, giving admins and integration engineers a single place to monitor what events flow through the org, who subscribes to them, and what happens when a subscription falls behind. Event-driven architecture has grown significantly in Salesforce deployments over the past five years, driven by the need for real-time integration between Salesforce and external systems, between Salesforce and other clouds (Marketing Cloud, Data Cloud, MuleSoft), and between different layers of customization within Salesforce itself (Flow listening for record changes, Apex publishing custom events for downstream processing). Event Manager is the page that brings this varied landscape under a single management view.

Event Monitoring Settings is the Setup page where Salesforce admins configure how Event Monitoring data is captured, retained, and surfaced. Event Monitoring is the paid Shield add-on that produces fine-grained event logs for user activity: API calls, Apex executions, report runs, dashboard views, login events, file downloads, list view exports, and 70+ other event types. The settings page controls which event types stream in real time vs at end-of-day, how long the data is retained, and which storage objects receive the events. Event Monitoring data flows through three surfaces. EventLogFile is the legacy daily-aggregated CSV-style log. Streaming Real-Time Event Monitoring delivers events as they happen through Platform Events, queryable in SOQL and consumable by external SIEM systems. Event Monitoring Analytics App is the CRM Analytics-powered visualization layer that turns the raw events into dashboards. The settings page lets admins decide which event types use which delivery channels and how long history is kept on each. Together with Transaction Security and Health Check, Event Monitoring forms the operational backbone of Salesforce security operations.

Event Relays in Salesforce are a feature that forwards platform events from Salesforce to Amazon EventBridge, letting AWS-hosted systems consume Salesforce events natively. The relay is configured per event channel and per AWS account, with Salesforce taking responsibility for delivery, retry, and message ordering. This is how Salesforce becomes a first-class event producer in an event-driven AWS architecture without requiring custom Apex callouts or middleware. Event Relays are part of Salesforce''s broader Platform Events and Pub Sub API story. Platform Events are publish-subscribe messages internal to Salesforce; the Pub Sub API exposes them outside via gRPC streams; Event Relays extend the model by pushing them into Amazon EventBridge for AWS-native consumption. Customers running serverless workflows on AWS (Lambda, Step Functions, EventBridge Pipes) get a clean integration path without building a polling layer.

An Event Series in Salesforce is a recurring calendar event: a single configuration that produces multiple individual Event records, one per occurrence, on a defined schedule. The Event Series record holds the recurrence pattern (daily, weekly, monthly, yearly, with end date or occurrence count); each occurrence is a separate Event record tied to the series. Editing the series updates future occurrences; editing a single occurrence breaks it from the series for that one event only. Event Series support the standard calendar use cases: weekly 1:1s, monthly team meetings, yearly events. They live on the Event object (the same object that holds one-off events), distinguished by the IsRecurrence flag and the RecurrenceActivityId field that links occurrences to their parent series. Reports, calendar views, and sync to Outlook and Google Calendar all support them, though with some caveats on the sync side.

An Event Sink in Salesforce Open CTI is a JavaScript handler registered by a CTI implementation to receive events from Salesforce. The Open CTI framework lets external telephony providers (and modern Service Cloud Voice integrations) hook into platform events: when an agent changes status, when a softphone receives a call, when a click-to-dial button is pressed, when the user navigates to a different record. The Event Sink is the JavaScript function the CTI app provides; Salesforce calls it when the relevant event happens. Open CTI is the framework that lets custom telephony integrations live inside Salesforce without requiring server-side communication for every UI event. The Event Sink is the callback registration mechanism: the CTI app calls sforce.opencti.subscribe() (or the Lightning equivalent) with an event name and a handler function. From that point on, Salesforce invokes the handler whenever the event fires. This is how CTI implementations stay in sync with the Salesforce UI: agent status changes in the softphone reflect on the agent''s Salesforce page, and vice versa.

Event Studio is a Salesforce Setup area that provides administrative tools for designing, monitoring, and managing the event-driven messaging features of the platform: Platform Events, Change Data Capture events, Flow Orchestration events, and the supporting infrastructure for subscriptions, channels, and replay. It overlaps in scope with Event Manager and the various event-monitoring pages, with Event Studio acting as the design-and-build surface where admins create new event types, define their fields, and configure subscriber rules. The page is the right starting point for anyone building a new event-driven integration on Salesforce. Where Event Manager surfaces operational metrics (publish rates, subscriber lag, throughput consumption), Event Studio is the configuration surface where admins design the event itself. The two surfaces work together: Event Studio for the build phase, Event Manager for the operate phase. Mature event-driven deployments use both routinely, with admins moving between them as they iterate on new events and monitor production traffic.

An Exchange Asset in MuleSoft Anypoint Platform is a reusable artifact published to Anypoint Exchange (the integration content hub at the heart of MuleSoft) that other teams across the organization can discover, install, and reuse. Asset types include API specifications (RAML or OpenAPI), API fragments, connectors, integration templates, examples, custom policies, and complete API products. The Exchange model is the foundation of MuleSoft's API-led connectivity vision: every reusable integration component is published to Exchange where it can be consumed by other projects, reducing duplication and accelerating delivery. Inside Salesforce-integrated MuleSoft deployments, Exchange Assets bridge the gap between the broader MuleSoft asset library and the specific integration components Salesforce teams consume. A Salesforce admin building a Flow that calls an external API can browse Exchange for an existing connector or API specification rather than building from scratch. A MuleSoft developer publishing a new API publishes it to Exchange so future consumers can discover and reuse it. The combination of publish-and-discover patterns turns integration from a one-off engineering effort into a library-based composable practice.

The Experience API in Salesforce is the set of REST endpoints that expose Experience Cloud (formerly Community Cloud) data and capabilities for custom mobile apps, headless Experience Cloud sites, and external integrations. It is part of the broader Connect REST API (the chatter-style social-data API) but scoped to Experience Cloud sites: site members, feeds, recommendations, gamification, communities, groups. The Experience API is what powers branded customer-facing apps that need to talk to an Experience Cloud site without using the rendered LWR pages. Experience API endpoints follow the pattern /services/data/v60.0/connect/communities/{communityId}/resource, where the resource is feeds, members, groups, recommendations, knowledge, or similar. The API supports both authenticated user calls (using OAuth or named credentials) and certain anonymous public-knowledge calls. Lightning Web Runtime (LWR) Experience Cloud sites use a similar API under the hood; headless deployments use it directly.

Experience Builder is the Salesforce visual editor for creating and configuring Experience Cloud sites: customer help centers, partner portals, learning sites, marketing microsites, branded community experiences. The builder provides a drag-and-drop canvas, a component palette, theme controls, audience targeting rules, and the publishing workflow. Admins and developers use Experience Builder to assemble pages from Lightning Web Components, configure navigation, set branding, and deploy the site without writing custom front-end code for most use cases. Experience Builder is the Experience Cloud counterpart to Lightning App Builder. Both are drag-and-drop UI editors, but Experience Builder targets external-facing community sites while Lightning App Builder targets internal record pages and app pages. Experience Builder supports both Lightning Web Runtime (LWR) and Aura templates; the LWR builder is more modern and the recommended path for new sites.

Experience Cloud is Salesforce's product for building customer-facing portals, partner portals, employee communities, and public websites that connect external users to Salesforce data. Formerly known as Community Cloud, Salesforce Communities, and earlier as Force.com Sites, the rebranded Experience Cloud bundles the platform's external-user features into a unified product. Customers log into Experience Cloud sites to check Case status, browse Knowledge, manage their account; partners use sites to register Leads, track Opportunities, access training; employees use sites for HR self-service or intranet-style communication. Each Experience Cloud site is built from a template (Customer Service, Partner Central, Help Center, Build Your Own) plus pages assembled in Experience Builder (the Experience Cloud equivalent of Lightning App Builder). External users authenticate via licensed user records or via guest-user access for fully public content. Sharing rules, profiles, and permission sets control what data external users can see and modify. Experience Cloud is licensed per external user (Customer Community, Customer Community Plus, Partner Community, External Apps), with pricing per active user or per login.

An Experience Cloud Site is a single instance of an Experience Cloud deployment: one set of pages, one theme, one URL, one audience. Each site has its own configuration (template, components, navigation, branding) but lives in the same Salesforce org as other sites. A typical company has multiple Experience Cloud sites: one customer help center, one partner portal, one employee learning site. They share the org''s data and users but present completely different branded experiences. Each Experience Cloud Site corresponds to a Network record in the API (the underlying object that backs the platform''s site abstraction). Site administrators configure sites through Setup, then Digital Experiences, then All Sites. The configuration covers everything: which pages exist, what template they use, who can access them, what URL they live at, what branding they use. Sites are independently activated and deactivated; one site going offline does not affect others.

Expire All Passwords is a one-click Salesforce administrative action that invalidates the existing password for every user in the org, forcing each user to set a new password on their next login. The action is irreversible once executed: there is no undo, no per-user exemption applied retroactively, and no way to recover the prior passwords. It is one of the most consequential single actions an administrator can take in Salesforce, used almost exclusively during security incidents (suspected credential compromise) or major password-policy resets (a forced rotation after a policy change). The action lives under Setup > Users > Expire All Passwords. It applies to every user in the org including system admins, sandbox users, and integration users with standard logins. Users with single sign-on configured continue to authenticate through their SSO provider; only users who log in with a Salesforce username and password are affected. The platform records the action in the Setup Audit Trail with the executing administrator's name, providing an incident response record.

External Client App Manager is the Setup-area page in Salesforce where admins manage External Client Apps, the modern OAuth-integrated application records that replaced the older Connected App framework for newly registered apps. External Client Apps are OAuth 2.0 client identities that external systems use to authenticate against Salesforce, with scopes, policies, and certificate metadata managed through a Setup UI separate from the legacy Connected App Manager. External Client Apps were introduced in 2024 as the strategic direction for OAuth-protected integrations. They split the App definition (the client identity, secrets, scopes) from the policy configuration (refresh-token behavior, IP restrictions, session policies) into two separate metadata records: ExternalClientApp and ExternalClientAppOauthSettings. The split is what makes External Client Apps work cleanly with Salesforce DX, source control, and packaged deployment patterns that Connected Apps struggled with.

An External Data Source in Salesforce is a configuration record that defines how the platform connects to data living outside Salesforce: a SQL database, a SharePoint site, an OData service, an Oracle ERP, an S3 bucket, or any system that Salesforce Connect or Files Connect can talk to. Each External Data Source captures the endpoint URL, authentication method, and protocol details. Once defined, the platform can query the source live (Salesforce Connect) or surface its files in Salesforce (Files Connect), without copying the data into Salesforce records. External Data Sources are how Salesforce stays the system of engagement without being the system of record for everything. The customer's ERP holds invoices; the CRM holds opportunities and accounts; an External Data Source bridges the two so a Salesforce user sees invoice data inline on the Account record without ETL. Authentication patterns include OAuth, Named Credentials, Per-User basic auth, and Anonymous (for public OData services). The configuration lives in Setup, then External Data Sources.

An external lookup relationship is a Salesforce field that links a standard, custom, or external object record to a record held in an external system, with the join keyed on that external record's primary identifier. It is the Salesforce Connect mechanism that lets a Salesforce object point at a row sitting in SAP, an OData service, an Amazon Redshift cluster, or another Salesforce org without copying the data into the Salesforce database. Unlike a regular lookup that points to a Salesforce record by Salesforce ID, an external lookup uses the external object's external ID field, which is the value the source system uses as its own unique key. The Salesforce record stores that key, and the platform resolves it on demand when a user opens the page or runs a report. This keeps a single source of truth in the external system while still letting users see, navigate, and report on the linked data inside Salesforce.

An External Object is a Salesforce object that represents data living in an external system rather than in the Salesforce database. The records appear and behave like normal Salesforce records in the UI (page layouts, list views, related lists, lookup pickers), but each request resolves through Salesforce Connect to the underlying source system. External Objects use the __x API suffix and are the Salesforce-side projection of an OData service, a cross-org connector, or a custom Apex adapter. External Objects exist to give Salesforce users and Apex code a unified data model that spans Salesforce and external systems without copying data. A field-service team can see SAP work orders next to Salesforce Cases without an integration pipeline that moves rows between systems. A finance team can see ledger entries from Oracle alongside Opportunity records without ETL. The pattern preserves the source system as the single source of truth, with Salesforce acting as a read (and sometimes write) view. Salesforce Connect is the platform component that makes External Objects work, and it is licensed separately from base CRM.

External Services is the declarative Salesforce feature that imports an external REST API into Flow as a set of invocable actions, without writing Apex. You point External Services at an OpenAPI specification (the JSON or YAML description of the API), Salesforce parses the spec, generates strongly typed Apex wrapper classes, and exposes each endpoint as a Flow action that admins can drop into a flow like any other action. The feature solves the problem of "I want to call this API from a flow, but I do not want to write Apex." Before External Services, every external integration required a developer to build an @InvocableMethod wrapper, define input and output classes, and deploy it. With External Services the wrapper is generated automatically from the spec. The trade-off is rigidity; the generated code reflects the spec exactly, and complex authentication or response handling still needs custom Apex.

An External User in Salesforce is a user account that belongs to someone outside the host organization: a customer, partner, supplier, or other non-employee. External Users access Experience Cloud sites (customer help centers, partner portals) with limited license types specifically designed for external access: Customer Community, Customer Community Plus, Partner Community, and a few specialized variants. Their permissions, data visibility, and feature access are all narrower than internal Salesforce users by design, both to constrain cost and to maintain the security boundary between the host org and the outside world. External Users are central to Salesforce''s customer-self-service and partner-collaboration strategy. Every Customer Community portal user is an External User; every Partner Community user is an External User. They live in the same User object as internal users, but with a different license type, a Contact record linking them to an Account (the partner organization or the customer household), and a profile that restricts what they can do. The line between External and Internal users is one of the platform''s primary security boundaries.