Salesforce terms starting with A

An Account is the company, household, or person you do business with. In a Business-to-Business org it represents a buying organization, the one signing the contract and getting invoiced. In a Business-to-Consumer org it can represent an individual through Person Accounts, a variant covered later in this entry. Either way, the Account is where the data graph converges. Contact records carry an AccountId. Opportunities carry an AccountId. Cases, Assets, Orders, Contracts, and most Activity records do too. Even custom objects in most orgs add an Account lookup early in their schema. Reports without one end up answering "which deals" but never "whose deals." The Account is the join condition for nearly every cross-object report you will build. In Salesforce's standard data model the Account sits at the top of a small but heavily-trafficked subtree. Whatever you do here, the rest of the org feels. Bad Account hygiene shows up downstream as duplicate forecasts, broken sharing, mis-routed Cases, and territory rules that fire on the wrong region. Good Account hygiene quietly keeps every other object honest. The cost of getting Accounts right is one careful design pass on day one. The cost of getting Accounts wrong is paid every quarter, mostly by whoever's holding the forecast.

An Account Assignment Rule is the territory-management mechanism that automatically associates Accounts with one or more Territories based on rule criteria. It is part of the Enterprise Territory Management feature, the modern replacement for the legacy Customizable Territory Management module. The rule evaluates Account fields (Industry, BillingCountry, AnnualRevenue, custom fields) against an ordered list of conditions, and assigns matching accounts to the territory the rule belongs to. Account assignment rules sit between two concepts often confused: territory models and territories. A Territory Model is the active or planning version of the entire territory tree. A Territory is a node inside the model, with its own users, account assignments, and child territories. An Account Assignment Rule is attached to a single territory and runs when the territory model is activated or when an account is created or edited. The rule is the bridge between the data (accounts) and the structure (territories), without which territory management is just an org chart with no records inside it.

An Account Contact Relationship, often shortened to ACR, is a junction record that links a single Contact to additional Accounts beyond the one stored in the Contact's primary AccountId field. In a Business-to-Business org a real person rarely belongs to only one company. A consultant works with several firms. A board member sits on three boards. A buyer at a parent company also influences purchases at the subsidiary. The Contact's AccountId can hold only one of those affiliations. Every other relationship lives in an AccountContactRelation row, with the role described in fields like Roles, IsActive, StartDate, and EndDate. The object exists because Salesforce's data model is a star, not a graph. Contacts hang off one Account by design, which keeps reporting simple and ownership obvious. ACR is the escape hatch for the real world. Once enabled, the Contact's related list shows every Account it touches and every Account's related list shows every Contact that touches it, indirect ones included. Report Builder gains a fresh report type, custom report types can use the junction, and sharing for indirect Contacts is controlled separately from the primary affiliation. It is the difference between modelling people who happen to work somewhere and modelling people who participate in multiple revenue stories.

Account Settings is the Salesforce Setup page that controls organization-wide defaults for the Account object: whether Account Teams are enabled, whether Contacts can relate to multiple Accounts, whether Account Hierarchies display in the record detail, whether Account Insights surfaces engagement signals, and several smaller toggles for Account behavior across the platform. Changes here apply to every Account in the org and to every user who works with Account records. The page is one of the lower-traffic Setup destinations and often holds settings that were configured years ago and never revisited. Account Teams is the most consequential toggle (it adds an entire object relationship to the data model). Contacts to Multiple Accounts is the second (it changes how the Contact object behaves across Sales, Service, and Marketing). Most other settings are smaller, but the page deserves a quarterly audit because settings here cascade across the platform and quietly affect downstream automation when they drift from current business requirements.

An Account Team is a defined group of Users who collaborate on a single Account in Salesforce. Each team member has a role (Account Manager, Executive Sponsor, Channel Sales Manager, Lifecycle Manager, Pre-Sales Engineer, Sales Manager, Sales Rep, or any custom role your org adds) and a set of access levels on the Account and the related Opportunities, Contacts, and Cases. Account Teams give selling organizations a way to model who actually works a deal beyond the single Account Owner field, and they give the platform a way to share visibility automatically rather than through manual sharing buttons. The point of an Account Team is to stop the most common sharing-rule workaround in Salesforce. Without teams, granting visibility on an Account to anyone other than the Owner requires either expanding the Role Hierarchy, building Account-specific sharing rules, or hitting the manual Share button on every record. Each of those has costs. Role-Hierarchy changes affect every Account in the org. Sharing rules require criteria that you have to maintain. Manual sharing breaks the moment ownership changes. Account Teams sit in the middle: they grant access record-by-record but in a structured way that survives Owner transfers and is easy to report on. For enterprise sales orgs with named-account books, Account Teams plus a clear role taxonomy beats the alternative of dumping everyone into the manual sharing button.

An Account Team Member is a row on the AccountTeamMember object that grants a Salesforce user access to a specific Account in a named role, separate from ownership. The Account itself has one owner, but a real sales pursuit usually involves more people: an account executive, a sales engineer, a customer success manager, a technical architect, a renewals rep. Each of those people gets added to the Account Team with a Team Member Role and an Account Access level. The role is a descriptive picklist. The access level is the practical permission, the same Read Only, Read/Write, or Private scale used in standard Account sharing. One Account can have many Team Members. One user can sit on many Account Teams. Account Teams are the lightweight alternative to writing sharing rules for every cross-functional user. Sharing rules work well for static populations like a region or vertical. They fall apart for dynamic teams where the admin does not know in advance which SE will be on which deal. Account Teams shift that decision down to the rep who owns the Account, who can drag teammates in or out as the pursuit evolves. Default Account Team templates speed this up further: every new Account a user owns automatically inherits their default team, so the standard cast appears on day one.

An Action Layout controls which fields appear inside a single quick action and how they are ordered when a user invokes that action from a record. It is the per-action equivalent of a page layout. When an admin creates a Create-a-Task quick action on Account, the Action Layout decides which Task fields the user sees in the popup, which are required, and in what order. The Action Layout is distinct from the Lightning Page Layout (which decides where the action button itself appears on the record). Action Layouts exist because quick actions are essentially mini record-create or mini record-update forms inside a popup. Without per-action control over the fields shown, every action would inherit the full object's page layout, which is usually overwhelming for a quick task. Action Layouts let admins surface only the fields the action needs (Subject, Due Date, Comments for a Create-a-Task action) and skip the dozens of other Task fields that would clutter the popup.

An Action Link Template is a reusable definition of an Action Link, which is a clickable button or link rendered on a Chatter feed item that triggers a pre-configured action. Action Links themselves can invoke a REST API call, open an external URL, download a file, or initiate an OAuth-protected request. Without a template, each Action Link has to be defined inline whenever code creates a feed item, which makes them tedious to use at any kind of scale. The template stores the action's type, endpoint, HTTP method, body, headers, button labels, and user visibility in Setup. Code that creates a feed item references the template by ID, and Salesforce instantiates the actual Action Link from it. Action Link Templates exist because most integrations that surface a clickable button in Chatter generate the same shape of post many times over. A procurement workflow posts Approval requested to Chatter and every approver should see Approve and Reject buttons. Hard-coding the URL and request body into every post is fragile and clutters integration code. The template centralises that definition, supports placeholder bindings that get substituted at post time, and version-controls the action so a single change in Setup updates every future feed item that references it.

An Action Plan is a Salesforce object that bundles a set of related Tasks under a single parent record (an Account, Opportunity, Lead, Case, or one of the Industries-specific objects like Financial Account, Insurance Policy, or Visit) so the work can be tracked and reported as one engagement. Each Task in the Action Plan carries a due date offset from a starting point, an owner, a priority, and a status. The pattern is born from the realisation that any meaningful interaction with a customer is not a single Task but a sequence: send the welcome packet, schedule the kickoff call, confirm the verification documents, deliver the first review. Wiring those steps together as separate Tasks loses the connection between them. The Action Plan keeps the sequence visible, owned, and reportable. Action Plans are produced from Action Plan Templates. The template defines the standard set of Tasks and their offsets. Applying the template instantiates a real Action Plan with real Task records assigned to real people. The feature originates in Financial Services Cloud and spread to Public Sector Solutions, Health Cloud, and broader Sales Cloud via Action Plans for Sales. The mechanics are largely the same across editions, with differences mainly in which standard objects are supported as the Action Plan target.

An Action Plan Template is a reusable Salesforce definition that lists the Tasks (or Item Templates) that should run together as one engagement, along with the relative due dates, default owners, and priorities for each step. Applying the template to a parent record (an Account, Opportunity, Case, Financial Account, Insurance Policy, or whichever object is supported by the relevant cloud) creates a fresh Action Plan with real Task records that respect the template's design. Without the template, every team member has to rebuild the same sequence of Tasks from memory on every engagement. With it, the playbook stays in Setup and the operational work stays consistent. The template is where the real process design happens. Editors choose which Tasks belong, define each Task's offset from the plan start date, assign a default owner (or owner role, like Account Owner or Account Manager), and set per-Task priority and reminder flags. Templates can be cloned for variants, versioned, and shared across business units. They are the artifact that internal trainers, RevOps, and customer success leaders argue about; the resulting Action Plans are simply the realisation of that argument on a specific customer.

An Action Strategy is a visual flowchart, built in the Strategy Builder canvas, that decides which Recommendation records to surface to a user at a given moment. The strategy takes context as input (the current record, the user, business rules, model scores) and runs through a series of nodes that load, filter, branch, enhance, and rank Recommendations before returning the final list to a Next Best Action component on a Lightning page or to a Flow. Filters use the standard formula language. Branches use If conditions. Predictive nodes call Einstein Discovery models with a single click. Action Strategies sit at the centre of Salesforce Einstein Next Best Action. They are how a static list of possible offers (Recommendations stored in a custom object) becomes a personalised, ranked, contextual prompt on the record page. A bank uses one to suggest Open a Certificate of Deposit or Schedule Retirement Review on the Person Account based on age, balances, and recent activity. A retailer uses one to suggest service upgrades after a support case. The strategy is the brain; the Recommendation records are the menu.

Actionable Relationship Center (ARC) is a Salesforce Industries feature that renders the network of records around a focal point, typically an Account, Contact, or Household, as an interactive visual graph and lets users act on those records without leaving the visualization. ARC is configured per object via ARC Relationship Graph metadata, where admins choose which related objects to display, which fields to show inside each card, and which Quick Actions to expose. The result is a single canvas where a banker can see the household, the family members, the joint accounts, and the recent service cases on one screen, and create a referral or open a new product without clicking through three layouts. ARC shipped first in Financial Services Cloud, where modelling household relationships is the bread-and-butter of the cloud, and expanded into Health Cloud, Consumer Goods Cloud, and the broader Industries family. It replaces the older Relationship Tab and Relationship Map components. Underneath, ARC reads the ARC Graph metadata to traverse junction objects, Account Contact Relationships, and lookup fields in any direction, including reverse lookups. The visualization stays interactive and the actions stay one click away; both pieces are why the feature carries the word Actionable in its name.

An Actions and Recommendations deployment is a Lightning component in Salesforce Service Cloud that gives service agents one ranked panel of next steps for the record they have open. It combines quick actions, macros, screen flows, Knowledge actions, and Einstein Next Best Action recommendations in a single list, so agents stop hunting through sub-tabs to find the right move. Admins build a deployment in Service Setup, pick the channels and record types it serves, then drop the Actions and Recommendations Lightning component on the case, work order, or messaging session record page. Without an active deployment for that channel, the panel renders empty. The recommendation slot is the only slot wired to an external strategy. Everything else is configured directly on the deployment record itself.

Activation in Salesforce is the explicit step that takes a configured artifact (a Flow, a Price Book, a Permission Set, a Workflow Rule, a Process Builder process, a Validation Rule, a User record) from a built-but-inactive state to a live state where the platform enforces or executes it. Many Salesforce artifacts ship with an Active flag that defaults to off; the admin builds, tests, then activates when ready. Activation is the gate between configuration time and runtime behavior. The pattern is consistent across the platform but the activation mechanism varies per artifact. Flows have a Version Activate button. Permission Sets have an Activate Users link to assign them. Validation Rules have an Active checkbox. Price Books have an Active checkbox. The unifying property is that an inactive artifact does not affect production behavior, and an active one does. Activation is one of the most consequential single clicks an admin makes; the artifact moves from sandbox-quality experiment to production-affecting rule the moment the box is checked.

In Salesforce Data Cloud, an Activation is the published delivery of a segment of unified profiles to a downstream destination, such as Marketing Cloud Engagement, Google Ads, Meta Ads, an Amazon S3 export, or another connected system. An Activation specifies which segment to send, which attributes to include in the payload, which channel to push to, and on what schedule the publish should run. Activations are the bridge between the unified data graph inside Data Cloud and the channels that act on it. Without an Activation, a segment is a query result that nobody downstream can use. Activations were called Activation Targets in early Customer Data Platform releases and got renamed when CDP merged into Data Cloud. The feature has steadily gained more destinations and richer payload controls. Each Activation runs through a configured Activation Target (the destination connector) and an Activation Schedule (one-time, recurring, or change-triggered). The published payload typically includes a unique identifier suitable for the destination, an email hash for ad platforms, a contact key for Marketing Cloud Engagement, or a record ID for sales platforms, along with whichever profile attributes the destination needs for personalisation.

An Activity in Salesforce is a Task or an Event tracked against another record. Tasks are to-dos with a due date (a callback, a follow-up email, a contract review). Events are calendar items with a start and end time (a discovery call, a customer demo, an onsite meeting). Both attach to a Lead or Contact through the WhoId field and to an Account, Opportunity, Case, or custom object through the WhatId field. Together they form the historical record of what your team did with each customer. Activity is one of those Salesforce concepts that does not behave the way the documentation suggests. There is no Activity object you can query directly; you query Task and Event. There are two read-only views called OpenActivities and ActivityHistory that surface Tasks and Events together on a parent record, and they are how the Activity Timeline on Lightning records gets built. When somebody on your team says "the Activity object," what they usually mean is "the polymorphic Activity behavior that spans Task, Event, Email logging, and Logged Calls." That distinction matters once you start writing reports or triggers, because both halves of the abstraction have separate metadata, separate field history, and separate permissions.

Activity History is the Salesforce term for the related list and the Past Activity section of the Lightning Activity timeline that shows every completed Task, logged call, sent email, and past Event associated with a record. It is the read-only counterpart to Open Activities. The two sections together form the complete activity record of a Lead, Contact, Account, Opportunity, Case, or any object with the Activities related list enabled. Users open Activity History to answer what did we do, when, with whom, and what happened. Every customer-facing interaction that has been logged appears there in reverse chronological order. In Lightning Experience, the classic related list evolved into the Activity component on the right rail of every record page. Past Activity (the modern Activity History) and Upcoming & Overdue (Open Activities) sit side by side as tabs. The underlying data is the same: closed Tasks where Status equals Completed, sent emails (when Email-to-Salesforce or Outlook/Gmail integration is in use), and Events whose end date is in the past. The Salesforce mobile app renders the same data in a stacked timeline. Reporting still uses the Task and Event objects directly through the standard Tasks and Events report types.

Activity Settings is the Salesforce Setup page that controls organization-wide behavior for Tasks and Events: whether Shared Activities is enabled (allowing a Task or Event to relate to multiple Contacts), whether users can relate Events to multiple people, whether activity reminders default on or off, and several smaller toggles affecting how the platform manages the Task and Event objects. Changes apply to every Task and Event across every user, every record, and every integration that creates activities. The page is one of the lower-traffic Setup destinations and holds settings that meaningfully shape how the org's data captures relationships and follow-up. Shared Activities is the most consequential toggle; enabling it changes the data model permanently because once activities are related to multiple contacts, the data cannot be cleanly reverted. Most other settings are easier to change but still affect downstream automation, reporting, and the Activity Timeline experience users live with daily.

An Add-on in Salesforce is a licensed product that extends the functionality of a base edition (Sales Cloud, Service Cloud, Experience Cloud, Marketing Cloud, and so on) without requiring an edition upgrade. Add-ons are sold separately at a per-user-per-month price and turn on additional features, objects, permission set licences, and APIs that the base edition does not include. Common examples include Sales Cloud Einstein, Sales Engagement, Inbox, Service Cloud Voice, Salesforce CPQ, Salesforce Maps, and Field Service. Add-ons are how Salesforce monetises advanced capability without forcing every customer to upgrade their whole edition tier. Add-ons differ from AppExchange managed packages in one important way: they are Salesforce-built first-party products that integrate natively with the core platform's UI, permissions, and data model. They show up in Setup as if they were part of the platform, ship with their own Permission Set Licences (PSLs), and often add tabs, objects, and entire Lightning apps. Customers usually activate an add-on through a provisioning step at the contract level, after which an admin assigns the new PSL and permission sets to the users who need the feature.

A Salesforce Administrator, also called a System Administrator or Admin, is the person who owns the configuration, customization, security, and ongoing health of a Salesforce org. The role spans user management (provisioning, deactivation, permission set assignment), data model changes (adding fields, building objects, configuring page layouts), automation (Flows, Validation Rules, Approval Processes), reporting (dashboards, list views, reports), security (sharing rules, profile management, IP restrictions), and integration oversight (managed package installs, connected app reviews, sandbox refreshes). The Administrator is typically the most-titled but least-glamorized Salesforce role. The work compounds over time; choices made today (a field naming convention, a sharing model design, a profile vs permission set decision) determine how easy or how painful every later change becomes. Most orgs have at least one Administrator; mid-size and enterprise orgs typically have several with specialized focus (Sales Cloud admin, Service Cloud admin, integration admin, security admin). The Certified Administrator credential validates the foundational skill set.

An Advanced Function in Salesforce is a category of sophisticated formula or analytical operation used in reports, dashboards, CRM Analytics, and Tableau Cloud that goes beyond basic arithmetic and aggregation. Advanced Functions include windowing operations (running totals, moving averages), comparison functions (percent of total, percent difference between rows), summary-row references (PARENTGROUPVAL, PREVGROUPVAL), and statistical operations (standard deviation, regression, percentile). The term covers two distinct surfaces in Salesforce. In the standard Reports & Dashboards module, Advanced Functions appear as summary formulas that operate across grouped data: percent of total within a grouping, year-over-year deltas, running balances. In CRM Analytics and Tableau, Advanced Functions are expressed in SAQL (Salesforce Analytics Query Language) or in Tableau's calculated-field syntax, supporting an even broader set of analytical operations like cohort analysis, custom percentile bands, and time-series decomposition. Mastering Advanced Functions is what separates a basic report builder from someone who can answer business-strategy questions with self-service analytics.

Advanced Search in Salesforce is the search experience that exposes object-specific filters, multi-criteria text matching, and configurable field scope beyond the simple top-bar global search. In Lightning Experience, it shows up as the All Objects search results page where users can scope to one object, apply field-level filters, narrow by owner or date, and re-sort results. In Salesforce Classic, Advanced Search was a separate dialog with explicit filter rows. Both UIs run against the Salesforce search index, the same index used by global search, with the same tokenisation rules and the same field-level visibility checks. Advanced Search matters because the global search shortcut gets users to the right ten records, while Advanced Search gets them to the right one. The simple text box in the header runs a fuzzy match across searchable fields on every searchable object. That works fine for I know the Account name but breaks down on I need the Account in California with a renewal in March owned by Maria. Advanced Search exposes the additional filters that let users narrow exactly that case without leaving the search experience to build a list view.

After Conversation Work (ACW) is a configurable period in Salesforce Omni-Channel where service agents are protected from new work assignments immediately after a customer interaction ends, giving them dedicated time to complete wrap-up tasks: writing notes, updating case fields, setting follow-up tasks, dispositioning the conversation, capturing learnings. ACW is part of the Omni-Channel routing engine and applies across the channels Omni-Channel handles: voice calls through Service Cloud Voice, chats through Live Agent or Messaging for In-App and Web, cases assigned through Omni-Channel. ACW is one of the unglamorous but operationally critical configurations in any service center deployment. Without ACW, the routing engine assigns the next work item the moment the agent ends a call or closes a chat, with no time to capture what happened. Agents either rush the wrap-up (producing poor case data) or refuse new work (looking like they are stalling). With ACW, the agent has a defined window for wrap-up, the routing engine knows the agent is busy, and the case data quality stays high because the agent has time to do the documentation properly.

Age in Salesforce is a calculated metric showing how long a record has been in an open or active state. The most common form is days since a record was created (or since it last changed state, depending on the implementation), expressed as a number that grows over time until the record is closed. Age applies to many objects: Case Age (days since the case was opened), Opportunity Age (days since the opportunity was created or since it entered the current stage), Lead Age (days since the lead was captured), Task Age (days since the task was created without completion). Age is the workhorse metric of operational reporting because it surfaces records that need attention. A Case open for 30 days indicates a customer waiting longer than the team's SLA; a Lead untouched for 14 days indicates marketing-to-sales handoff friction; an Opportunity sitting at 45 days in the current stage indicates a stalled deal. Mature operations teams build dashboards around Age across every relevant object, with thresholds that trigger workflow, alerts, or escalation when records exceed their expected lifecycle duration. Without Age tracking, stale records accumulate invisibly and the team loses the ability to manage workload effectively.

In Salesforce, an Agent is the licensed user who works incoming customer interactions in Service Cloud: cases, chats, voice calls, messaging conversations, and email-to-case threads. Agents sit inside the Service Console, accept work routed to them by Omni-Channel, and resolve each interaction against the customer's account history. The role is the operational heart of Service Cloud. Almost everything Salesforce ships for service organisations (Knowledge, Macros, Service Routing, Einstein Reply Recommendations, the Service Console itself) is designed to make Agent work faster and more accurate. The same word picked up a second meaning when Salesforce launched Agentforce, where an Agent is an autonomous AI worker built on the Atlas Reasoning Engine that handles tasks end-to-end without a human seat. Agentforce Agents share the routing and audit surfaces with human agents but execute through LLM reasoning, a configured set of Topics and Actions, and instructions written by a builder. Most Salesforce orgs in 2026 use both kinds. Human Agents handle the cases that need judgement; Agentforce Agents handle volume that follows a known playbook. The platform UI uses the word Agent for both, and the distinction lives in the agent type field.

An Agent Action is one discrete capability an Agentforce agent can take during a conversation, such as running an Apex method, executing a flow, calling a prompt template, searching a Data Library, or invoking a built-in record action. Each Agent Action carries a name, a natural-language instruction that tells the Atlas Reasoning Engine when to use it, an input schema, and an output schema. Agentforce agents do nothing on their own without actions. When a user sends a message, the reasoning engine compares the message against the instructions on every Agent Action available to the agent's active topics, picks one or more, and executes them. Actions live inside Agent Topics, which group related skills into recognizable buckets like Order Lookup, Returns, and Account Updates.

Agent Builder is Salesforce's no-code design tool for creating, configuring, and testing Agentforce AI agents. It is the Setup-based UI inside Agent Studio where admins define an agent's purpose, build its topics, wire up its actions, configure grounding, and validate behavior through a built-in conversation playground. Agent Builder is to Agentforce what Flow Builder is to Flow: the primary author-time surface. The tool exposes the entire agent definition through a visual interface. Topics appear as cards with their descriptions and action lists. Actions show their parameters, return values, and behavior descriptions. The Conversation Playground lets you type realistic user inputs, see which topic the reasoning engine selects, watch which actions fire, and read the generated response. This iterative loop (edit, test, refine descriptions) is the daily workflow of agent design. Agent Builder is the only way to design Agentforce agents without writing direct metadata; while metadata-API workflows exist for advanced use cases, most agents are built end-to-end in Agent Builder.

Agent Capacity in Salesforce Omni-Channel is the cap on how much work a service agent can handle at the same time. Each agent gets a numeric capacity from a Presence Configuration, and each work item (case, chat, voice call, messaging session) gets a capacity weight from its Routing Configuration. Omni-Channel adds up the weights of an agent's open work, compares the total against the agent's capacity, and only routes new items when there is room. The model is designed to mix work types by cognitive load instead of counting raw items. A voice call that demands focus can weigh 5, while an email might weigh 1. The same agent with a capacity of 10 could handle one call plus five emails, or two calls flat, but never both a third call and an email at once. Three records own this behavior: Presence Configuration sets agent capacity, Routing Configuration sets per-item weight, and Service Channel maps each weight to the underlying object.

The Agent Console is the multi-pane Salesforce Classic UI designed for service representatives to work cases efficiently. It splits the screen into a list view (top left), a detail view (top right), and a related-records mini-view (bottom) so an Agent can scan a queue, open a case, and review the parent Account or Contact without leaving the page. The Console preceded Lightning Experience and was the original answer to how do we make Service Cloud reps faster than the standard one-record-at-a-time UI. It also introduced tabbed navigation for case work, where each open case becomes a primary tab and related records open as sub-tabs. Most Salesforce orgs moved off the Classic Agent Console to the Lightning Service Console between 2018 and 2022. The Lightning Service Console retains the multi-tab idea but uses Lightning Components, supports Utility Bars, integrates Omni-Channel natively, and offers richer customisation through App Builder. New orgs no longer receive the Classic Agent Console; it remained available as a backwards-compatibility surface for orgs that had not migrated. Documentation now treats Agent Console as a legacy term and points to the Lightning Service Console for current implementations.

An Agent Topic is the skill group inside Agentforce that organizes related Agent Actions and tells the Atlas Reasoning Engine when to consider them. Each topic has a name, a classification description that defines which user messages fall under this skill, an agent instruction that shapes response style, and an attached set of actions that can be invoked when the topic is active. Topics let the reasoning engine narrow the search space. Without topics, the engine would have to evaluate every action against every message, which destroys latency and accuracy. With topics, the engine first classifies the message into one topic (or rejects it as out of scope), then only considers that topic's actions. The result is predictable behavior even as the action library grows past a hundred entries.

Agentforce is Salesforce's platform for building, deploying, and managing AI agents that take action on the platform's data and processes. Launched in 2024 and rapidly evolving, it is the centerpiece of Salesforce's AI strategy: not just generative chatbots that answer questions, but autonomous agents that can read records, run Apex, send emails, create Cases, update Opportunities, and chain multi-step actions. Salesforce positions Agentforce as the third wave of platform automation after declarative tools (Flow) and code (Apex). An Agentforce agent has three pieces: topics (the categories of questions or jobs it handles), actions (the things it can do, like Apex methods, Flow invocations, REST calls, or other agents), and a backing large language model that decides which actions to invoke based on the user's input and conversation context. Agents run in conversational interfaces (Slack, Salesforce Mobile, Experience Cloud sites, embedded chat) and in headless contexts triggered by events. The Atlas Reasoning Engine routes user requests to the right topic and chooses the right action. Agentforce is licensed separately and consumes credits per interaction.

Agentforce Agents are the autonomous AI workers built on Salesforce's Agentforce platform that can hold a conversation with a customer or employee, decide which actions to take, execute them against Salesforce records or external systems, and respond grounded on real org data. Each Agent is a configured combination of Topics (what the agent can talk about), Actions (what it can do), Instructions (how to behave), Channels (where it runs), and Grounding sources (where its facts come from). Agents are the deployable unit of work on Agentforce. The Agent runs on a large language model (Atlas Reasoning Engine, GPT, or another supported LLM) constrained by the Topics and Instructions an admin defines in Agent Builder. When a customer message arrives, the Agent decides which Topic best matches, picks Actions to fulfill the request, calls those Actions, returns a grounded response. Agents differ from Einstein Bots (the older Dialog-based chatbot product) in being LLM-driven rather than dialog-tree-driven, capable of handling novel utterances the admin never explicitly scripted, and able to chain Actions autonomously. They are the strategic direction for conversational AI in Salesforce.

Agentforce Assets are the metadata building blocks used to define, configure, and deploy an Agentforce agent. The asset family includes Agents (the top-level autonomous agent definition), Topics (the bundled groupings of intent and instruction that scope what the agent can handle), Actions (the discrete operations the agent can invoke, like creating a record or calling a flow), Prompt Templates (the structured instructions the agent uses for generative responses), and Permissions and Channels (where the agent runs and what data it can touch). Each asset is a Salesforce metadata record with its own object, lifecycle, and packaging behavior. Asset-based composition is what distinguishes Agentforce from a one-off prompt or a single chatbot script. The same Action can be reused across Topics, the same Topic can be reused across Agents, and the same Prompt Template can ground multiple Actions. Reuse means an Agentforce deployment scales as a metadata project, not a copy-paste script collection. The trade is operational: agent assets must be governed, version-controlled, and deployed through Salesforce DevOps practices, not built informally in production.

An Agentforce Data Library is a managed knowledge store inside Salesforce that holds unstructured content (Knowledge articles, files, web pages, uploaded documents) and serves it back to Agentforce agents through retrieval-augmented generation. The library chunks each piece of content, embeds the chunks into a vector index, and exposes a Data Library Search action that the Atlas Reasoning Engine can call to ground its answers in trusted source material. Without a Data Library, an Agentforce agent answers from the underlying LLM's training data plus whatever record data the actions pull. That works for transactional questions like order status. It fails for policy or how-to questions where the right answer lives in a PDF or a Knowledge article. The library closes that gap. Each library is scoped to a specific topic or audience, so a Returns library and a Pricing library can coexist on the same agent without bleeding context.

Agentforce for Sales is the Salesforce Agentforce SKU that ships two pre-built agents grounded in Sales Cloud data: the Sales Development Representative (SDR) Agent and the Sales Coach. The SDR Agent handles inbound and outbound prospecting (researching accounts, drafting first-touch emails, qualifying leads, proposing meeting times). The Sales Coach reviews opportunities in flight and gives reps next-best-action coaching tied to the deal's stage, history, and signals. Both agents run on the Atlas Reasoning Engine and use Agent Actions that read and write Sales Cloud records (Account, Lead, Opportunity, Contact, Task, Event). They ship with standard topics admins can customize: Account Research, Meeting Prep, Opportunity Health, Email Drafting, Pricing Questions. Agentforce for Sales is licensed per conversation, not per user, so the cost model scales with activity rather than seat count.

Agentforce for Service is the Salesforce Agentforce SKU that ships two pre-built agents grounded in Service Cloud data: the customer-facing Service Agent and the rep-facing Service Coach. The Service Agent answers customer questions on Messaging, Web Chat, Slack, WhatsApp, and SMS, handling FAQs, order lookups, status checks, and basic record updates without a human in the loop. The Service Coach sits beside a live agent and offers reply drafts, case summaries, Knowledge suggestions, and next-step recommendations. Both agents run on the Atlas Reasoning Engine and use Agent Actions that read and write Case, Contact, Asset, Knowledge Article, Order, and the various messaging objects. They ship with standard topics admins customize per industry: Order Status, Returns, Account Updates, FAQ Lookup, Escalation. Agentforce for Service is licensed per conversation. The customer-facing Service Agent's conversations are the primary cost driver in most deployments.

The Salesforce Agentforce Specialist Certification is the credential for designing, building, and deploying AI agents on Agentforce, Salesforce's autonomous agent platform. Launched in 2024 alongside the Agentforce product, it validates hands-on skill with Agent Builder, prompt templates, action design, grounding with Data Cloud, and the Einstein Trust Layer. The cert is the natural next step for someone holding AI Associate who wants to actually build AI agents rather than just understand AI concepts. The exam is 60 multiple-choice questions, 105 minutes, currently $200 USD, with a 73% passing score. It is hands-on rather than conceptual; expect scenario questions where you choose the right action type, grounding source, or testing strategy for a given customer use case. Pass rates are lower than AI Associate (around 50-60% on first attempt) because the questions test real configuration decisions rather than definitions. The cert pairs naturally with hands-on Agent Builder experience in a Developer Edition org plus the official Agentforce Specialist Trailmix.

Agentforce Studio is the dedicated Setup-area workspace inside Salesforce for designing, configuring, testing, and deploying Agentforce Agents. It bundles Agent Builder (the agent configuration UI), Prompt Builder (the prompt template editor), Model Builder (where admins configure which LLM each agent uses), the Agentforce Testing Center (synthetic conversation testing), and an agent monitoring dashboard. Studio is the umbrella experience that ties every Agentforce configuration tool together so admins do not have to jump between disjoint Setup menus. Studio is where the entire agent lifecycle happens. Admins start in Agent Builder to define Topics and Actions, drop into Prompt Builder to author prompt templates, use Model Builder to pick the LLM (Atlas Reasoning Engine, GPT, or another supported model), test in the Testing Center, and monitor production performance from the dashboard. The integrated workspace reduces the friction of building agents compared to the early Agentforce releases where each tool lived in a separate Setup area. It is the workbench, not a runtime product.

Agentforce Testing Center is the regression testing tool for Agentforce agents. It lets admins capture conversations as test cases, save them into reusable test sets, and run those sets against the agent on demand or after every change. Each test case records the expected topic classification, the expected actions fired, and the expected response style, then compares actuals against expecteds to flag drift before the change reaches users. Testing Center is the only way to know that fixing one topic did not break two others. Editing a topic's classification description, a Data Library scope, or a Prompt Template can change agent behavior on conversations you did not have in mind. Without a saved test set, the team only learns about regressions from customers or supervisors. Testing Center turns that feedback loop into seconds inside Setup rather than days in production.

Agentforce Vibes Extension is a Visual Studio Code extension that brings the Agentforce Vibes coding agent into a developer's existing editor without forcing them to switch to a separate IDE. It surfaces the same code generation, refactor, test writing, and metadata-aware autocomplete capabilities that the standalone Agentforce Vibes IDE offers, installed as a plugin alongside the Salesforce Extensions Pack and any other VS Code tooling a developer already uses. The extension authenticates against a Salesforce org and reads the org's metadata schema, so suggestions for Apex, LWC, Flow, and metadata files are grounded in actual sObjects, fields, and code in the target org rather than generic templates. A developer can chat with the agent, ask for a code change, accept or revise the diff, and have the agent run tests against the change before commit. The extension is the lighter-touch entry point to Vibes for teams that have standardized on VS Code.

Agentforce Vibes IDE is the standalone Salesforce-tuned development environment built around the Agentforce Vibes coding agent. It packages a code editor, multi-agent orchestration, project-level deployment pipelines, and a tight loop with Agent Builder into one application aimed at teams that operate the full Salesforce development cycle (write, test, deploy, review) through an AI-augmented workflow rather than a per-file assistant. The IDE is the heavier counterpart to the Agentforce Vibes Extension for VS Code. Both share the same metadata-aware completion engine, the same authentication model, and the same Einstein Trust Layer. The IDE adds capabilities that do not fit a single-editor extension: a draft-and-review multi-agent flow where one agent generates code and another reviews it before commit, native CI integration for sandbox deploys, and the ability to edit Agent Builder topics and actions from the same window as the Apex code those agents call.

An AI model is a trained mathematical function that takes inputs (data, text, images, audio) and returns predictions, classifications, embeddings, or generated content. In the Salesforce context, AI models power Einstein features (case classification, prediction builder, opportunity scoring), Agentforce reasoning, Data Cloud identity resolution, and Tableau forecasting. Some models are Salesforce-managed and shared across the platform; others are customer-trained on the customer's own data; still others are third-party models accessed through brokered connectors. The model is the artifact that gets trained, evaluated, deployed, monitored, and retired. Each phase has its own concerns. Training needs representative data and protected labels. Evaluation needs metrics that match the business goal, not just academic accuracy. Deployment needs governance around who can call the model and what data flows through. Monitoring catches drift before users complain. Retirement is the part that gets neglected and produces models in production no one remembers training.

The AJAX Toolkit is the JavaScript library Salesforce historically provided so client-side code could call the SOAP API and Apex web service methods directly from the browser. It exposed an sforce.connection object that wrapped login, query, create, update, delete, and Apex web service calls, returning JavaScript objects that pages could render or manipulate. The toolkit shipped as connection.js and apex.js and was loaded from a /soap/ajax/<version>/connection.js URL inside any Visualforce page or S-Control. Developers used it to build server-aware behaviour into Classic pages before Lightning Components or LWC existed. The AJAX Toolkit is firmly legacy. Salesforce has not added new features to it in over a decade, and the underlying SOAP API path it depends on is itself in maintenance mode. Modern Salesforce code calls the REST API, the User Interface (UI) API, or invokes Apex through @AuraEnabled methods on Lightning Components. The toolkit still loads on Classic surfaces and continues to work in older orgs, but new development is strongly discouraged. Most enterprise orgs have migrated their remaining AJAX Toolkit code as part of the Lightning Experience migration; what remains usually sits inside long-tail Visualforce pages that nobody has rewritten yet.

All Sites is the Setup page in Salesforce Experience Cloud that lists every Experience Cloud site (formerly called a Community) configured in the org. The page is the entry point to Experience Builder, Workspaces, the URL configuration, and the activation toggle for every site. Admins land on All Sites to create a new Experience site, edit the navigation and theme of an existing one, manage member access, or take a site offline for maintenance. It is to Experience Cloud what the App Manager is to internal Lightning apps: the single starting point for site-level work. The page lives under Setup, Digital Experiences, All Sites. Older orgs may still see the navigation labelled Communities depending on when the rebrand from Salesforce Communities to Experience Cloud was applied. Each row on the page shows the site's name, status (Active or Inactive), URL, and the template the site is built on (Customer Service, Partner Central, Build Your Own LWR, Help Center, and so on). The Workspaces link beside each row opens the per-site dashboard for content moderation, member management, and analytics. The Builder link opens Experience Builder, where the site's pages, components, and theme are designed.

Amazon Connect is AWS's cloud contact-center-as-a-service product, and it is the underlying telephony platform that Salesforce Service Cloud Voice was originally built on. When a customer dials a Service Cloud Voice number, the call routes through Amazon Connect's PSTN gateway and speech-to-text pipeline, then surfaces in the Salesforce Service Console as a structured Voice Call record with live transcript and AI assistance. The Salesforce-AWS partnership turned Amazon Connect into a first-party telephony option for Salesforce customers without forcing them to manage AWS configuration directly. Salesforce sells Service Cloud Voice in three editions: with Amazon Connect (Salesforce owns the AWS configuration), Partner Telephony (the customer uses a separate telephony provider via the Voice Adapter framework), and Bring Your Own Amazon Connect (the customer owns their AWS account and Salesforce talks to it). The Amazon Connect edition remains the most common because it requires the least configuration on the customer's side. Service Cloud Voice rides Connect's IVR, queuing, recording, and transcription, plus Salesforce's CRM integration, agent UI, and Omni-Channel routing on top.

Amount Without Adjustments is the Collaborative Forecasts column that shows the forecast roll-up of opportunities in their unmodified state. It is the pure sum of Opportunity Amount values for opportunities in the relevant Forecast Category, before any forecast user (the owner or any manager up the role hierarchy) has applied an adjustment. It is the system-calculated baseline against which every adjustment is measured. In a forecast that has been edited five times by five layers of management, the Amount Without Adjustments column still shows what the underlying Opportunity records say at this moment. Forecasting in Salesforce works through a chain of judgements: opportunities roll up to the rep, the rep can adjust, the rep's manager can adjust on top of that, the manager's manager can adjust again. At each layer, the displayed forecast can drift from the underlying data because of those adjustments. The Amount Without Adjustments column strips every layer away and shows just the opportunity roll-up. Sales operations and the CFO usually watch this column closely because it represents the underlying pipeline reality before judgement calls were layered on. The number is also what most forecast accuracy retrospectives benchmark against, since adjusted forecasts move targets while the un-adjusted number stays anchored to the data.

Amount Without Manager Adjustment is the Collaborative Forecasts column that shows a forecaster's number with the owner-level adjustment included but with every manager-level adjustment stripped out. In plain terms, this is the forecast the rep submitted before any manager up the role hierarchy edited it. The column lets a manager see exactly what the rep is committing to, separate from any subsequent adjustments the manager (or the manager's manager) layered on top. The number is calculated row by row across the forecast period and per Forecast Category, just like Amount and Amount Without Adjustments, but with a different combination of adjustments applied. The column matters because Collaborative Forecasts supports multi-layer adjustments. A rep can override their own opportunity roll-up. Their manager can override that further. Their manager's manager can override that again. Amount, the headline column, reflects every applicable adjustment. Amount Without Manager Adjustment carves out the rep's adjustment but keeps the lower layer. It is the manager's audit view: what is my rep actually saying, before I touched their forecast? Most sales operations dashboards include this column alongside Amount Without Adjustments and the headline Amount to expose the magnitude and direction of adjustment at each tier.

Amount Without Owner Adjustment is the Collaborative Forecasts column that shows a forecaster's number with manager-level adjustments applied but with the owner's own (rep-level) adjustment stripped out. The column lets a sales operations analyst or executive see what the chain of managers thinks the forecast should be, separate from what the rep adjusted. Where Amount Without Manager Adjustment surfaces the rep's view, Amount Without Owner Adjustment surfaces the manager's view of the same underlying pipeline. The number is calculated row by row across the forecast period and per Forecast Category, just like the other Amount variants, with a specific combination of adjustments applied. The column exists because Collaborative Forecasts supports adjustments at multiple layers. A rep adjusts their own number. The rep's manager adjusts on top. The manager's manager can adjust again. The headline Amount column reflects every layer. Amount Without Owner Adjustment carves the rep's adjustment back out while keeping the rest. The result answers a specific question: if the rep had not touched their roll-up, what would the manager's view of the forecast look like? Operations teams use it to separate manager judgement from rep optimism (or rep sandbagging) and to attribute the chain of adjustments to the right person.

Analytics Groups in Salesforce reporting are the row and column bucket dimensions that turn a flat list of records into a Summary, Matrix, or Joined report. Adding an Analytics Group means picking a field whose values become the section headers, with each underlying record collapsing into its bucket. A report grouped by Stage shows one row per Stage with the underlying Opportunities folded inside. Grouped by both Stage and Owner, the same data becomes a matrix where one axis is Stage and the other is Owner. Groupings are the single most powerful tool inside the report builder; they convert raw row data into a story without writing a single formula. Outside of standard reports, the phrase Analytics Groups also appears in CRM Analytics (formerly Tableau CRM, formerly Einstein Analytics, formerly Wave) where Public Groups control who can see an Analytics App and the dashboards inside it. Both meanings share a common idea: bucket records or users into sets so the platform can apply behaviour at the bucket level rather than the individual one. Most documentation now uses the more specific phrases Report Groupings or Analytics App Sharing, but the umbrella term Analytics Groups still appears in older help articles and certification material.

An Annuity in Salesforce is a recurring-revenue product line that pays out the same amount on a regular cadence (monthly, quarterly, annually) for the life of the contract, rather than as a single up-front sale. In CRM terms, an Annuity Opportunity Product spreads its revenue over time through Revenue Schedules, with each scheduled installment landing in a specific period for forecasting. In the insurance industry sense (Financial Services Cloud Insurance), an Annuity is a contract between a customer and an insurance carrier that pays the customer a stream of income for a defined period or for life. Salesforce uses the same word in both contexts because the underlying revenue mechanics are similar: a base contract value plus a schedule of payments. Two distinct Salesforce surfaces handle Annuities. Opportunity Products in Sales Cloud support Quantity and Revenue Schedules for any product flagged as scheduled, and Annuity products are the canonical example. Financial Services Cloud (Insurance) and Salesforce Industries (Insurance) ship dedicated objects for annuity contracts, riders, beneficiaries, and payment history, with policy-management UI for advisors and claims teams. Most orgs use only one of the two surfaces depending on whether they sell annuities (FSC) or model recurring product revenue inside a broader CRM (Opportunity Products with Schedules).

An Anonymous Block in Apex is a piece of Apex code that runs once without being saved to the org as a class, trigger, or scheduled job. Developers run anonymous blocks to perform one-time tasks: cleaning up bad data, back-filling a new field on existing records, testing a snippet of logic, or initialising a Custom Setting. The block executes in the running user's context, with that user's permissions, sharing model, and governor limits. It does not persist after execution. Once the run finishes, the code is gone unless the developer copies it back into a class. Anonymous Apex runs from several surfaces: the Developer Console's Execute Anonymous Window (Ctrl/Cmd-E), VS Code via the Salesforce CLI command sf apex run, Workbench's Apex Execute tab, or the REST API's executeAnonymous endpoint. Each surface produces the same outcome but exposes different debugging affordances. The Developer Console shows logs and limits inline. The CLI dumps the log to disk and is the path most production scripts use. The REST API returns a structured success/failure payload that automation can parse. Use of anonymous blocks is common for data migrations, post-deployment fix-ups, and ad hoc support work.

An Anti-Join in SOQL is a query pattern that returns records from one object only when they do not have a matching record on a related object. The canonical example is finding Accounts with no Opportunities: SELECT Id, Name FROM Account WHERE Id NOT IN (SELECT AccountId FROM Opportunity). The outer query asks for Accounts; the inner subquery returns every Account that already has an Opportunity. The NOT IN clause subtracts the inner set from the outer. The result is Accounts that have never had an Opportunity attached. The opposite pattern, a Semi-Join, returns records that do have a match by using IN instead of NOT IN. Anti-joins are how Salesforce admins and developers answer negative-existence questions through SOQL alone, without writing Apex. Common business questions like which Accounts have no recent activity, which Leads have not been emailed, or which Cases lack a Knowledge attachment all translate cleanly into anti-join queries. Salesforce's query optimizer treats the pattern specially: there are stricter selectivity requirements on the inner query, and anti-joins on non-selective parents can fail with non-selective filter errors that selectively-matched queries would not.

Apex is Salesforce's proprietary, strongly typed, object-oriented programming language that runs on the Lightning Platform servers. It looks like Java syntactically but is purpose-built for the Salesforce environment: every script runs inside a transaction, every operation counts against governor limits, and the language has first-class support for SOQL queries, DML operations, and platform events without external libraries. Apex powers most of the custom logic in any production Salesforce org. Triggers fire Apex on record save events. Classes hold reusable business logic invoked from Lightning components, Flow actions, REST API endpoints, scheduled jobs, batch operations, and queueable jobs. Apex tests run in the same execution context as production code, with a 75 percent coverage requirement for deployment. Apex is the right tool when declarative automation (Flow, validation rules, formula fields) cannot express the logic, when bulk processing exceeds Flow's performance envelope, or when the integration pattern requires programmatic precision. Most Salesforce engineers spend the majority of their career writing, reading, and refactoring Apex.

An Apex class is a reusable container for Apex code, holding properties, methods, constructors, inner classes, and constants. It is the building block of every nontrivial Apex codebase. Triggers delegate to classes for the actual logic. Lightning components invoke class methods to fetch and update data. REST endpoints expose class methods to external systems. Scheduled and batch jobs implement specific class interfaces. Everything beyond the smallest one-liner lives inside a class. Apex classes look syntactically similar to Java or C# classes. They support inheritance with the extends keyword, interfaces with implements, generics for collections (List<Account>, Map<Id, String>), and a familiar set of access modifiers (public, private, global, protected). The runtime adds Salesforce-specific behavior: sharing context declaration (with sharing, without sharing, inherited sharing), governor limits, automatic JSON serialization for REST endpoints, and integration with the platform's caching, queueing, and async execution frameworks. Most Apex engineering work is class design: deciding what each class should know, what methods it should expose, and how classes compose into a maintainable system.

The Apex Connector Framework is the Salesforce extension point for Salesforce Connect that lets developers build custom data sources, exposing external systems as External Objects in Salesforce. When the built-in Salesforce Connect adapters (OData 2.0, OData 4.0, Cross-Org) do not fit, the framework lets a developer write Apex classes that respond to query, search, and DML callbacks from the platform. The result is an External Object that looks like any other Salesforce object but reads from (and optionally writes to) an arbitrary backend: a REST API, a SOAP service, a custom queue, a third-party database, anywhere the developer's Apex code can reach. The framework consists of two main base classes plus a set of provider interfaces. DataSource.Connection is the per-request connection that handles query, search, and DML operations. DataSource.Provider declares the connector's capabilities (whether it supports search, sync, write operations, OAuth refresh, and so on). The developer registers a Custom Adapter type in Setup pointing at the custom Apex provider, configures a Named Credential for authentication, creates an External Data Source referencing the custom type, then syncs External Objects from the data source. From that point on, External Objects appear in reports, lookups, and SOQL like any other Salesforce object.

An Apex Controller is a server-side Apex class that backs a Salesforce UI page, exposing methods that the front-end can call to load and persist data. The role of a controller is to bridge the UI runtime (Visualforce, Aura, or Lightning Web Components) and the Salesforce data model. Controllers are where the SOQL queries, DML operations, business logic, and platform integrations live, while the UI layer focuses on rendering and user interaction. The term means different things across the three UI frameworks. In Visualforce, a controller is a class declared on the page tag and tightly bound to the page lifecycle. In Aura, a server-side controller is a class with @AuraEnabled methods called from the client controller. In LWC, the same concept appears as an Apex class with @AuraEnabled methods wired through @wire or imperative calls. Across all three, the controller pattern is the same: a thin server-side class that exposes methods, enforces security, and returns data.

Apex Exception Email is a Salesforce Setup configuration that controls which email addresses receive notifications when an unhandled Apex exception fires in the org. By default, Salesforce sends the exception email to the user whose transaction caused the failure (or to the developer who last edited the failing class, depending on the context). The Apex Exception Email page lets administrators add additional recipients (an admin distribution list, a support team alias, a monitoring inbox) and to enable Salesforce User notifications for specific Salesforce users beyond the original trigger. The configuration sits at Setup, search for Apex Exception Email. The feature is the simplest production monitoring surface Salesforce offers. Every unhandled exception in Apex code produces a record in Apex Job Failures and, when configured, an outbound email with the stack trace, the failing class, the user who hit it, and the input that triggered the error. Most production orgs route the exception email to a shared engineering inbox or a chat-bot integration so failures are visible in real time. The configuration is also a useful early-warning signal during deployments; a sudden uptick in exception emails after a release usually means a regression worth investigating before users start filing tickets.

The Apex Flex Queue is the Salesforce holding queue for batch Apex jobs that have been submitted but not yet started. The platform runs up to five concurrent batch jobs per org; any batch class submitted while five are already running lands in the Flex Queue with a status of Holding. The queue holds up to 100 jobs at a time. Once a running slot opens, Salesforce promotes the next job in the queue to Queued status and the batch class begins execution. Without the Flex Queue, every System.LimitException for too many batch jobs would fail outright; with it, the platform smooths submission spikes into the available execution capacity. Beyond simple holding, the Flex Queue is a management surface for those waiting jobs. Setup, Apex Flex Queue lets administrators reorder Holding jobs, move a low-priority job to the back, promote an urgent one to the front, or cancel jobs that should not run at all. Reordering is the most-used capability: a long-running daily import suddenly becomes urgent and gets pulled to the top so it does not wait behind a hundred routine nightly maintenance jobs. The queue is per org and applies to every batch Apex job regardless of who submitted it.

Apex Jobs is the Salesforce Setup page that monitors every asynchronous Apex execution in the org: batch Apex, scheduled Apex, Future methods, and Queueable jobs. The page lives at Setup, Environments, Jobs, Apex Jobs and lists each job with its submitter, status (Holding, Queued, Preparing, Processing, Completed, Failed, Aborted), total batches processed, errors, start time, and elapsed time. For an admin investigating why an automation did not fire or a developer debugging a slow batch class, Apex Jobs is the first place to look. It is the operational dashboard for async Apex. The Apex Jobs page is backed by the AsyncApexJob standard object, which is queryable through SOQL. The same data flows into the Apex Flex Queue page (which scopes to Holding status), into custom monitoring dashboards built on AsyncApexJob, and into Setup, Scheduled Jobs (which scopes to cron-driven jobs). Most production orgs build a dashboard or report on top of AsyncApexJob to surface failure trends, average run times, and stuck jobs across the entire async surface, since one Setup page rarely keeps up with the operational scale of a busy org.

Apex Page is the metadata-API name for what most Salesforce users call a Visualforce Page. The Metadata API type is ApexPage, the file extension is .page, and the matching Apex controller is an ApexClass. The two together (the .page markup and its controller) implement a custom Salesforce-hosted web page that runs inside the platform. Apex Pages were the primary way to build custom UI inside Salesforce from 2008 through roughly 2018, when Lightning Components and Lightning Web Components replaced them as the recommended UI surface. The metadata type still exists, the pages still render, and large enterprise orgs typically retain dozens to hundreds of them through any Lightning migration. The markup language inside an Apex Page is Visualforce, a JSP-style tag library that includes Salesforce-aware components like apex:pageBlock, apex:repeat, apex:inputField, and apex:commandButton. Components bind to controller properties through expression syntax ({!Account.Name}), which evaluates against the Apex controller class associated with the page. Pages can be standard-controller-driven (use the platform-provided controller for an object), custom-controller-driven (use a developer-written class), or both via a controller extension. Most surviving Apex Pages serve niche use cases that Lightning never quite replaced: PDF generation, email templates, public Sites pages, and tightly customised quote or invoice surfaces.

Apex Settings is the Salesforce Setup page that controls org-wide behavior of the Apex runtime. It governs how the compiler treats deployments, whether unit tests run in parallel, how callout response limits and security defaults apply, and a handful of other knobs that shape deployment timing, test reliability, and the diagnostic data available when something breaks. You reach it at Setup, then Custom Code, then Apex Settings. The page is low-traffic day to day, but the toggles on it carry weight. Turning on Compile All Apex on Deploy adds minutes to every deploy and catches dependency problems earlier. Disabling parallel testing slows the whole suite for every developer. The settings are also captured as the ApexSettings metadata type, so they travel between sandboxes and production through change sets or Salesforce DX. That is why two orgs that started identical can quietly drift apart over the years.

Apex Test Execution is the Salesforce Setup page that lets administrators and developers launch Apex unit-test runs interactively, monitor progress, and inspect results. It lives at Setup, Custom Code, Apex Test Execution. The page is one of three primary surfaces for running Apex tests in the platform. The Developer Console offers more verbose output and richer parallel runs, and the Salesforce CLI is the path most production CI/CD pipelines use. Apex Test Execution is the lowest-friction surface inside Setup itself, and the one new administrators tend to reach for first. The page lets users select one or many test classes, choose which methods inside each class to run, and submit the run. Tests execute asynchronously. The page tracks progress, shows pass/fail counts per class, and links into the underlying ApexTestResult records for failed methods. The same data flows into the Apex Test History page for trend analysis across recent runs. For day-to-day developer work, Developer Console and the CLI win on UX; for ad hoc runs and quick validations, Apex Test Execution is the right tool inside Setup itself.

An Apex trigger is a block of Apex code that runs automatically when records on a specific object are inserted, updated, deleted, or undeleted. It is the platform's primary hook for executing custom logic in response to data changes, and it has been the workhorse of programmatic Salesforce automation for fifteen years. Triggers fire at two timing points (before and after the database operation) for each of the four DML events, producing seven possible trigger contexts on each object. A trigger is declared with the trigger keyword, a name, an object reference, and one or more event contexts: trigger AccountTrigger on Account (before insert, after insert, before update, after update). Inside the trigger, the Trigger.new, Trigger.old, Trigger.newMap, and Trigger.oldMap context variables expose the records being processed. Most production triggers delegate immediately to a handler class for the actual logic, keeping the trigger file as a thin dispatcher. This pattern (the Trigger Handler) is the foundation of every maintainable Apex codebase.

Apex Managed Sharing is the Salesforce sharing mechanism that lets Apex code create, modify, and delete share records programmatically, applying access grants that standard sharing rules cannot express. Every shareable object (standard or custom) has a parallel __Share object that holds one row per access grant. The __Share row stores the parent record ID, the user or group receiving access, the access level (Edit, Read, or All), and the row cause (Manual, Rule, Owner, Team, or a developer-defined Apex Sharing Reason). Apex Managed Sharing is the only mechanism that can use Apex Sharing Reasons; the others reserve a fixed set of row causes. The technique exists for orgs whose sharing requirements outgrow declarative tools. Standard sharing handles owner-based, role-hierarchy, and rule-based access. Teams, queues, and territories add a few more options. Beyond those, complex business rules (a custom approver gets read access when a deal reaches a particular stage, sales engineers get edit access only on opportunities matching their product specialty) require Apex. The mechanism is powerful enough to grant arbitrary access patterns, but it inherits the same governor limits and bulkification concerns as any other Apex code. Production orgs reach for Apex Managed Sharing only after exhausting the declarative options.

ApexGuru Insights is a Salesforce platform feature that uses AI-powered static and runtime analysis to surface performance, security, and reliability issues in an org's Apex code. The tool produces Insights, each one a specific finding (a SOQL inside a loop, a non-bulkified DML, a heap-bloating pattern, a callout that can violate governor limits) attached to a specific class, trigger, or method. Developers open ApexGuru through the Setup app or the Code Builder IDE, review the ranked Insights list, and pick which ones to address. The tool prioritises Insights by estimated impact (transactions affected, governor-limit risk, performance hit), letting teams focus on what actually matters in production. ApexGuru is part of Salesforce's broader push to bring AI-assisted development to the platform alongside Agentforce for end users. It sits next to the older Apex Replay Debugger and the Salesforce Code Analyzer (PMD-based static analysis) as another layer of code-quality tooling. The differentiator is the use of actual runtime telemetry from the production org: ApexGuru sees which code paths matter most based on real user activity, rather than just scanning source for known patterns. The combination of static analysis plus runtime weighting is what makes it useful for triaging legacy code in busy orgs.

An API (Application Programming Interface) in Salesforce is the programmatic interface that external systems use to interact with the platform: read records, create records, update records, delete records, trigger automation, manage metadata, listen for events. Salesforce exposes several distinct APIs targeted at different use cases: REST API for standard CRUD operations and modern integrations, SOAP API for legacy enterprise integrations, Bulk API for high-volume data operations, Streaming API for real-time event subscriptions, Metadata API for configuration deployment, Tooling API for granular development operations, and several more specialized APIs. The Setup area titled API typically refers to the configuration page where admins manage API access policies, view API consumption against limits, and download the WSDL files needed for SOAP API integrations. The page is essential for any org that does meaningful integration work: monitoring API consumption against the daily limit, managing user-level API access, and configuring the policy controls that protect the org from runaway integrations.

API Catalog is the MuleSoft Anypoint Platform feature that organises every API specification, implementation, and consumer documentation in one searchable repository so developers, architects, and partners can discover existing APIs before building new ones. The catalog draws content from API Manager, Anypoint Exchange, Design Center, and MuleSoft's GitHub integrations. Each catalog entry shows the API's specification (typically OpenAPI/Swagger or RAML), version history, the team that owns it, the SLA tier it sits on, and the consumer documentation including code samples and a try-it-out console. Salesforce has been expanding the API Catalog concept across the broader product family as part of its Composable Enterprise positioning. Modern catalog implementations also index Salesforce-native APIs (REST, SOAP, Bulk, Streaming, Pub/Sub, Connect REST) plus the org-specific Apex REST endpoints, Named Credentials, and External Services. The intent is a single discovery surface where engineers can find, evaluate, and consume any API the organisation has built or licensed, instead of hunting through wikis or asking an architect. Inside an MuleSoft-anchored enterprise, the API Catalog is the central index that ties API-Led Connectivity, Anypoint Exchange, and run-time governance together.

API Manager is the MuleSoft Anypoint Platform component that governs APIs at run time. It applies policies such as rate limiting, client ID enforcement, and OAuth 2.0 token enforcement through an API proxy. Every consumer call passes through that proxy before it reaches the backend implementation, so the platform team gets one control plane for security, traffic, and access. Where Anypoint Exchange and the API Catalog handle discovery and documentation, API Manager handles enforcement. In the API-Led Connectivity model, API Manager sits in front of every System, Process, and Experience API. Each API is registered, a policy bundle is applied, and consumer applications request access by signing up for a client ID and secret. That access is recorded as a contract, often tied to an SLA tier. The result is a clear audit trail of which consumers called which APIs, how often, and whether they hit their limits. Without it, run-time governance falls to ad hoc checks inside each implementation.

An API Version in Salesforce is the numbered release of the platform's APIs (SOAP, REST, Bulk, Streaming, Metadata, Tooling, Connect, Pub/Sub) that callers and Apex code pin to so the contract stays stable across Salesforce releases. Versions follow a major-minor pattern: 60.0, 61.0, 62.0, and so on. A new version ships with each Salesforce major release (Spring, Summer, Winter), bringing new objects, new fields, new endpoints, and occasionally renamed or removed ones. Apex classes carry their API version in metadata. SOAP and REST callers send it in the URL or the WSDL. Each Salesforce release adds the new version while keeping older ones available, usually for at least three years. Pinning to an API version is the platform's main backward-compatibility lever. An Apex class written against API 50.0 keeps running unchanged through release after release because the platform honours the original 50.0 behaviour. An integration that calls /services/data/v55.0 stays on that contract until the integration owner upgrades the URL. The trade-off is staleness: behaviour fixed at 50.0 misses every subsequent improvement (new fields, performance optimisations, security upgrades). Salesforce periodically retires old API versions, giving customers years of notice but eventually forcing the upgrade.

API-Led Connectivity is the MuleSoft architectural pattern that splits an organisation's APIs into three layers: System APIs that expose raw access to backend systems (Salesforce, SAP, Workday, a mainframe), Process APIs that encode reusable business logic (orchestrate the System APIs to do something meaningful, like an Order-To-Cash flow), and Experience APIs that shape data and behaviour for a specific consumer channel (mobile app, partner portal, contact-centre console). Each layer has its own contract, its own owner, and its own deployment cadence. The point of the pattern is to invest in reusable components in the middle while keeping consumer-facing APIs small and tightly fitted to each surface. The pattern is the centrepiece of MuleSoft's value proposition inside the Salesforce ecosystem. Without API-Led Connectivity, every new consumer (mobile app, partner portal, third-party integration) writes its own integration to every backend system it needs, producing a tangle of point-to-point connections that nobody can refactor. With it, consumers call Experience APIs that call Process APIs that call System APIs. The contract becomes the documentation, MuleSoft's API Manager enforces policies at each layer, and the result is reuse, governance, and a clear path for retiring an underlying system without rewriting every consumer.

An App in Salesforce is a configurable bundle of tabs, navigation, branding, and Lightning components that gives a specific user role its working surface. Sales reps land in the Sales app with Accounts, Contacts, Opportunities, and Leads in the top navigation. Service agents land in the Service Console app with Cases and Knowledge in front of them. The same org may have dozens of Apps, each scoped to one team or workflow. Lightning Apps are configured in Setup, App Manager, and assigned to profiles or permission sets, so the right user sees the right surface on login. The word App carries several related meanings inside Salesforce, distinct from but adjacent to Lightning Apps. Connected Apps are OAuth client registrations for external integrations. AppExchange Apps are managed packages distributed by third-party partners. Mobile Apps are the Salesforce mobile clients (Salesforce Mobile App, Field Service App, partner-built mobile apps). Each surface uses the word App differently. The Lightning App is the most common day-to-day meaning, since every Salesforce user spends their session inside one App at a time.

The App Launcher is the grid icon in the top-left of the Salesforce Lightning Experience header that opens the menu of apps and items the user can access. Clicking it surfaces a panel with two sections: All Apps (the Lightning apps the user can switch to) and All Items (every tab, object, and Salesforce-built page the user has permission to open). The App Launcher is the primary navigation entry point in Lightning, replacing the Salesforce Classic App Menu dropdown. App Launcher visibility is profile and permission-set driven. An app appears in a user's App Launcher only if their profile or one of their permission sets explicitly grants access to that Lightning App. The order apps appear in is partly user-customizable (drag to reorder favorites) and partly admin-controlled through App Launcher settings. The Launcher also exposes Connected Apps (third-party SSO apps) and external services if the org has them configured, turning it into a unified launchpad for everything a user needs from Salesforce or from systems integrated through Salesforce.

App Manager is the Salesforce Setup page where administrators create, view, edit, and assign the apps in an org. It lives at Setup, then Apps, then App Manager. The page lists two different things that Salesforce both calls "apps": Lightning apps, which are user-facing bundles of tabs, branding, and a navigation bar, and connected apps, which register external systems that authenticate into Salesforce using OAuth, SAML, or OpenID Connect. Those two app types solve unrelated problems, but they share this one page because of shared vocabulary. A Lightning app shapes what a group of users sees when they open the App Launcher. A connected app governs how an outside service signs in and what it is allowed to do. App Manager is one of the higher-traffic admin pages because building a team app, adjusting a navigation bar, or wiring an integration all start here.

The App Menu in Salesforce is the Setup page where admins configure the order, visibility, and inclusion of apps available to users across the org. In Salesforce Classic, the App Menu was a dropdown in the top-right corner that let users switch between apps. In Lightning Experience, the App Menu role has been mostly absorbed by the App Launcher, but the App Menu Setup page still exists for org-level configuration of which apps are exposed to users and in which order. App Menu is the admin-facing configuration. It is distinct from the user-facing App Launcher (the grid icon that lets users switch apps) and the Lightning App itself (the configured page set with navigation, utility bar, and identity). The App Menu page lets admins decide which Lightning Apps appear in the App Launcher and which Salesforce Mobile App navigation shows the app. The Setup path is App Manager (Lightning Experience) or Setup, Create, Apps (Classic). The role is largely behind-the-scenes for Lightning-era orgs.

AppExchange is the marketplace Salesforce operates for third-party applications, components, consultants, and Trailhead-style learning content that extend the Salesforce platform. It launched in 2005 and is now the largest enterprise-application marketplace by listing count, with over 4,000 apps spanning Sales Cloud, Service Cloud, Marketing Cloud, vertical clouds, and Slack. Apps install directly into a Salesforce org through one-click flows, with the metadata, code, and license terms handled by Salesforce as the package broker. AppExchange is more than a download site. It is the distribution and revenue channel for Salesforce's ISV ecosystem. ISVs (Independent Software Vendors) publish managed packages on AppExchange, sign Partner Program contracts with Salesforce, pay a share of license revenue back to Salesforce, and submit each release to a Security Review that gates publication. Customers benefit from this gate: AppExchange listings have been audited for OWASP-class vulnerabilities, sharing-rule abuse, and platform-API misuse. The same code outside AppExchange has no such guarantee.

An AppExchange Listing is the marketplace page on Salesforce AppExchange that represents one solution offered by a partner. The listing carries the product name, tagline, descriptions, screenshots, demo video, feature highlights, supported industries and editions, pricing, customer reviews, installation method, and support contacts. It lives at appexchange.salesforce.com under a permanent URL. Customers use the listing to discover, evaluate, and install third-party apps, components, and bolt-ons before bringing them into their own org. Partners build and maintain a listing in the AppExchange Partner Console using a guided tool called the Listing Builder. A solution listing is linked to a managed package and must pass Salesforce Security Review before it can publish. A consultant listing promotes professional services rather than software and skips the package and review steps. Once approved and published, the listing becomes the partner's storefront, lead-capture surface, and review aggregator in one place.

The AppExchange Marketplace is Salesforce's official online store for ready-to-install business solutions and certified experts that extend the Salesforce platform. It hosts apps, components, Flow and Lightning Bolt solutions, data services, and consulting offerings built by Salesforce partners. Customers reach it at appexchange.salesforce.com to find, evaluate, and install solutions, while partners use it as their main distribution channel. Solutions arrive as packages, which Salesforce describes as containers for apps, tabs, and objects, and any package containing custom code has passed Salesforce Security Review. In 2025 Salesforce began rebranding the marketplace toward AgentExchange, the home for Agentforce actions, topics, and prompt templates, and several install pages now carry that name. The underlying idea has not changed. Rather than building every adjacent feature itself, Salesforce relies on partners to fill gaps like industry verticals, niche compliance needs, and integrations with non-Salesforce products. The marketplace makes those partners discoverable to millions of users and supplies the trust signals, security review, customer reviews, and transparent pricing, that justify installing third-party code into a production org.

An AppExchange Publishing Organization (APO) is a specialised Salesforce org that hosts the managed-package metadata and AppExchange listings for a partner ISV. Every partner with active marketplace listings keeps one APO that owns the master copy of every package they publish. Customer installs of those packages come from the APO; new package versions are uploaded to the APO before they are submitted for Security Review and released. The APO sits at the centre of the partner's distribution operation, separate from the Partner Business Org where the partner runs their own CRM, separate from the Development Org where engineers build the package, and separate from any sandboxes used for testing. The APO is special-purpose. It cannot be used for normal CRM or development work. Its job is to be the durable, single source of truth for what the partner has published to AppExchange. When a customer clicks Install on a listing, Salesforce reads the package metadata from the APO and applies it to the customer's org. When the partner uploads a new package version, they upload to the APO and that becomes the new install candidate for new and upgrading customers. Losing access to the APO or letting it lapse is one of the few ways a partner can disrupt their entire distribution channel; partners typically guard the org credentials carefully and avoid making operational changes inside it.

The AppExchange Security Review is the mandatory Salesforce review process that every app, component, or solution must pass before it can be listed on the AppExchange. A partner submits the package and supporting documentation through the Partner Portal; Salesforce's product security team runs automated and manual checks for OWASP-top-ten vulnerabilities, insecure coding patterns, improper sharing usage, exposed credentials, and policy compliance. Apps that pass are listed; apps that fail get a detailed remediation report and can re-submit after fixing. The review exists because installed AppExchange packages run inside customer orgs with the permissions of whoever installs them, often with broad data access. A vulnerable package becomes a vulnerable customer org. The review is one of the longest single processes in the Salesforce partner journey, commonly taking 8 to 16 weeks from first submission to listing approval depending on package complexity and how clean the first submission is. Re-reviews on package updates are faster but still required for any change that affects security surface.

AppExchange Upgrades is the platform mechanism that delivers new versions of managed packages from an AppExchange Publishing Organization to the customer orgs that already have a previous version installed. When a partner releases a new package version, customers can upgrade in place rather than uninstalling and reinstalling. The upgrade carries Apex classes, custom objects, custom fields, page layouts, and other metadata into the existing managed namespace, preserving all customer data that lives in the package's objects. Upgrades come in three flavours: Push Upgrades (the partner pushes the new version to selected customer orgs on a schedule), Pull Upgrades (the customer installs the new version themselves from AppExchange), and Patch Upgrades (a constrained release that adds limited changes without going through full Security Review). The upgrade model is critical to the AppExchange ecosystem because most packages evolve continuously. Customers expect to receive bug fixes, security patches, and new features without re-architecting their installation. Partners depend on the upgrade machinery to ship improvements without forcing customers off the product. The trade-off is governance: every upgrade must preserve backwards compatibility, respect customer customisations (custom fields added to managed objects, validation rules layered on managed records), and avoid breaking the org's existing automation. Mature ISVs invest heavily in upgrade testing because a broken upgrade ripples across every customer install at once.

Apple Messages for Business is Apple's branded business-messaging channel that lives inside the Messages app on iPhone, iPad, Mac, and Apple Watch. Customers start a conversation by tapping a Messages button on a business website, an Apple Maps listing, a Siri suggestion, or a Spotlight search result. The thread sits alongside their personal chats, marked with the business logo, name, and brand colors, so the experience feels native rather than bolted on. In Salesforce, Apple Messages for Business is one of the messaging channels in Service Cloud, handled the same way as SMS, WhatsApp, and Facebook Messenger. Each conversation becomes a messaging session tied to a Messaging User record, and Omni-Channel routes it to a queue, a flow, or a service rep in the Service Console. Setup depends on the business first registering with Apple Business Register and getting an approved brand and a Business ID. Marketing Cloud Engagement can also use the channel for outbound transactional notifications once a customer has opted in.

Application Lifecycle Management (ALM) is the practice and tooling that govern how a Salesforce application moves from idea to production and on through operations. The ALM scope covers requirements capture, design, development in dedicated environments, peer code review, automated testing, source-controlled metadata, environment promotion (dev to UAT to staging to production), release planning, change management, deployment automation, and post-release monitoring. The discipline applies whether the team uses change sets, Salesforce DX, or third-party tools like Copado, Gearset, Flosum, or AutoRABIT. The point is the same: keep the path from change to production predictable, auditable, and reversible. Salesforce ALM has evolved through three major waves. The first was Change Sets, the original UI-driven deployment tool tied to org-to-org connections. The second was the Ant Migration Tool plus Metadata API, which let teams script deployments but still relied on file-based metadata. The third is Salesforce DX, source-driven development with scratch orgs, Source format, Unlocked Packages, and the Salesforce CLI. Most enterprise orgs in 2026 run on a mix of DX plus a third-party ALM tool that adds visualisation, governance reporting, and CI/CD orchestration on top of the platform primitives.

An Application Network is the MuleSoft concept of a network of applications, data, and devices connected by reusable APIs, where each API is built on the principles of API-led connectivity. Instead of wiring every system directly to every other system, an organization exposes its capabilities as discoverable, governed APIs. Those APIs and the applications behind them become nodes, and the calls between them become edges, so the whole integration estate starts to behave like a connected graph rather than a flat list of point-to-point links. The idea reframes integration as a long-lived asset. As System APIs wrap backends, Process APIs orchestrate business logic, and Experience APIs serve consumer surfaces, each new API can reuse the ones already published. That reuse is what makes the network valuable: a capability built once can be consumed many times. Salesforce architects who work with MuleSoft adopt the model because it answers how an integration landscape scales as more teams, channels, and systems come online.

An Application Programming Interface (API) is a defined contract that lets one piece of software call another without knowing how it is built inside. In Salesforce, the word API usually points to one of the platform's standard web service interfaces, such as REST API, SOAP API, Bulk API 2.0, Pub/Sub API, GraphQL API, Connect REST API, User Interface API, Metadata API, and Tooling API. It can also mean a custom Apex REST or Apex SOAP endpoint that a developer exposes from an org. Each Salesforce API speaks a particular protocol and data format, covers a particular set of operations, and carries its own authentication and limits. REST and Bulk use HTTP and JSON, SOAP uses XML over a WSDL contract, and Pub/Sub uses gRPC with binary Apache Avro payloads. APIs are how an org reads and writes data with the systems around it, whether that is a mobile app, a data warehouse, an ETL job, or another cloud.

Application Test Execution is the Salesforce Setup page where administrators and developers run Apex tests and automated flow tests, then watch the results as they come back. You reach it from Setup by typing "Application" in the Quick Find box and selecting Application Test Execution. From there you pick which tests to run, launch them, and review pass and fail counts plus code coverage in one place. This page is the current home for declarative test runs in an org. It replaced the older Apex Test Execution page, so the name changed but the job stayed the same. The notable upgrade is scope. The page now runs both Apex unit tests and flow tests created with automated flow testing in Flow Builder, which the old Apex-only page could not do. A companion page, Application Test History, keeps the record of past runs for later review.

Application Test History is the Salesforce Setup page that lists the results of Apex test runs that executed asynchronously in your org. You reach it from Setup by entering Application in the Quick Find box and selecting Application Test History. It is also called the Apex Test History page, and it is available in Lightning Experience only. The page is the record of what happened after a run. Application Test Execution launches a set of tests, and Application Test History keeps the outcomes so you can review them later. The page shows test runs by ID. Click a run to see every test method it covered, then filter to passed methods, failed methods, or all of them. Salesforce keeps these results for 30 days after a run finishes, unless someone clears them sooner.

Appointment Scheduling in Salesforce is the capability to book, manage, and track customer appointments with a specific person, location, or asset in a defined time slot. The platform feature that delivers it is Salesforce Scheduler, formerly called Lightning Scheduler. It is available in Enterprise and Unlimited editions in Lightning Experience, and it lets a business schedule appointments in person, by phone, or by video, with the right person at the right place and time. Salesforce Scheduler builds on a small set of objects: Service Appointment (the booked appointment), Service Resource (the person or asset being booked), Service Territory (the location or organisational unit), Work Type (the kind of appointment, with a default duration and required skills), and Operating Hours (when appointments can be scheduled). It supports two booking patterns. Inbound scheduling lets customers book their own slot through an Experience Cloud site or your website. Outbound scheduling lets an internal user book on the customer's behalf from the Service Console. Both patterns run through the same scheduling engine, which finds open slots by reading availability, skills, and existing bookings.

An Approval Action in Salesforce is an automated action that an Approval Process runs at a defined point in its lifecycle. Those points are when a record is first submitted, when an individual step is approved or rejected, when the whole process finishes with approval or rejection, and when the submitter recalls the request. Each action performs a side effect, such as updating a field, sending an email alert, creating a task, sending an outbound message, or running a flow. Approval Actions are what turn a human decision into changes the rest of the org can see. Approval Actions are configured inside the Approval Process editor, attached to one of five trigger points: Initial Submission Actions, Approval Step Actions, Final Approval Actions, Final Rejection Actions, and Recall Actions. Any trigger point can hold any number of actions. The Salesforce documentation lists the same five action types at each point: email alert, field update, task, outbound message, and flow. Most real processes lean on field updates and email alerts, with record locking handled automatically on submission and unlocked when the process resolves.

An approval process is a Salesforce automation framework that routes a record through a defined sequence of approvers, applying field updates, locking records, and triggering notifications at each step. It is the platform's answer to "this record needs someone to sign off before the next step." Approval processes work natively on most standard and custom objects and combine criteria-based entry, multi-step routing, parallel or unanimous approvers, and conditional field updates on approval or rejection. Each approval process has three layers: entry criteria that determine which records qualify, approval steps that define who approves and in what order, and final approval/rejection/recall actions that change the record state when the process completes. Approvers can be specific users, role hierarchies, queues, or values from a User lookup field on the record. The platform locks the record during approval to prevent edits that would invalidate the in-flight decision, and the lock releases automatically when the process completes or is recalled. Approval processes are still actively supported and have not been deprecated alongside workflow rules and Process Builder.

An Approval Request in Salesforce is the record an approver acts on when a submitted record reaches a step in an approval process. When a record is submitted and lands on a step, Salesforce creates the request and assigns it to the named approver (a user, a queue, or a public group). The approver finds it in the notifications tray, in the Items to Approve list on the home page, or in the email alert sent at submission. Approving, rejecting, or reassigning the request moves the underlying approval process to its next step or to its final outcome. The Approval Request is the human-facing side of Salesforce's approval framework. The approval process is the configuration, the step is the logical checkpoint, and the request is what a person actually clicks. Each request shows the submitted record's key fields, the history of decisions so far, any comments left by earlier approvers, and the action buttons. For classic approval processes the data lives on the ProcessInstance, ProcessInstanceStep, and ProcessInstanceWorkitem objects, all queryable with SOQL for reporting and integration.

An Approval Step is one decision point inside a Salesforce Approval Process. Each step has its own entry criteria, an assigned approver or set of approvers, a behavior on rejection, and optional actions that fire when the step is approved or rejected. One step models a single sign-off, such as a manager approving an expense. Several steps chained in sequence model a longer review, such as finance approving first, then legal, then a senior leader for high-value records. A step is configured in the Approval Process editor under the Approval Steps related list, and it is stored on the ApprovalStep portion of the ApprovalProcess metadata. Every step has a name, a step number that sets its order, optional step criteria that decide which records enter it, an approver assignment, and a rule for what happens if the approver rejects. Step criteria give one process conditional paths, so a small request and a large request can follow different routes without building separate processes. Steps are how Salesforce models hierarchical, conditional, and multi-stakeholder approvals declaratively, without code.

Approvals in Chatter is a Salesforce feature that delivers a pending approval request to the approver as a post in their Chatter feed, so they can read the record context and click Approve or Reject without opening a separate approval page. When the feature is on and the request is configured for it, each newly assigned approver gets a Chatter post that shows selected fields from the submitted record, prior comments, and inline action buttons. The feature is tied to Classic Approval Processes. You turn it on once in Setup under Chatter Settings, build an approval post template to control what the post shows, then point an approval process at that template. Salesforce now positions Flow-based approvals (built in Flow Orchestration) as the modern way to route approvals, so treat Chatter approval posts as a mature capability that pairs with the older approval engine rather than the newest option.

An Archived Article is a Salesforce Knowledge article whose published version has been retired from active use but kept in the org. Archiving sets the PublishStatus field on the KnowledgeArticleVersion record to Archived. The article drops out of Knowledge search results, the agent Knowledge sidebar, and any Experience Cloud help center, yet it stays in the database with its full content, version history, author, and metadata intact. Archiving sits between publishing and deleting. Published content has a natural lifecycle: product notes go stale, procedures get superseded, and macros stop matching the current release. Deleting throws the article away, while archiving preserves it for audit, legal hold, and possible reinstatement. Only users with the right Knowledge permissions can find or restore an archived article, so agents and customers never stumble onto outdated answers during normal work.

An Article in Salesforce is a Knowledge Article, the platform's unit of structured help content. Each article carries a Title, a URL Name, a rich-text Body, data category assignments, channel assignments, and version metadata. Authors write articles, reviewers approve them, and the org publishes them so agents, customers, and partners can find the answer they need. In Lightning Knowledge, every article lives on the standard Knowledge object rather than the per-type objects used by Classic Knowledge. Articles are how an organization captures institutional knowledge in a form the platform can serve. An agent reading a case pulls the relevant article from the Knowledge sidebar. A customer searching a Help Center finds the same article ranked by relevance. Einstein and Agentforce ground their answers in published articles so the response cites a real source. The article's lifecycle (Draft, Online, Archived) decides which version each audience sees.

Article Manager is the Salesforce surface that Knowledge authors and managers use to find, create, edit, publish, archive, restore, and delete Knowledge articles across their full lifecycle. In Lightning Experience it is the Knowledge tab, also called Knowledge home, paired with list views filtered by publication status, data category, record type, and author. The same surface that lets a new author open their drafts also lets a manager review content archived three years ago. The page is the day-to-day control center for a Knowledge program. From a list view you can search, sort, select records, and run authoring actions on one article or a batch at once. It folds in the work that Salesforce Classic handled on the separate Article Management page. The capabilities carry over, but in Lightning Experience they live inside the standard Knowledge tab rather than a dedicated screen.

Article Publication is the Salesforce Knowledge lifecycle event that moves an article version from Draft into Online status, making it visible to the channels assigned to that article. Publishing sets the PublishStatus field to Online on the KnowledgeArticleVersion record. The new version replaces the previously Online version, and the content becomes searchable and visible across the Knowledge component, the agent sidebar, Experience Cloud help sites, and any other surface that reads the Knowledge index. Publication can be triggered by a person who clicks Publish in the Knowledge app, by a scheduled job tied to a future publish date and time, or programmatically through Apex and the REST API. Each path produces the same result. A new article version goes Online, the prior Online version moves to version history, and the article reaches its configured audience. Before publication the article exists only as a working draft, so publication is the moment the content actually starts helping agents and customers.

An Article Review is the controlled step where a Salesforce Knowledge article moves from a finished draft into reviewer evaluation before it goes live. A subject matter expert, editor, or compliance owner reads the draft, checks accuracy and tone, confirms the Data Category and channel choices, then approves it for publication or sends it back to the author with comments. Salesforce supports this step through standard Approval Processes (or a Flow-built approval) layered on the Knowledge object, plus optional automation that runs checks before a human ever opens the draft. The review step matters because a Knowledge article becomes operational truth the moment it publishes. A wrong instruction in a how-to article costs an agent time on every case that surfaces it. A misleading answer shows to thousands of customers per quarter through self-service. Review is the gate that keeps weak content off the customer-facing surface. One detail trips up many teams: even after an approval completes, Salesforce does not auto-publish. A person still clicks Publish.

An Article Type is a Classic Salesforce Knowledge construct that defined one kind of article, such as an FAQ, a How-To, a Procedure, or a Release Note. Each Article Type was its own custom object with a __kav suffix (short for KnowledgeArticleVersion). It carried a Title plus type-specific fields, its own page layouts, and its own permissions. Authors picked a type, and that choice decided which editor and which fields they saw. Every new kind of article meant a brand new custom object, so the model grew heavy fast. Lightning Knowledge replaced this design. Instead of many objects, it uses one Knowledge object with Record Types that distinguish the kinds. The functional behaviour carries over, but the schema is far simpler. Most production orgs have finished moving from Classic Knowledge to Lightning Knowledge using a supported migration tool. The phrase Article Type still shows up in older Help pages, blog posts, and some certification material, where it points at the Classic concept rather than current Lightning behaviour. If you read it in a recent context, translate it to Record Type.

An Article-Type Layout was the page layout attached to a Salesforce Classic Knowledge article type. Each article type, such as FAQ or How-To, had at least one layout that decided which fields appeared on the article, in what order, inside which sections, and which fields each profile could see or edit. The layout connected the article type's fields, stored on the underlying article version object, to the experience an author saw while writing. The feature is older Classic Knowledge functionality. Lightning Knowledge replaced article types with record types on one unified Knowledge object, and replaced the per-type layout with a standard page layout assigned per record type and profile. Most orgs moved off Classic Knowledge between 2018 and 2022, retiring Article-Type Layouts along the way. The term still shows up in older documentation and certification material, so reading any such reference means translating it to the Lightning record type layout that does the same job today.

An Article-Type Template was a Salesforce Knowledge setting that controlled how an article's sections rendered to readers in each publishing channel. In Classic Knowledge, every Article Type was assigned a template per channel, and that template decided whether the article's sections appeared as clickable tabs, as a single page with a table of contents, or as a fully custom Visualforce layout. The two standard choices were Tab and Table of Contents, and admins could swap them per channel without writing code. This is a legacy concept. It belonged to the Classic Knowledge data model, and that model is no longer available as of the Summer '25 release. Lightning Knowledge replaced article types and their templates with standard objects, page layouts, and the Knowledge Article component configured through Lightning App Builder and Experience Builder. You will still see Article-Type Template mentioned in older implementation guides, certification prep, and partner blogs, but it no longer maps to a setting you can configure in a current org. Treat any reference to it as historical and translate it to the Lightning equivalent.

An Asset in Salesforce represents a specific instance of a product that a customer owns. Where Product describes the catalog item your company sells, Asset describes the actual unit installed at a specific customer site, tied to that customer's Account or Contact, with a serial number, install date, status, and history. A single Product can have thousands of Asset records across the customer base; each Asset is one customer's copy of that thing. Asset is the object that connects sales motion to service motion. The deal closes on an Opportunity, the order gets fulfilled through an Order or Contract, and the Asset record is what remains on the customer Account as a tangible thing the support team can reference for warranty, troubleshooting, and renewal. In a Field Service org, every truck-roll keys off an Asset. In a B2B software org, Assets often represent subscription instances or named-user licenses. In a manufacturing org, Assets represent physical equipment with serial numbers and installation locations. The shape of the data is consistent; the operational meaning shifts by industry.

An Asset Hierarchy is a Salesforce structure that links Asset records into parent and child relationships, so a compound product and its components can be tracked as a single unit. You build it on the standard Asset object using the Parent Asset field, and Salesforce surfaces the result through the Child Assets related list and a View Asset Hierarchy action that opens a collapsible tree grid. A common example is a solar panel system that holds a child Asset for each panel, inverter, and meter. An industrial machine can hold child Assets for each replaceable part, and a connected appliance can hold child Assets for its modules. Asset Hierarchy is part of the core CRM schema and is used heavily in Field Service, where a technician servicing one installation needs to know exactly which component failed.

An Asset Relationship is a Salesforce standard object that records a non-hierarchical link between two Asset records that exists because of an asset modification, such as a replacement or an upgrade. It is the object behind the Primary Assets and Related Assets related lists you see on an asset page. When one piece of equipment takes the place of another, the relationship captures which asset replaced which, so the swap is preserved as data rather than living in a note field. Asset Relationship is used in Field Service, in Revenue Lifecycle Management, and in any business that tracks installed equipment over its life. In Revenue Lifecycle Management it carries a second meaning: it represents assets grouped together in a bundle or set. The object is queryable, reportable, and editable, and it keeps the underlying Asset records untouched while it describes how they relate.

An Assigned Approver in Salesforce is the user, queue, or related user named on an Approval Step to act on every approval request that reaches that step. The approval process configuration sets the Assigned Approver at design time, and the platform resolves who that actually is at runtime, when a record flows through the step. Depending on the assignment type chosen, the approver can be the submitter's manager, a specific user, a queue, a public group, or the value of a hierarchical user field on the record. Choosing the Assigned Approver is the central decision in an approval step. Get it right and the request lands with someone who has context and authority, so the decision happens fast. Get it wrong and requests stall, escalate to the wrong person, or sit unanswered. Salesforce assigns approvers per step, so one approval process can route the same record through different approvers at each stage, modeling multi-stakeholder sign-off without any code.

Assignment in Salesforce is the act of giving ownership of a record (Lead, Case, Account, Opportunity, Contact, custom object) to a specific user or to a queue. The OwnerId field on every assignable object captures the assignment; downstream sharing rules, list view visibility, reporting, and assignment-driven automation all read this field. Assignment can happen manually (the user edits the Owner field on a record), through Assignment Rules (declarative rules for Leads and Cases), through Round Robin or load-balancing patterns (often built with Flow or Apex), through territory rules (Enterprise Territory Management), or programmatically through any Apex or Flow that writes the OwnerId field. The pattern is consistent across objects but the configuration mechanism varies. Lead and Case have native Assignment Rules with built-in declarative rules engines. Account uses territory-driven assignment or manual ownership. Opportunity inherits the rep on creation and stays unless reassigned. Custom objects rely on Flow, Apex, or manual assignment. Across all of these, the right assignment pattern depends on response-time requirements, fairness across reps, and how the team handles handoffs.

An asynchronous call in Salesforce is an Apex operation that runs later, in a separate transaction from the code that started it. The calling transaction does not wait for the result. It returns right away, and the platform runs the queued work whenever processing resources become available, which can be milliseconds or minutes afterward. Salesforce groups asynchronous Apex into four patterns: future methods (the @future annotation), Queueable Apex, Batch Apex, and Scheduled Apex. Each pattern has its own entry point, its own monitoring, and its own behavior under load. They share one purpose. Move work out of the synchronous request so the user is not blocked, large data volumes can be processed, and operations get a fresh set of governor limits instead of competing inside one tight transaction.

Atlas Reasoning Engine is the planner inside Agentforce that decides what an agent does on every user turn. It classifies the incoming message into one of the agent's active topics, picks which Agent Actions to invoke (and in what order), extracts the parameters those actions need from the conversation context, runs the actions, and synthesizes the final response. Atlas is the layer that turns a generic LLM into a behaviorally consistent Salesforce agent. Atlas is what differentiates Agentforce from a plain chatbot wrapper around a model. The engine reads the topic classification descriptions, action instructions, and parameter descriptions that admins write in Agent Builder and uses them to make grounded decisions rather than letting the LLM free-ride on training data. The Plan Trace surfaced in the Conversation Preview is Atlas's decision log, exposed in human-readable form so admins can debug agent behavior without reading model logs.

An Attachment is a standard Salesforce object that stores a single file (a PDF, image, or document) tied directly to one parent record. The Attachment row holds the binary content in its Body field as a blob, along with metadata like the file name, content type, body length, and the parent record ID. Files attached this way show up in the Notes & Attachments related list on the parent record and can be downloaded or viewed, but not much else. Attachment is the older file mechanism. It came before Salesforce Files, the modern feature built on the ContentVersion and ContentDocument objects. The object is still available in every org for backward compatibility, and existing Apex that creates Attachment rows still runs. Salesforce now points new development at Files, and Lightning record pages surface Files by default. Treat Attachment as a legacy term: when you see it in older docs or inherited code, the current equivalent is almost always Files.

An Audience Channel in Salesforce is the delivery surface that an audience or segment gets activated against, such as email, SMS, push notification, paid advertising, in-app messaging, or a file-storage and partner destination. It is one of three things you decide for any activation: which population (the audience or segment), where it goes (the channel), and when it runs (the schedule). Each channel carries its own connector, its own identifier requirements, and its own consent and frequency rules. The concept appears across Marketing Cloud Engagement and Data Cloud. In Data Cloud you activate a segment to an activation target, then choose contact points so the right people reach the right channel with the right permissions. In Marketing Cloud Engagement the channels are email, SMS through MobileConnect, push through MobilePush, and paid ads through Advertising Studio. The Audience Channel answers the where question, separate from the who and the when.

Audit Trail Export Dashboard is the Setup-area report that lets admins download a CSV of the Setup Audit Trail (every configuration change made by users with Modify All Data or higher permissions) over a date range, then visualize the export as a dashboard. The dashboard exists because the Setup Audit Trail UI alone is hard to analyze: it shows 20 entries at a time, has no filtering by user or by entity type, and retains data for only 180 days online (six months) before older entries become archived and require export to access. The dashboard pattern lives on the standard SetupAuditTrail object. Admins export the audit log via the Download button under Setup, Setup Audit Trail, then load it into a CRM Analytics dataset, an external BI tool, or a custom Salesforce dashboard built on imported data. The point is to track who changed what and when across the year, especially for compliance audits, security reviews, and post-incident change forensics. Without the dashboard, the data exists but is unusable at scale.

An Aura Component is a unit of custom UI built with the original Salesforce Lightning Component framework, released in 2014 and superseded by Lightning Web Components in 2019. Aura components are made up of a component markup file (.cmp), a controller, a helper, a renderer, an event bundle, and a metadata file. The framework was Salesforce's first answer to building a single-page-app feel on top of Visualforce, predating native Web Components in the browser. Aura still runs in production orgs. Many standard Salesforce features (older Lightning record pages, parts of the Service Console, Aura-based community templates) were built in Aura and have not been ported to LWC. Custom Aura components from earlier builds also remain widely deployed. Salesforce supports Aura but no longer invests in new Aura features. The official guidance is to build new components in LWC and migrate Aura components opportunistically as they require change.

Auth Providers is the Salesforce Setup page where administrators configure external identity providers (Google, Facebook, LinkedIn, Microsoft, Apple, Twitter, OpenID Connect, GitHub, custom) that users can authenticate against to log into Salesforce or into Experience Cloud sites. Each Auth Provider record holds the OAuth client ID, client secret, authorization endpoint, token endpoint, and the scopes Salesforce requests from the external provider. Once configured, the provider appears as a Login With button on the Salesforce login page or the Experience Cloud login page. Auth Providers are the foundation for social sign-in and federated SSO scenarios. They are different from SAML SSO (configured under Single Sign-On Settings) which uses SAML assertions rather than OAuth tokens. Auth Providers are the right choice for OAuth-based identity (Google, Microsoft Entra OAuth, custom OpenID Connect IdPs); SAML is the right choice for traditional enterprise SSO (Okta, Microsoft Entra SAML, Ping). Most enterprise orgs use both, with Auth Providers for customer-facing Experience Cloud login and SAML for internal Salesforce user login.

Authorized Email Domains is the Salesforce Setup feature where administrators register the email domains the org is allowed to send From in outbound email. Each registered domain pairs with a DKIM key Salesforce generates so receiving mail servers can verify that emails claiming to come from the org's domain actually originated from Salesforce. Without authorized domain registration plus the matching DKIM record on the customer's DNS, outbound emails commonly land in spam folders or get rejected outright by receiving servers. The feature is the Salesforce side of email authentication. The customer side requires publishing a CNAME or TXT record in DNS that points to the Salesforce-generated DKIM key. Together they tell receiving mail servers: yes, Salesforce is authorized to send for this domain. Authorized Email Domains is one of three related features for outbound email integrity (Email Relay Activation, DKIM Key Management, Email Authentication settings); together they form the deliverability foundation for any org that sends customer-facing email.

Auto Number is a Salesforce custom field type that automatically generates a unique sequential number for every new record on the object, formatted according to a display pattern the admin defines (PROJ-{0000}, CUST-{2026}-{00000}). The platform increments the counter on every insert; the resulting value is read-only and cannot be edited after creation. Auto Numbers are commonly used for internal record codes (Project Number, Customer Code, Internal Reference), and several standard objects (Case, Solution, Contract) ship with built-in Auto Number fields by default. The Auto Number field exists because Salesforce's record IDs (the 15- or 18-character alphanumeric Id) are not friendly for human reference; nobody quotes "0035j00000ZXY5kAAH" on a phone call. An Auto Number gives each record a readable identifier that supports filtering, sorting, search, and integration. Beyond convenience, Auto Numbers also serve as the user-facing reference in customer-facing documents, support tickets, and downstream systems that consume Salesforce data.

An auto-response rule is a Salesforce automation that sends a templated email to a Lead or Case contact the moment a new record is created. It is the platform's answer to "send an immediate acknowledgment so the customer knows we received their request." Auto-response rules fire on inbound channels like Web-to-Lead forms, Web-to-Case forms, Email-to-Case, and partner portal submissions, and they run as part of the initial save sequence so the email lands within seconds of submission. Like assignment rules, auto-response rules have a one-active-rule-per-object limit and a list of entries evaluated in priority order with first-match-wins behavior. Each entry has criteria, a sender email, a reply-to address, and a template. The matching entry determines which template fires for which record. Auto-response rules cover only Lead and Case objects natively; other objects need Flow or Process Builder to send acknowledgments, but the pattern is identical.

An Autolaunched Flow is a Salesforce Flow that runs without showing any screens to a user. It executes in the background and is started by something other than a person clicking through a wizard. That starter can be a record save, a scheduled time, a published platform event, an Apex class, a process, another flow called as a subflow, a custom button or link, an Agentforce action, or an external system through the Flow REST API. The key difference from a Screen Flow is that an Autolaunched Flow has no user interface. Decisions, loops, data lookups, record creates and updates, and Apex callouts all work the same way in Flow Builder. What changes is who sees the result, which is nobody. The flow runs, finishes, and hands control back to whatever called it. That makes it the standard pattern for background automation, integrations, and any work that fires from an event rather than a click. Salesforce now recommends flows for most automation that older tools like Workflow Rules and Process Builder used to handle.

An Automated Action in Salesforce is a reusable side effect that an automation rule fires when its trigger conditions are met. The classic catalog has four types: a Field Update changes a value on the triggering record or a parent record, an Email Alert sends an outbound email from a template, a Task creates an assigned activity, and an Outbound Message posts a SOAP message to a configured external endpoint. Each action is its own metadata record. You build it once in Setup, then point one or more rules at it. The concept predates Flow and is tied to the older automation tools. Workflow Rules and Process Builder both reached end of support on December 31, 2025, so they no longer get bug fixes or Salesforce support, though existing rules keep running. Approval Processes still expose these actions, and legacy Workflow Rule actions continue to fire in older orgs. New automation should use Flow, whose action list is much wider than the original four.

Automatic Number Identification (ANI) is the caller's phone number that the telephony network captures and delivers with every inbound call. It arrives during call setup, alongside the dialed number known as DNIS, and it tells the receiving system who is on the line before anyone speaks. In a Salesforce contact center, the ANI is the signal that links a ringing phone to a known customer. In Salesforce Voice (formerly Service Cloud Voice) the ANI flows from the telephony provider into Salesforce and drives caller matching. The platform searches your records for that phone number, finds the matching Contact, Account, Lead, or Person Account, and opens it on the agent's screen as a screen pop. The same number can shape routing, feed the IVR for self-service, and provide context the agent would otherwise have to ask for.

An Automation App in Salesforce is a focused app or Setup surface dedicated to building, scheduling, and monitoring the automation that runs behind the scenes. The label is not one fixed product. It points to whichever surface a given cloud uses to house its automation, and the meaning shifts with context. In the core CRM platform it usually means the Flow Builder surface and the supporting Setup pages under Process Automation. In Marketing Cloud Engagement it means Automation Studio, the tool that orchestrates data imports, SQL queries, file transfers, and scheduled sends. The common thread is a single place where automation lives, gets watched, and gets debugged. For most CRM admins working in 2026 the relevant Automation App is Flow Builder plus its monitoring views, because Salesforce stopped supporting Workflow Rules and Process Builder on December 31, 2025. For Marketing Cloud teams the relevant Automation App is Automation Studio, which stays the home for data preparation and back office messaging workflows. Both describe a contained workspace where automation is created, governed, and observed.

An autonomous agent in Salesforce Agentforce is an agent that takes multi-step action on a user request without asking a human to confirm each step. It plans, chooses which Agent Actions to run, executes them in sequence or parallel, decides whether the result satisfies the user, and either responds with the outcome or loops back to do more. The Atlas Reasoning Engine drives the loop; the agent's topics and actions define what the engine is allowed to do. Autonomy is a spectrum, not a switch. A fully autonomous customer-facing Service Agent that updates records and sends emails sits at one end. A purely assistive Service Coach that drafts a reply but never sends it sits at the other. Most production Agentforce deployments live in the middle: the agent acts autonomously on read operations and low-risk writes, and gates higher-risk writes (refunds over a threshold, account merges, license changes) behind a human review step.