Salesforce terms starting with O

OAuth is the open-standard authorization framework Salesforce uses to grant external applications access to its APIs without sharing user passwords. OAuth 2.0 is the version Salesforce supports across REST API, SOAP API, Bulk API 2.0, Streaming API, Pub/Sub API, and Lightning Out. Every modern Salesforce integration starts with an OAuth flow that exchanges credentials for an access token, then uses that token as a bearer credential on subsequent API calls. Salesforce implements OAuth through Connected Apps, which act as the OAuth client configuration. The Connected App stores the client ID, client secret, allowed scopes, callback URLs, and security policies. The user (or admin pre-authorization) grants the app permission, the platform issues an access token, and the app uses the token to call the Salesforce APIs as that user. Salesforce supports several OAuth flows tailored to different integration patterns: Web Server flow for interactive user redirects, JWT Bearer flow for headless server integrations, Client Credentials flow for service accounts, User-Agent flow for SPAs, and Device flow for input-constrained devices.

OAuth and OpenID Connect Settings is the Salesforce Setup configuration that controls how the org acts as an OAuth 2.0 and OpenID Connect provider for external applications and how it consumes those protocols when acting as a client. The settings span several related areas: enabling OAuth scopes, configuring OpenID Connect discovery endpoints, setting token expiration policies, managing dynamic client registration, and controlling which OAuth flows are permitted. The page is the master control plane for federated authentication and authorization across the org. The settings interact closely with Connected Apps (which are individual OAuth client configurations) and Identity Provider settings (for SAML-based federation). Misconfiguration here affects every OAuth integration: token lifetimes that are too long create security risk; flows disabled here break integrations that rely on them; missing scopes prevent integrations from accessing data they need. Most B2B orgs leave the default settings in place; security-sensitive industries tighten beyond defaults based on regulatory requirements.

OAuth Custom Scopes is the Salesforce feature that lets administrators define org-specific OAuth scopes beyond the standard scopes (api, refresh_token, full, openid, etc.). Custom scopes enable fine-grained authorization where the standard scopes are too broad: a custom scope might grant access to specific custom objects, allow specific business operations, or represent a specific permission level within a custom integration. Once defined, custom scopes can be requested by Connected Apps just like standard scopes. The feature addresses a specific gap. Standard OAuth scopes are coarse-grained: api grants all object access; the only finer control comes through profile and permission set assignments on the user. Custom scopes let the integration declare its access intent at the token level, and the platform can enforce based on the scope. This is particularly useful for multi-tenant integrations where the same Connected App needs to request different levels of access depending on the deployment context.

An Object in Salesforce is the foundational unit of the data model: a table that holds records of a specific type, made up of fields that describe each record's attributes and relationships to other objects. Every business entity the platform tracks (a customer Account, a sales Opportunity, a Case from a customer, a Lead from marketing) lives as records on a Salesforce object. The platform ships with around 200 Standard Objects covering common business scenarios, and customers extend the data model by creating Custom Objects for entities specific to their business. Objects are the right place to start any Salesforce data design conversation because every other element of the platform (fields, validation rules, layouts, automation, sharing, reports, integrations) ultimately attaches to an object. The choice of which standard object to use, when to create a custom object, and how to model relationships between objects shapes everything downstream from the daily user experience to long-term analytics performance.

Object Manager is the central Setup area in Salesforce Lightning Experience for managing every standard and custom object in an org. From a single list, admins can open any object and configure its fields, relationships, page layouts, record types, validation rules, triggers, buttons and links, compact layouts, list views, and search layouts. It replaces the scattered per-object menus that Salesforce Classic kept under Setup > Customize > [Object Name]. The Object Manager opens through Setup > Object Manager and lists every object alphabetically, including standard objects like Account, Contact, Opportunity, Case, custom objects ending in __c, and external objects ending in __x. Filter by Object Label, API Name, or Type to find a specific object quickly. Inside each object, a left-nav menu lists every customization area, and a Schema Builder shortcut sits at the top right for ER-diagram-style visualization.

Object-Level Help is a Salesforce customization that replaces the default Help for this Page link on a custom object's pages with content the admin specifies. The override targets the help icon visible at the top right of an object's tab home, list views, edit pages, and detail pages. Admins point the help link to either a Visualforce page hosted in the org or to an external URL that opens in a new tab. The feature exists so internal documentation teams can replace Salesforce's generic help text with company-specific guidance: how this object fits into your business process, which fields are required for compliance, which integration syncs the record. It applies only to custom objects, not standard ones. For standard objects, the Help link always points back to Salesforce Help, regardless of any customization attempt.

Object-Level Security in Salesforce is the access control layer that determines whether a user can read, create, edit, or delete records of a specific object. The platform enforces object permissions through profiles and permission sets: each profile or permission set declares per-object permissions (Read, Create, Edit, Delete, View All, Modify All). A user's effective object permissions are the most permissive grant across their profile and assigned permission sets. Without the appropriate object permission, the user cannot access any record of that object regardless of sharing rules or record-level access. Object-Level Security is the broadest access control layer, sitting above Field-Level Security (which restricts specific fields) and Record-Level Security / Sharing (which restricts specific records). All three layers must permit access for the user to interact with a specific field on a specific record. Confusing these layers produces frequent misconfiguration: granting record sharing without object access produces nothing; granting object access without field access shows the record but blank fields. Understanding the layering is foundational to Salesforce security administration.

An object-specific action is a Salesforce action button that lives on a specific object's pages and operates in the context of a record from that object. Users see object-specific actions in the Highlights Panel, on the record's chatter publisher, in the action menu of the related list, and on mobile record pages. The action can create a related record with pre-filled fields, update the current record, log a call, send an email, post to chatter, or launch a screen flow. Object-specific actions differ from global actions in two ways: they only appear on pages for their parent object, and they inherit the record's context automatically. A Create New Case action on the Account object pre-fills the Case AccountId with the current Account; a Log a Call action attaches the Task to the record the user is viewing. Global actions, by contrast, appear in the global publisher and on the App Launcher and never know what record the user is looking at when invoked.

An OData producer is an external system that exposes data through the Open Data Protocol so Salesforce Connect can pull that data into Salesforce as external objects. OData defines a standard URL pattern, a metadata document describing entity types, and CRUD operations expressed as HTTP verbs (GET, POST, PATCH, DELETE). Once an OData producer is wired up, Salesforce treats the external data as if it were native: records appear in list views, on related lists, in SOQL queries, and on Lightning page components, without the data ever leaving the source system. Salesforce Connect supports OData 2.0 and OData 4.0 producers. The Connect adapter calls the producer's service endpoint on demand whenever a user or process reads or writes an external object, so storage stays in the producer's system and Salesforce only carries metadata and pointer records. This pattern is common for ERP, mainframe, and data-lake systems where the volume is too high or the data sensitivity too tight to replicate everything into Salesforce.

Omni-Channel is the routing and presence engine inside Service Cloud that delivers cases, chats, voice calls, messages, and any custom work to the right agent at the right time. It tracks each agent's presence (Available, Busy, Offline), their capacity (how many concurrent items they can hold), and their skills (the kinds of work they can handle). When a new work item arrives, Omni-Channel runs a routing algorithm against the available agent pool and pushes the work to the best match. The agent accepts or rejects, the system records the response time, and the work appears in the Service Console. Omni-Channel replaces older single-channel routing (Live Agent for chat, separate queues for cases) with a unified routing layer. It runs through three concepts: Service Channels (a definition of a kind of work, like Cases or Chats), Routing Configurations (how the work is routed: skill-based, least-active, most-available), and Presence Configurations (what counts as available and at what capacity). Together they let a Service Cloud team route incoming work intelligently across hundreds of agents without manual queue cherry-picking. Omni-Channel is the difference between a queue-based call center model and a modern routed contact center.

Omni-Channel Flow is the Salesforce feature that lets admins build Omni-Channel routing logic in Flow Builder, replacing the legacy queue-based assignment rules. The flow runs on each new work item before routing, examines fields, branches on conditions, and assigns Skills, target Queue, or Routing Configuration dynamically. The same flow can route a billing case to the Finance queue and a technical case to the Engineering queue based on Case Type, without separate assignment rules for each. Omni-Channel Flow is the recommended approach for any new Omni-Channel rollout since 2022. Queue-based routing still works for backward compatibility, but flow-based routing is where Salesforce is investing. The flow has access to the full record context (Case, Lead, Chat), record-related data via Get Records elements, custom Apex actions, and a final Route Work action that hands control to the routing engine. This is a significant upgrade over the old declarative pattern where logic was scattered across assignment rules, escalation rules, and Process Builder.

Omni-Channel Home is the supervisor-facing Lightning page that surfaces real-time Omni-Channel operations: who is online, what they are working on, what is waiting in queue, and which work items are overdue. It is the supervisor's command center for managing a service team mid-shift. The page combines Live Agent Status, Backlog metrics, Wait Time, Service Channel performance, and AgentWork history into one screen so supervisors can spot bottlenecks and rebalance load without digging through reports. Omni-Channel Home is built on the Omni Supervisor app, accessible to users with the Omni Supervisor permission set. It is not a single page but a small bundle of standard Lightning components (Agent Status, Queues Backlog, Skills Backlog, Recent Activity) that supervisors can rearrange in their personal layout. The data is live: status changes, item assignments, and queue depth update within seconds. This is what differentiates supervisor visibility in Omni-Channel from legacy report-based supervision; you can see and act in the moment instead of waiting for end-of-day reports.

Omni-Channel Routing is the Service Cloud feature that pushes work items (Cases, Leads, Chats, Messages, Voice calls, custom records) to service agents based on agent availability, skill match, capacity, and channel priority. Instead of agents pulling work from queues (the legacy pattern), Omni-Channel pushes the next available item to the agent best suited to handle it. Routing happens continuously: as soon as an agent finishes a case, the system assigns the next one. Omni-Channel runs on Salesforce's routing engine, which evaluates Service Channel definitions (Case, Chat, Message), Routing Configurations (how work is prioritized), Presence Statuses (whether an agent is available for which channels), and Skill-Based Routing (matching item requirements to agent abilities). The combination produces a routing decision per work item per agent. Agents see incoming work in the Omni-Channel widget (a floating panel in the Service Console) and accept, decline, or auto-accept based on configuration. The model scales from small support teams to thousands of agents across multiple lines of business.

Omni-Channel Settings is the Setup page that enables and globally configures Salesforce's Omni-Channel work routing engine. From this single page, admins switch Omni-Channel on for the org, control whether routing pushes work to agents in console or in the standard interface, define decline reasons, set the default service channel behavior, and configure secondary routing options like Omni Supervisor and Skills-Based Routing. The page sits under Setup > Omni-Channel > Omni-Channel Settings and acts as the master switch. Without it enabled, every other Omni-Channel feature (queues, service channels, presence configurations, routing configurations) is invisible and the omni utility item does not appear in any app. Once enabled, the page acts as a control center: turn on skills-based routing, external routing, secondary routing priority, and the various supervisor features from here.

OmniScript is a Salesforce Industries (formerly Vlocity) tool for building guided, multi-step digital interactions. It is a low-code wizard-style designer that strings together input forms, decision steps, lookups, integration calls, and document generation into a single end-user workflow. Customer service agents, self-service portal users, and call center reps walk through an OmniScript to complete tasks like switching a wireless plan, filing an insurance claim, onboarding a new patient, or processing a loan application. OmniScript runs as a Lightning Web Component on Lightning record pages, Experience Cloud sites, and Salesforce mobile. It calls Integration Procedures for server-side logic, DataRaptors for data shaping, FlexCards for visual surfaces, and Apex Remote Actions for custom logic. Underneath, every OmniScript is a JSON definition stored in custom objects (OmniScript__c and related) that the runtime interprets. The product ships with every Salesforce Industries cloud and is a defining feature of the Industries stack.

OmniStudio is the Salesforce declarative development toolkit originally built by Vlocity (acquired by Salesforce in 2020) for building guided customer experiences, complex data orchestration, and document generation without writing Apex. It ships standard with Industries Clouds (Financial Services Cloud, Health Cloud, Communications Cloud, Energy and Utilities Cloud, Public Sector Solutions) and is available as an add-on for Sales Cloud and Service Cloud. The toolkit includes OmniScript (guided flows), DataRaptor (data mapping), FlexCard (presentation layer), Integration Procedures (server-side orchestration), and Document Generation. OmniStudio targets developer-grade complexity through admin-friendly tools. Where Salesforce Flow handles linear automation, OmniStudio handles branching guided journeys with sophisticated UI, multi-step data transformations, and external system orchestration. A loan application that pulls credit data from three external systems, calculates risk, displays a custom UI per applicant tier, and generates a PDF disclosure document is the canonical OmniStudio use case. Salesforce Flow alone would struggle; pure Apex would take 10x the development time.

An on-demand document in Salesforce is a PDF, Word, or other formatted file generated at runtime from data in the org, in response to a user action or automated trigger. The pattern shows up across CPQ (quotes and proposals from the Document Designer), OmniStudio (Document Template Source for guided journeys), Service Cloud (case correspondence), and Sales Cloud (mail merge templates). The shared idea is that the document does not exist as a stored file until someone needs it; the system builds it from a template plus current data on demand. This approach contrasts with static documents that are uploaded once and referenced repeatedly. On-demand generation guarantees that every document reflects the latest data: a quote re-generated five minutes after a price change shows the new price; a case correspondence regenerated after a status update shows the new status. The trade-off is server cost and a few seconds of latency on each generation. Salesforce offers several engines (Conga, Salesforce Document Generation, OmniStudio Document Template, Visualforce PDF) so admins can pick the right tool for the use case.

A one-to-many relationship in Salesforce is a data model pattern where one parent record can have many related child records, but each child record belongs to exactly one parent. The relationship is implemented through a lookup or master-detail field on the child object that points to the parent. Common examples are Account to Contact (one Account, many Contacts), Account to Opportunity (one Account, many Opportunities), Opportunity to OpportunityLineItem (one Opportunity, many line items), and Case to CaseComment. Salesforce supports two flavors of one-to-many: lookup (loose coupling, child can exist without parent, parent deletion does not cascade) and master-detail (tight coupling, child is owned by parent, parent deletion cascades to children). Choose lookup for optional relationships where children sometimes have no parent; choose master-detail when the child has no meaning without the parent and ownership and sharing should inherit from the parent.

Open CTI is the Salesforce framework that lets third-party computer-telephony integration vendors connect their phone systems to Salesforce. CTI vendors like Genesys, Five9, NICE, RingCentral, and AWS Connect build softphones that run inside the Salesforce UI as a Lightning component or Visualforce page in the utility bar, screen-pop inbound calls onto the matching record, log call activity automatically, and feed call metadata back into Salesforce for reporting. Open CTI replaced the older CTI Toolkit (which required a Windows-only desktop installer) with a pure-browser JavaScript API. Today's softphones run as web components, communicate with the phone system through standard browsers, and update Salesforce records using the Open CTI API. Every major contact-center platform ships a Salesforce integration built on Open CTI; for new contact center implementations, this is the default integration pattern unless the vendor exclusively supports Service Cloud Voice.

An operator in Salesforce is a symbol or keyword that defines how values are combined, compared, or evaluated inside expressions. Operators appear everywhere users build conditions or calculations: formula fields, validation rules, workflow criteria, Flow conditions, SOQL WHERE clauses, report filters, and SAQL queries in CRM Analytics. The exact syntax varies by context, but the categories stay consistent: math operators (+, -, *, /), comparison operators (=, !=, <, >, <=, >=), logical operators (AND, OR, NOT), string operators (& for concat), and the more specialized SOQL operators (LIKE, IN, INCLUDES). Mastering operators is essential for anyone writing Salesforce automation. A misplaced equals sign in a validation rule blocks every record from saving. An ambiguous AND vs OR in a Flow condition routes users down the wrong branch. SOQL LIKE without proper wildcard placement returns zero rows. The platform exposes operators through pickers and editors that hide some of the syntax, but understanding the underlying language pays off whenever the picker cannot express what you need.

An Opportunity is a potential sale in Salesforce, tied to an Account and tracked through a sequence of Stages until it closes Won or Lost. The Opportunity object holds the amount you expect to book, the date you expect to book it, the probability assigned to that stage, the products attached to the deal, and the roles that the Contacts on the buying committee play. Almost every revenue forecast a Salesforce-using company produces traces back to a query against Opportunity. Opportunities are how Salesforce decides where to put the dollar signs. Pipeline reports sum Amount across open Opportunities. Forecasts weight that sum by Stage probability and segment it by Close Date. Quota attainment compares Amount on Closed Won deals to a target. Commission calculations key off Amount, Stage, and Close Date. Bad Opportunity hygiene rolls forward into every executive review for the rest of the quarter, which is why Sales Operations spends so much time auditing the same fields week after week.

An Opportunity Contact Role in Salesforce (OpportunityContactRole in the API) is a standard junction object that links a Contact to an Opportunity, capturing each person's role in the deal - Decision Maker, Economic Buyer, Influencer, Champion, Evaluator, or any custom value the org defines. Each Opportunity Contact Role record holds a ContactId, an OpportunityId, a Role picklist, and an IsPrimary flag (only one Contact per Opportunity can be primary). Contacts attached through Opportunity Contact Roles do not have to belong to the Opportunity's Account - this allows complex selling situations where partners, influencers, advisors, or third-party evaluators participate in a deal without being employees of the buying organization. Opportunity Contact Roles drive several core sales features: campaign-influence reporting (which Contacts at which Opportunities came from which Campaigns), deal-team visibility, win/loss analysis by buyer persona, and account-based marketing attribution. They are required prerequisites for many advanced Sales Cloud features including Salesforce Inbox auto-association and Pardot/Account Engagement-driven attribution.

An Opportunity Line Item in Salesforce (OpportunityLineItem in the API) is a standard child object that represents a single Product included on an Opportunity, capturing the Quantity, UnitPrice, ListPrice, Discount, and TotalPrice for that line. Each Opportunity Line Item links to a parent Opportunity through OpportunityId and to a Product through PricebookEntryId - meaning an Opportunity Line Item always sits on top of a specific Price Book Entry and inherits its currency, list price, and product reference. The sum of all Opportunity Line Items' TotalPrice values populates the Amount field on the parent Opportunity (when "Use Product-Based Pricing" is enabled), which then drives forecasts, pipeline reports, and territory roll-ups. Opportunity Line Items snapshot pricing at insert time - subsequent changes to the underlying Price Book Entry do not propagate, so historical pipeline values remain stable as price lists evolve.

Opportunity Settings is the Salesforce Setup page that controls the org-wide behavior of the Opportunity object. From a single screen, admins enable or disable features like Opportunity Splits, Big Deal Alerts, automatic creation of Opportunity Products on conversion, Update Reminders for stagnant Opportunities, and Opportunity Contact Roles defaults. The page sits under Setup > Opportunities > Opportunity Settings and is the central control panel for sales-pipeline configuration. These settings shape how the sales team works without touching individual Opportunity records. Turning on Opportunity Splits, for example, enables crediting revenue across multiple sales reps; turning on Big Deal Alerts triggers automatic email notifications to a designated recipient when a deal above a threshold reaches a specified stage. Each switch is independent, but several settings depend on broader org features (Multi-Currency, Forecasting) being enabled first.

An Opportunity Team is a group of Salesforce users who share access to a single Opportunity record. Each team member has a defined role (Account Manager, Sales Engineer, Executive Sponsor, Pre-Sales Lead) and a specific access level on the deal. The team is how Salesforce models the fact that one Opportunity is often worked by five or ten people, even though only one user actually owns the record. Behind the scenes the team lives on the OpportunityTeamMember object, a junction between User and Opportunity. Adding a user to the team creates a row in OpportunityShare with the chosen access level. That share row is what actually grants visibility; the team is the friendlier UI on top of it. Default Opportunity Teams let a rep pre-load the same supporting cast onto every new deal they own, so the Sales Engineer never has to be added manually three times a week.

An Opportunity Team Member in Salesforce (OpportunityTeamMember in the API) is a standard junction object that adds a User to an Opportunity Team and grants that user configurable access to the parent Opportunity record. Each Opportunity Team Member record holds an OpportunityId, a UserId, a TeamMemberRole picklist (Account Manager, Pre-Sales Consultant, Sales Manager, Sales Rep, etc.), and an OpportunityAccessLevel field set to Read or Edit. Opportunity Team Members are the deal-level equivalent of Account Team Members - they let multiple users collaborate on a specific deal with shared visibility and edit access, without affecting access to other deals on the same Account. This matters most in orgs where Opportunity organization-wide defaults are Private or Public Read Only, requiring an explicit grant for non-owner users to participate in deal work. Default Opportunity Teams (configured per User in Personal Settings) auto-populate Opportunity Team Members on every new Opportunity the user creates, so a sales rep's standard supporting cast (SE, SDR, manager) follows them across every deal automatically.

Opt Out of Customer Data Access is a Salesforce Setup option through which customers can declare that Salesforce employees, including support engineers, should not access their data for troubleshooting, optimization, or any other purpose without explicit per-incident customer authorization. The opt-out is a contractual and operational commitment: Salesforce-internal processes that would normally allow employee access (support escalations, infrastructure troubleshooting, security incident response) are restricted to require customer approval before any access occurs. The feature exists for customers in regulated industries or with internal compliance policies that mandate strict control over who can access customer data. Without opt-out, Salesforce Support engineers can access customer orgs to troubleshoot support cases (with customer-granted Login Access). With opt-out, that pathway is constrained: the customer must explicitly authorize each access, with the authorization itself audited. The trade-off is operational friction in support scenarios for the assurance of compliance posture.

An Order in Salesforce is the transactional commitment to deliver products or services to a customer. The Order object holds the AccountId, an optional ContractId (the agreement the Order falls under), an EffectiveDate (when the Order takes effect), a Status (Draft, Activated, and any custom values your org adds), and one or more OrderItem records that detail what is being delivered. Orders sit downstream of Quotes and Contracts in the typical sales motion, and they are the record that downstream fulfillment systems (ERP, provisioning, billing) usually integrate with. The Order object is the bridge between Salesforce and your ERP. Most Salesforce orgs treat Order as a mirror of what the ERP shows: the CRM-side view of a fulfillment commitment whose real lifecycle lives in another system. Some orgs use Order as the system of record for the commitment, then push to ERP through middleware (MuleSoft, Boomi, Workato) on Activation. Either way, the Order record carries enough detail for service teams, customer success, and account managers to answer "what did this customer order" without leaving Salesforce. The Order is also the typical trigger point for Asset creation, billing initiation, and the renewal clock that drives the next sales cycle.

An Order Product in Salesforce (OrderItem in the API) is a standard child object that represents a single line item on an Order - one Product, one quantity, one price. Each Order Product has a parent Order through the OrderId field, a reference to the Product through PricebookEntryId, and a copy of pricing details at the moment the line was created: Quantity, UnitPrice, ListPrice (snapshot from the Price Book Entry), TotalPrice (calculated), and ServiceDate. Order Products are typically created in one of three ways: automatically when a closed-won Opportunity is converted to an Order (using Salesforce's built-in "Create Order from Opportunity" action), manually added by a sales-ops user as part of order entry, or programmatically through Apex or an integration. Like Quote Line Items and Opportunity Line Items, Order Products snapshot pricing at insert time - subsequent changes to the underlying Price Book Entry do not propagate.

Order Settings is the Salesforce Setup configuration that controls behaviors of the standard Order object: whether the Order object is enabled, whether negative quantities are allowed on Order Products, whether orders are required to have a contract reference, and how the Reduction Order capability (returns and partial fulfillment) functions. The Order object is part of the standard Sales Cloud data model, sitting alongside Opportunity and Contract as the artifact representing committed customer commitments after the deal closes. Most organizations using Salesforce for commerce or post-sale fulfillment enable Orders and configure the settings during initial Sales Cloud rollout. Once enabled, Orders typically participate in workflow automation around fulfillment, billing, and revenue recognition. The Settings page is small but each toggle has downstream implications: enabling negative quantities affects how returns are recorded; requiring contract references affects how Orders flow from Opportunity. Plan changes deliberately because mid-life setting changes can break in-flight automation.

An Org (short for organization) is a single tenant instance of the Salesforce platform that contains a company's data, metadata, users, and customizations. Every Salesforce customer has at least one org, which represents the live system of record for their CRM data. The org has a unique 15-character organization ID, lives in a specific Salesforce data center or Hyperforce region, and operates as an isolated unit in the multi-tenant architecture that powers the platform. Most customers operate one production org plus several sandbox orgs (Developer, Developer Pro, Partial Copy, Full Copy) used for development, testing, training, and pre-release validation. The relationship between production and sandboxes is hierarchical: sandboxes are refreshed from production, customizations flow from sandbox to production through deployment tooling, and the production org is the source of truth for live business data. Understanding the org concept is foundational because every Salesforce conversation eventually circles back to which org someone is referring to.

An Org Limit in Salesforce is an organization-level resource allocation that defines the maximum resources available to the entire org, such as API request limits, storage limits, or data limits. Org Limits are tracked via the Limits API and are enforced to ensure platform stability in the multi-tenant environment. They are distinct from Governor Limits, which are per-transaction runtime constraints on Apex code execution.

An Org-Wide Default (OWD) is the Salesforce baseline access level for every object, defining the minimum visibility any user has to any record they do not own. Each object has an OWD setting at one of several levels: Private (only the owner sees), Public Read Only (everyone sees but only owner edits), Public Read/Write (everyone sees and edits), Public Read/Write/Transfer (everyone can also transfer ownership), or Controlled by Parent (inherits from a parent object). OWD is the foundation of the Salesforce sharing model; other mechanisms (sharing rules, manual shares, team access) can only widen access from the OWD baseline, never restrict. OWD is the single most consequential security decision in any Salesforce implementation. A Public Read/Write OWD on Account means every user with object access to Account sees every Account in the org. Tightening from Public to Private retroactively restricts access on every existing record, which can break downstream automation, reports, and integrations that assumed broad visibility. Loosening from Private to Public exposes data that was previously restricted. Plan OWD changes deliberately and test extensively before applying in production.

In Salesforce Web-to-Lead, leads generated when prospects find your company through a search engine and submit a web form, tracked as a lead source to measure search engine marketing effectiveness.

An Organization in Salesforce, commonly shortened to Org, is a single customer's instance of the Salesforce platform. Each org contains the customer's data records, metadata configurations, custom code, installed packages, users, sharing settings, and integration connections, uniquely identified by an Organization ID (a 15- or 18-character globally unique identifier starting with 00D). Every Salesforce customer has at least one production org plus one or more sandboxes for development, testing, and training. The Organization concept is foundational because every Salesforce conversation eventually circles back to which org someone means: production, a specific sandbox, a developer scratch org, or a different customer's org entirely. Organizations operate as isolated tenants on Salesforce's multi-tenant infrastructure, with the platform enforcing strict separation between them. Inside an organization, the configuration choices made by admins (sharing model, page layouts, automation, integrations) define the customer's specific Salesforce experience. The same product can produce very different experiences across two different organizations because the configuration layers on top are so flexible.

An Organization-Wide Address (or Org-Wide Email Address) is a Salesforce-configured shared email address that authorized users can choose as the From address on outbound mail instead of their personal Salesforce email. Common examples: billing@yourcompany.com, support@yourcompany.com, hello@yourcompany.com. The address must be verified through a confirmation email before becoming available, and access is restricted to specific profiles or all users based on configuration. The feature lets multiple users send mail under a single branded address without sharing email account credentials. The capability is essential for any organization where outbound mail should appear from a consistent business address rather than individual reps. Sales teams use shared sender addresses for company-branded outreach; support teams send Case-related mail from a support@ address; billing teams send invoices from billing@. Without Org-Wide Addresses, every send appears from the individual user's address, which is unprofessional in many contexts and creates trust issues (customers may not recognize the sender).

Organization-Wide Defaults (OWD) are the Salesforce baseline access settings that establish minimum visibility for every object in the org. Each object has its own OWD, set to Private, Public Read Only, Public Read/Write, Public Read/Write/Transfer, or Controlled by Parent. The collection of all object OWDs is the org's sharing model foundation: every other sharing mechanism (sharing rules, manual shares, role hierarchy, team access) builds on top of OWD by widening access, never restricting below it. OWD is configured under Setup > Security > Sharing Settings. The decision is the most consequential security choice in any Salesforce implementation. A misconfigured OWD on a sensitive object (HR data, customer financial data) exposes records to inappropriate users. Conversely, an over-restrictive OWD on a collaboration-needed object (Account, Opportunity) blocks legitimate access and forces administrators to build extensive sharing rules to compensate. Plan OWD per object based on data sensitivity, user populations, and the access patterns the business genuinely needs.

In Salesforce Service Cloud and CTI integrations, a phone call initiated by an agent to a customer, which can be placed via click-to-dial functionality from contact or case records within the Service Console.

A change set created in a Salesforce org (typically a sandbox) to send metadata components to another connected org (typically production), containing customizations like fields, objects, and classes for deployment.

An Outbound Message is a SOAP-based notification Salesforce sends to an external endpoint when a Workflow Rule or a Process Builder action fires. The message contains a fixed set of fields from the triggering record, formatted as SOAP XML, and is POSTed to a configured URL. The receiving endpoint acknowledges with a SOAP response; if Salesforce does not get the ack, it retries on a back-off schedule for up to 24 hours. Outbound Messages are the legacy declarative integration pattern, predating Flow, Platform Events, and Change Data Capture by a decade. Outbound Messages live in Setup, Workflow Actions, Outbound Messages. They are still supported but are no longer the recommended pattern for new integrations. Salesforce documents Platform Events, Change Data Capture, and Apex callouts as the modern alternatives. Many production orgs still run Outbound Messages from the 2010s era; they work reliably and require no code, which is why they have survived multiple generations of platform changes. New integrations should default to Platform Events or REST callouts; existing Outbound Messages can stay until a migration project justifies the work.

Outlook Integration and Sync is the Salesforce Setup area where administrators configure how Salesforce connects to Microsoft Outlook. The integration has two complementary pieces: the Salesforce sidebar embedded in the Outlook client (the user-facing integration) and the server-side Einstein Activity Capture or older Salesforce for Outlook sync engine (the background email and calendar synchronization). Together they let users work in Outlook while keeping the Salesforce records updated with relevant activity automatically. The integration is one of the most heavily used productivity features in Sales Cloud because most sales reps still live in Outlook for their email and calendar workflow. Forcing reps to switch to Salesforce-native email and calendar is rarely realistic; meeting them where they already work and bringing Salesforce context into Outlook is the path of least resistance for adoption. The Setup configuration controls what data flows in which direction, how often the sync runs, and which users have which features enabled, with thoughtful defaults that handle the majority of straightforward deployments.

In the Salesforce console (Classic), a detail view that opens as a floating panel on top of the current page, allowing agents to view or edit record details without navigating away from their current work context.

The Salesforce user assigned as the owner of a specific record, who has full access to that record and whose ownership determines the record's position in the role hierarchy for sharing and reporting purposes.

In Salesforce Forecasting, the forecast amount that includes only the opportunities owned directly by a specific user, excluding any rollup amounts from subordinates in the forecast hierarchy.

Owner Only Quantity is a Salesforce Collaborative Forecasting measure that shows the forecast quantity (or revenue) derived exclusively from records the user directly owns, excluding the rollup contribution from anyone reporting to that user in the forecast hierarchy. The figure isolates an individual contributor's pipeline from their team's pipeline, which matters for managers who carry their own quota in addition to their team's quota. The measure appears alongside its counterpart Quantity (or Amount) on the forecast page. The combined view answers two distinct questions: how is the manager performing on their personal book of business, and how is the entire team rolling up. Owner Only is the personal view; Quantity is the team view. Both are computed at every level of the forecast hierarchy, so a director sees Owner Only for their own deals and Quantity for everyone reporting up through them. The data underneath is the same Opportunity records; the difference is whether subordinate-owned records are included in the sum.