Salesforce terms starting with B

Background Jobs in Salesforce are asynchronous units of work that run outside the user's interactive transaction: scheduled Apex jobs that fire on cron schedules, Queueable Apex jobs queued from another transaction, future methods that run shortly after the calling transaction commits, Batch Apex jobs that process large record sets in chunks, and the various platform-managed jobs (sharing recalculation, index rebuilds, mass updates). The Apex Jobs page in Setup is the central monitoring surface; admins use it to see job status, completion time, errors, and to abort stuck or runaway jobs. Background Jobs let Salesforce process work that does not fit in the synchronous transaction model: long-running data processing, scheduled maintenance, callouts that exceed the synchronous timeout, bulk record updates that exceed governor limits. They have their own governor limits (different from synchronous limits), their own monitoring surface, and their own debugging considerations. Most production Salesforce orgs run dozens to hundreds of Background Jobs per day; understanding the queue, the prioritization, and the failure modes is core admin and developer knowledge.

Basic Data Import is the Salesforce wizard for importing small to medium volumes of records (up to 50,000 records per import) into standard or custom objects. Admins upload a CSV file, map the columns to Salesforce fields, decide between insert, update, or upsert behavior, and run the import. The wizard handles common objects (Account, Contact, Lead, Solution, and one custom object per import session) and offers field mapping suggestions plus duplicate detection. It is the simpler counterpart to Data Loader, which handles larger volumes and more advanced patterns. Basic Data Import covers the everyday data load scenarios most admins face: importing a list of leads from a marketing event, adding contacts from a partner spreadsheet, updating account fields from an external system export. The 50,000 record cap and the limited object support are the boundaries; beyond those, Data Loader, Bulk Data Load Jobs, or a custom integration is the right tool. Most admin teams use Basic Data Import for weekly to monthly data loads and reserve heavier tools for mass migrations and integrations.

Batch Apex is a Salesforce execution context that processes large data sets by splitting work into manageable chunks (batches), each running as its own transaction with its own governor limits. It is the right tool when a job needs to read or update millions of records, perform long-running aggregations, or chain async work across multiple steps. The platform handles chunking, scheduling, and retry logic, leaving the developer to focus on the per-chunk business logic. A Batch Apex class implements the Database.Batchable<T> interface with three methods: start (returns a query locator or iterable identifying the records to process), execute (runs on each chunk with the records as input), and finish (runs once when all chunks complete). The platform splits the start query result into batches of 200 records by default, and each chunk runs in its own transaction. This pattern lets a single batch job process 50 million records without hitting any single-transaction limit, at the cost of slower wall-clock time compared to synchronous processing.

The Batch Bulk API (more commonly called the Bulk API, with Bulk API 2.0 as the modern version) is the Salesforce REST-based interface designed for high-volume asynchronous data operations: insert, update, upsert, delete, hard delete, and query against tens of thousands to hundreds of millions of records. Where the regular REST API handles one or a few records per call, Bulk API accepts a CSV (or JSON) payload of many records at once, processes them in chunks on Salesforce's async layer, and returns success/failure results that the client polls for. Bulk API 2.0 simplifies job lifecycle compared to 1.0 and is the recommended version for new integrations. Bulk API exists because the regular REST API governor limits make large data loads impractical. Loading a million Account records through standard REST would burn the daily API quota and take hours. Bulk API processes the same job in minutes by running batches against larger limits on the async layer. Data Loader, MuleSoft, Informatica, and most ETL tools use Bulk API under the hood for any operation above a few thousand records. Reporting tools that need bulk export use Bulk API Query for the same reason. The trade-off is async semantics: clients submit a job and poll for completion rather than receiving immediate responses.

The Best Answer in Salesforce Chatter Questions and Experience Cloud Q&A surfaces is the comment that the question asker, a moderator, or another authorised user has marked as the definitive resolution to a posted question. Marking a comment as the Best Answer pins it to the top of the question thread, surfaces a Best Answer label in feeds, and contributes to gamification reputation for the answering user. The marked answer is what new visitors see first, so it functions as the canonical answer to that question even when other replies remain visible below it. Best Answers replaced the legacy Answers feature's similar best-answer mechanism after Salesforce retired the Community Application's Q&A surface. Modern Best Answers run on Chatter Feed Items: the question is a Feed Item, the replies are Comments, and the Best Answer is a Comment with a Best Answer flag. Knowledge programs often elevate popular Best Answers into formal Knowledge articles, which then become reusable resolution content beyond the original thread. The combination of community-driven Best Answers and authored Knowledge is how mature self-service programs scale answers without scaling the support team.

Best Case Amount is the Collaborative Forecasts column that shows the forecast value rolled up from Opportunities in the Best Case forecast category, summed across the user's pipeline and any reports rolling up beneath them. Where Commit shows the conservative number the rep is willing to bet on and Pipeline shows everything still open, Best Case captures the deals the rep believes are more likely than not to close even though they cannot commit. The column is one of the central readings on the Forecasts tab and is the field sales leadership watches alongside Commit and Closed when assessing whether the quarter is on track or in danger. Best Case Amount is calculated by mapping each open Opportunity's Stage to its Forecast Category, summing the Amount of every Opportunity whose Forecast Category is Best Case for the relevant period and ownership, then applying any forecast adjustments. The Best Case column on the Forecasts tab and the matching ForecastingItem record both expose the value. Stage-to-Forecast-Category mappings are controlled in Setup; admins configure which Stages roll up to Pipeline, Best Case, Commit, and Closed. Most production forecast designs use Best Case to mean reasonably likely to close, leaving more aggressive forecasts in Pipeline and more conservative ones in Commit.

A Beta Managed Package in Salesforce is a managed-package version that the publishing ISV has uploaded but designated as Beta rather than Released. Beta packages can only be installed in Developer Edition orgs, sandboxes, and Trial Orgs; they cannot install in production orgs. This restriction lets ISVs share early builds with internal testers, partners, and select customers without committing to a Released version that becomes part of their installed base forever. Beta is the safe testing tier before a managed package goes to formal release. Beta managed packages help ISVs iterate quickly. Released managed packages carry significant commitments: existing customers must be able to upgrade safely, key fields and Apex classes cannot be removed, and Security Review (for AppExchange distribution) is required. Beta packages relax these constraints. The ISV can ship a Beta to internal QA, partner testers, and pilot customers; if the build has issues, the next Beta supersedes it without polluting the install history of any production org. Once the ISV is confident, they upload a Released version that becomes installable in production and (when going through AppExchange) starts the formal Security Review cycle.

Big Objects are a Salesforce object type designed to store billions of records, far beyond the practical limits of standard or custom objects. They are the platform's answer to scenarios that need long-term retention of event-level data: archived transactions, audit logs, IoT telemetry, regulatory snapshots, multi-year activity histories. Big Objects trade off some traditional Salesforce features (no triggers, no validation rules, limited reporting) in exchange for the ability to query records at massive scale via async SOQL. Each Big Object is defined by metadata that includes its fields and its composite primary key. The primary key is the access pattern, not just a uniqueness constraint. Big Objects are indexed only on this composite key, which means queries must filter on key fields to perform well. Async SOQL handles cross-cutting aggregations against Big Objects, returning results to a custom object as a Background Job. Big Objects do not appear in standard reports or list views; they exist for programmatic and analytical access at a scale no other Salesforce data store can match.

A Blank Lookup in Salesforce is a lookup field that has no value: the record's relationship to the parent object is empty (null in SOQL, no value selected in the UI). Blank Lookups happen by design (the lookup is genuinely optional) or by accident (a required relationship that nobody set). They show up in formula fields as ISBLANK(LookupField__c), in validation rules as a required-field check, in SOQL as IS NULL, and on related lists as missing rows on the parent side. Handling them correctly is part of basic Salesforce data hygiene. Blank Lookups matter because most Salesforce data models rely on lookups to navigate between objects. A Contact with a blank AccountId floats unattached and surfaces awkwardly in reports. An Opportunity with a blank Account is invalid in most B2B orgs. A custom object with a blank parent lookup may not roll up to dashboards correctly. The fix depends on intent: if the lookup should always be set, validation rules enforce non-blankness; if it can be blank, formulas and Flows handle the missing case. Either way, the design decision is explicit. Quietly tolerating Blank Lookups in fields that should be required is one of the most common sources of long-term data quality issues.

Boolean Operators in Salesforce are the logical connectives (AND, OR, NOT) that combine multiple conditions into one composite expression. They appear in nearly every place Salesforce evaluates a condition: validation rule formulas, Flow decision elements, report filters, list view filters, SOQL WHERE clauses, search expressions, sharing rule criteria, and approval-process entry criteria. The semantics are the same as Boolean algebra anywhere else: AND is true only when both sides are true; OR is true when at least one side is true; NOT inverts the value. The platform-specific detail is that different surfaces use slightly different syntax (text in some, symbols in others, parentheses in all). Boolean Operators are the difference between a simple match and a real business rule. Closed Won and Amount > 100k is two conditions joined by AND. Industry equals Healthcare or Industry equals Life Sciences is two conditions joined by OR. NOT(IsClosed) is the negation pattern that catches everything except closed records. Mastering Boolean Operators is a foundational Salesforce skill because the same logic shows up in every automation tool, every report builder, every formula field. The mistakes are universal too: missing parentheses change the meaning, mixing AND and OR without grouping produces unexpected results, and treating NULL like false produces wrong answers in places like Flow conditions where it should be ISBLANK or null checks.

A Bot Action in Salesforce is a configurable step inside an Einstein Bot or Agentforce Bot dialog that does something beyond conversation: calls an Apex method, runs a Flow, fetches data from a Salesforce object, posts to an external system, transfers the conversation to a human agent, or attaches a Knowledge article to the response. Bot Actions are the bridge between the conversational layer (intent recognition, response templates) and the rest of Salesforce. A bot that only chats is a chatbot; a bot that chats then books an appointment, looks up an order, or escalates to support is one that uses Bot Actions to do real work. Bot Actions are configured inside Einstein Bot Builder (or its successor surface in Agentforce). Each Action has a type, a set of input variables (filled from prior conversation context), a set of output variables (used to shape subsequent responses), and a configuration specific to the action type. The bot's dialog nodes string Bot Actions together with conversational steps and decision logic so the whole conversation feels coherent. Most production Einstein Bot deployments invest more design effort in Bot Actions than in the dialog tree because the actions are where the actual customer value happens.

Bot Builder is the Salesforce Einstein Bot configuration UI, where admins design conversational chatbots that engage customers across Web Chat, Messaging, WhatsApp, Facebook Messenger, and other channels. The builder is a drag-and-drop canvas with Dialogs (conversation steps), Intents (what the customer is asking), Entities (data the bot extracts), and Actions (what the bot does in response, including invoking flows or Apex). It is the configuration layer above the Einstein Bot runtime engine. Bot Builder sits inside the Setup, Einstein Bots area. Each bot has Dialog flows that branch on customer input, hand off to live agents when conversations exceed bot scope, and call Salesforce Flow or Apex actions to query records, create cases, or update customer data. The output of Bot Builder is a Bot Version, which can be activated, deactivated, or rolled back. Multiple Bot Versions can exist per bot, allowing A/B testing or staged rollouts. The classic Bot Builder has been largely superseded by the Enhanced Bot Builder, which adds NLP improvements, multi-language support, and the new Conversation Repair feature.

A Bot Dialog in Salesforce Einstein Bots and Agentforce is the conversation tree node that defines what the bot says and does in response to a specific user intent. Each dialog has a name, a triggering intent (or set of intents), and a sequence of steps: message steps (the bot says something), question steps (the bot asks for input and stores the answer), rule steps (decision branches), action steps (calls a Flow, Apex, lookup, transfer), and navigation steps (jumps to another dialog). The dialog is the unit of conversation design; the bot is the collection of dialogs plus the intent model that routes user input to the right one. Bot Dialogs are configured inside Einstein Bot Builder. Designers structure dialogs to handle distinct customer intents (Check Order Status, Reset Password, Book Appointment), each one capturing the necessary context, doing the work through Bot Actions, and routing the conversation forward. A typical production bot has dozens of dialogs that interconnect through Navigate actions. Agentforce evolves the dialog model into Topics and Actions inside a reasoning engine, but the conceptual primitives (steps, variables, decisions, actions) carry across. Most of the design effort in any bot project is dialog design: how the conversation flows, what context it captures, and when it hands off.

Bot Performance is the Salesforce surface that reports on how an Einstein Bot or Agentforce Bot is doing across the metrics that matter operationally: total sessions, average session length, intent recognition rate, containment rate (the percentage of conversations the bot resolved without escalation), transfer rate, customer satisfaction, and per-dialog success metrics. The page lives inside Einstein Bot Builder under the Performance tab and complements custom CRM Analytics dashboards built on the underlying Bot session objects. Bot Performance is the dashboard sales operations and customer experience teams open every week to track whether the bot is paying back its investment. Bot Performance matters because bot value is invisible without measurement. A bot that resolves 80 percent of inbound chats saves significant agent time but only if the team can prove it; a bot that resolves 10 percent and frustrates customers needs urgent attention but only if the data surfaces the problem. The Performance tab provides the headline metrics; CRM Analytics or custom Lightning dashboards extend them with cohort analysis, intent-by-intent breakdowns, and longer-term trends. Mature bot programs treat Bot Performance as a weekly operational meeting input and tune the bot continuously based on what the metrics reveal.

A Bot Version in Salesforce is a numbered, immutable snapshot of an Einstein Bot or Agentforce Bot's configuration: dialogs, intents, training utterances, Bot Actions, channels, and entity definitions. Each saved revision of the bot increments the version. Only one version is Active at a time; that version handles live traffic. Other versions remain available as Inactive history that admins can clone, compare, or reactivate. Bot Versions are how bot programs iterate safely: build a new version in isolation, validate it, then activate it without disrupting the in-flight conversations on the previous version. Bot Versions matter because bot quality emerges through iteration. Intent training improves as the team learns what real customers say. Dialogs evolve as edge cases surface. New channels (Slack, WhatsApp, SMS) get added. Each change risks regression on the existing version, so most production teams build major changes as a new Bot Version, test it in a sandbox, then activate it in production during a planned window. The previous version stays available for one or two cycles in case rollback is needed. The version model is also how A/B testing of major changes works; one version handles half the traffic and another handles the other half, with performance metrics compared after a measurable window.

Branch Management in Salesforce most commonly refers to the Financial Services Cloud (FSC) capability that models retail banking branches as Salesforce records with associated staff, queues, operating hours, and customer relationships. Each branch is a Service Territory or custom Branch record that ties a physical location to its bankers, the customers it serves, the appointments it handles, and the local goals it carries. Branch managers see a dashboard of their branch's pipeline, customer interactions, and team activity; regional managers roll branches up into geographies for higher-level reporting. The phrase Branch Management also surfaces in Salesforce DX as the practice of managing Git branches in a Salesforce CI/CD workflow: feature branches, integration branches, release branches, and how they map to the org chain (dev, UAT, staging, production). Both meanings share the idea of a structured way to organise a unit of work or a place of work and route activity through it. FSC Branch Management is the dominant industry meaning; the DX branch-management practice is the dominant developer-tooling meaning. Disambiguate based on context: a banker reading Branch Management thinks of the FSC dashboard; a developer thinks of the Git workflow.

Briefcase in Salesforce is the offline data package that mobile users (especially Salesforce Field Service technicians and Salesforce Mobile App users on intermittent connectivity) download to their device so they can read, edit, and create records when the network is unavailable. The Briefcase contains the records, related lists, page layouts, and metadata the user needs to work on the records assigned to them. When connectivity returns, the changes sync back to the Salesforce server and conflicts are resolved through the platform's sync engine. Briefcase exists because real-world mobile work happens in places with no signal (rural service routes, hospital basements, manufacturing floors, airplanes). Without Briefcase, the mobile app reverts to read-only or offline-error when the network drops; with Briefcase, the user keeps working and the platform reconciles when they come back online. The data scope of a Briefcase is defined by Briefcase Builder, an admin tool that lets admins pick which records, related objects, and depth of relationships ship to the device.

Briefcase Builder is the Salesforce Setup tool where administrators design and publish Briefcase Definitions: the offline data packages mobile users download to work without network connectivity. Each Briefcase Definition specifies a primary object, a set of filters that scope which records of that object are included, a list of related objects with their own filters, and a target permission set or profile that determines which users receive the Briefcase on their device. The Builder produces a visual tree of the data scope and an estimated size before the definition is published. Briefcase Builder is the admin counterpart to the Briefcase feature itself. The runtime (Briefcase on the device) consumes whatever the Builder configured. Admins who design Briefcase Definitions carefully end up with field-service mobile experiences that work reliably offline at reasonable sync times. Admins who skip the design and ship over-broad Briefcases end up with bloated devices and 20-minute syncs.

Bucketing is the Salesforce report-builder technique of grouping records into named categories at report-runtime, without creating a custom field on the underlying object. You define a bucket field by picking a source field (Amount, Industry, Stage) and writing rules that map source values into named buckets: Amount under 10k becomes Small, 10k to 50k becomes Medium, 50k and above becomes Large. The bucket column then behaves like a real grouped field, driving subtotals, charts, and dashboard slices. Buckets live only inside the report definition. They do not write back to the source record, do not appear on list views, and cannot be referenced by automation or other reports. This makes them perfect for ad-hoc analysis when the source field is messy or the category logic is specific to one stakeholder's question, and useless for any case where the categorization needs to drive downstream behaviour.

Bulk API 2.0 is Salesforce's high-volume data processing API, designed for loading or extracting millions of records in a single job. It is the modern replacement for the original Bulk API (released in 2009) and the right tool whenever data volumes exceed what REST or SOAP API can handle efficiently. Data Loader, MuleSoft, Informatica, and most enterprise integration platforms use Bulk API 2.0 for bulk loads behind the scenes. A Bulk API 2.0 job is a multi-step lifecycle. The integration creates a job with the target object, operation (insert, update, upsert, delete, hardDelete, query), and content type. It uploads CSV data in chunks. It marks the job ready for processing. Salesforce processes the chunks in parallel, returns success and failure records, and reports completion through job status polling. The API handles the chunking, parallelism, and error reporting automatically; integration code just submits CSVs and reads results. Bulk API 2.0 dramatically simplified the original Bulk API's manual chunking and makes high-volume operations approachable without specialized integration tooling.

Bulk Data Load Jobs is the Salesforce Setup monitoring surface for Bulk API jobs: the asynchronous, high-volume data import and export operations that tools like Data Loader, MuleSoft, dbt, Fivetran, and custom integrations submit through the Bulk API. Each job processes records in batches (10,000 records per batch is the typical chunk size), runs in the background, and reports per-batch and per-record results. The Bulk Data Load Jobs page shows job status, throughput, errors, and lets admins abort a runaway job. The page is the operational visibility layer for any data movement that goes through the Bulk API. It is where admins discover when a nightly integration job failed at 3 AM, why a migration script is still running after 6 hours, and which records failed and why. Most production Salesforce orgs have at least one Bulk Data Load Job running at any given time during business hours and several scheduled overnight; the page is essential operational furniture for any org with serious data integration.

A Business Account in Salesforce is the standard B2B-style Account record representing a company, organisation, or institution rather than an individual. It is the default Account shape: a single Account record represents one company, and Contacts (individual people) hang off the Account through their AccountId field. In a pure B2B org, every Account is a Business Account; the distinction only becomes important when Person Accounts (the B2C variant) are also enabled. Then Business Account and Person Account coexist in the same org, and both record types share the Account object's underlying schema while differing in how Contact-side data is represented. Business Account is what Salesforce CRM was originally built around. The standard data model assumes Accounts are companies with Contacts, Opportunities, Cases, and Activity related to the company. Sales reps work Opportunities tied to Business Accounts. Service Agents work Cases tied to Business Accounts and the Contacts within them. Reporting rolls up to the Business Account. When a Salesforce org enables Person Accounts, the model bends to support direct-to-consumer scenarios; Business Accounts remain available for the B2B side of the business. Understanding the Business Account versus Person Account distinction is foundational to any data model decision in Salesforce.

Business Hours in Salesforce is the Setup feature that defines the operating windows the org uses for time-sensitive calculations: when escalation rules fire, when milestone clocks tick, when entitlement SLAs count down, when Omni-Channel routes to available agents, when chat channels accept inbound conversations. Each Business Hours record specifies a name, a time zone, and a weekly schedule of open and closed periods. Multiple Business Hours records can coexist; rules and entitlements reference whichever one applies to their context. Business Hours exists because almost every service workflow needs to know whether it is currently "in hours" or "after hours". A case opened at 2 AM should not have its 4-hour SLA tick down through the night when the team is not staffed. An escalation rule that fires after 1 hour of no response should only count business hours, not weekend hours. The single setting underpins much of the time-aware automation across Service Cloud and beyond, and getting it right is one of the cheapest ways to make automation behave the way users expect.