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.

Bulk API is the Salesforce REST-based interface built for moving large volumes of records in and out of an org. It handles insert, update, upsert, delete, hard delete, and query operations against datasets that run from a few thousand rows up to hundreds of millions. The work happens asynchronously. A client submits a job, Salesforce processes the records in the background, and the client polls for the results rather than waiting on a single synchronous response. Bulk API 2.0 is the modern version and the one Salesforce recommends for new work. The original Bulk API (often called 1.0) made the client split data into batches by hand. Bulk API 2.0 removes that step. You upload one CSV file, Salesforce decides how to batch it internally, and you retrieve successful and failed rows when the job finishes. Salesforce guidance puts any operation above roughly 2,000 records in Bulk API territory.

A Best Answer in Salesforce is the single reply to a Chatter Question that the person who asked, a Chatter or site moderator, or a Salesforce administrator marks as the definitive resolution. The marked reply gets a check-mark indicator, and a copy of it is pinned to the top of the answer list so anyone reading the thread spots the resolution right away. Only one answer per question can hold Best Answer status at a time. Best Answers work the same way inside a Chatter feed, on a record, in a group, and on an Experience Cloud site that has Chatter Questions enabled. The question is a feed item, the replies are comments, and the Best Answer is the comment carrying the Best Answer flag. On a self-service site, this small flag does a lot of work: it turns a messy thread into a clean, searchable answer, and it feeds the reputation system that keeps your best community members answering.

A Best Case Amount is the value shown in the Best Case column of Salesforce Collaborative Forecasts. It sums the Amount of open Opportunities whose Stage maps to the Best Case forecast category for a given period and owner, then rolls that total up the forecast hierarchy and applies any adjustments. Sales reps and managers read it as the deals they believe are more likely than not to close, even when they are not yet willing to commit to them. Best Case sits between Pipeline and Commit on the Forecasts tab. Pipeline holds everything still open, Commit holds the conservative number the rep will stand behind, and Best Case holds the reasonable upside in between. The same value is exposed on the read-only ForecastingItem object, so it also appears in reports and dashboards. Which Stages feed Best Case is controlled by the Stage-to-Forecast-Category mapping that admins set in Setup, which makes the field only as trustworthy as that mapping.

A Beta Managed Package is a managed-package version that a Salesforce ISV or developer has created or uploaded but designated as Beta instead of Released. A Beta version installs only in Developer Edition orgs, sandboxes, and Trial orgs. It cannot install in a production org. Salesforce treats Beta as the pre-release tier, the version you hand to internal QA and pilot testers before you commit to a Released build that customers run for real. This rule exists to keep unfinished work out of production. In second-generation packaging, every new package version is created as Beta by default until you promote it. In first-generation packaging, you choose the Managed - Beta release type when you upload. Either way the trade is the same. Beta versions stay flexible and disposable, but they carry a hard restriction: they cannot be upgraded in place, and they cannot reach production until you cut a Released version.

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 relationship field that holds no value. The record points at no parent, so the field reads as null in SOQL, shows as empty in the user interface, and returns true for ISBLANK in formulas. Because a lookup relationship can be defined as optional, an empty lookup is a fully valid state rather than an error. The official platform docs note that a lookup links two objects much like a master-detail relationship, except it does not require a parent and does not support sharing or roll-up summaries. A blank lookup can happen by design or by accident. The relationship may be genuinely optional, in which case the empty value is expected. Or a field that should always be set was left empty by an import, an API call, or a user who skipped it. The two cases look identical in the data but mean very different things. Deciding which one you have, and enforcing it, is a core part of Salesforce data hygiene. Quietly tolerating empty lookups in fields that the business treats as required is one of the most common sources of long-term data quality problems.

Boolean operators are the logical connectives AND, OR, and NOT that join two or more conditions into a single true-or-false expression. In Salesforce they sit at the heart of almost every place the platform tests a condition: validation rule formulas, formula fields, Flow decision elements, report and list view filters, SOQL WHERE clauses, SOSL searches, and approval process entry criteria. The meaning matches ordinary Boolean algebra. AND is true only when every joined condition is true. OR is true when at least one condition is true. NOT flips a true to false and a false to true. The reason these three small words matter so much is that they turn a flat list of conditions into an actual business rule. "Stage equals Closed Won and Amount is greater than 100000" is two checks joined by AND. "Industry is Healthcare or Industry is Life Sciences" is two checks joined by OR. The catch in Salesforce is that each surface writes the same logic with different syntax. Formulas use function calls like AND() and OR(). SOQL and Flow use the words spelled out. Apex uses the symbols && and ||. The logic is identical, but the grammar shifts, so knowing the operator across every tool is a foundational admin and developer skill.

A Bot Action is a configurable step inside an Einstein Bot dialog that does work beyond conversation. It calls Apex, runs a Flow, searches or creates a Salesforce record, sends data to an external API, transfers the chat to a human agent, or returns a Knowledge answer. Bot Actions are the link between the conversational layer, where the bot recognizes intent and replies, and the rest of Salesforce, where the real business logic lives. A bot that only sends messages is just a script. A bot that looks up an order, books an appointment, or opens a case uses Bot Actions to do it. You add an action by dragging an action component onto the dialog canvas in Einstein Bot Builder, naming it, then mapping its input and output variables. The dialog chains that action together with messages, questions, and rules so the whole exchange feels like one coherent conversation.

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 is the conversation building block inside Salesforce Einstein Bots. It is a single segment of a conversation, such as a welcome, a main menu, an order-status lookup, or an identity check, built from an ordered list of steps that decide what the bot says and does. Each dialog can be tied to a dialog intent that the natural language model is trained to recognize, so when a customer types a request, the matching dialog fires. The dialog is the unit you design, test, and reuse; the bot is the set of dialogs plus the intent model that routes input to them. A dialog is assembled in Einstein Bot Builder from four step types: Outbound Messages, Questions, Actions, and Rules. Designers drag these components onto the canvas to model the back-and-forth of a real conversation, capture the data the bot needs, do the work through Actions, and route the customer onward. A production bot usually holds dozens of dialogs that link together and share common subroutines. Salesforce now positions Agentforce as the next step, where the Atlas reasoning engine chooses Topics and Actions instead of following a fixed tree, but the underlying ideas of steps, variables, decisions, and bound work still apply.

Bot Performance is the set of reports and dashboards in Salesforce that show how an Einstein Bot or Agentforce agent is doing on the numbers that matter operationally. It covers session volume, engaged versus unengaged sessions, dialog completions and cancellations, escalations and transfers to a human, intent recognition rate, entity extraction rate, and goals completed. Salesforce ships roughly 40 prebuilt reports in the Einstein Bot Report folder, and you can extend those with a CRM Analytics app built on the underlying bot session data. This surface exists because a bot's value is hard to see without measurement. A bot that handles most inbound chats saves real agent time, but only if the team can show it with data. A bot that frustrates customers needs attention fast, and the reports are where that problem becomes visible. Service and customer experience teams open Bot Performance on a regular cadence to decide what to tune next.

A Bot Version in Salesforce is a numbered, saved snapshot of one Einstein Bot or Agentforce agent's configuration. In the Metadata API this is the BotVersion type, and it holds the conversation pieces that change as you build: the dialogs, the conversation variables, the welcome and transfer messages, the entity references, and the intent training that the version uses. A single bot can have many versions over its life, but only one version is active at a time. That active version is the one handling live customer or employee conversations. The parent Bot record holds the settings that are shared across every version, such as the bot type and whether private data is logged. Each BotVersion holds the parts you iterate on. This split is what lets a team build and test a new version while the current one keeps answering traffic. You activate the new version when it is ready, the previous version steps down to inactive, and you still have it on hand if you need to switch back.

Branch Management is the practice of organizing and controlling Git branches that hold Salesforce metadata as a team moves work from a sandbox or scratch org toward production. A branch is a named line of development in a version control repository. Branch management decides how many branches exist, what each one represents, who can write to them, and how changes flow from a feature branch into an integration branch and finally into the branch that maps to production. On the Salesforce platform this practice is built into DevOps Center, which connects a GitHub repository to a release pipeline and manages branches for you. It also underpins Salesforce DX, where the Org Development and Package Development models both store metadata in a source control repository. Strong branch management is what keeps parallel admin and developer work from colliding, gives every change a review checkpoint, and produces a clean audit trail of who changed what and when.

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 Account record that represents a company, organisation, or institution rather than a single individual. It is the default shape of the Account object. One Account record stands for one company, and the people who work there are stored as separate Contact records linked through the Contact's AccountId field. In a business-to-business org, every Account is a Business Account by definition. The term only becomes meaningful once Person Accounts, the consumer variant, are switched on in the same org. At that point Business Accounts and Person Accounts live side by side on the one Account object, separated by record type. A Business Account keeps the classic company-plus-contacts structure, while a Person Account folds an account and a contact into a single record for an individual. Knowing which model an org uses is the first decision behind almost every Account, Contact, and Opportunity choice you make.

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.