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 a page in Salesforce Setup that controls which OAuth 2.0 authorization flows your org permits and how strictly it enforces them. You reach it by entering OAuth in the Quick Find box and selecting OAuth and OpenID Connect Settings. The page is org-wide. It sets the baseline for every connected app and external client app that authenticates against your org, so the toggles here decide whether older, riskier grant types can run at all. The page carries four controls: Allow OAuth User-Agent Flows, Allow OAuth Username-Password Flows, Allow Authorization Code and Credentials Flows, and Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows. Salesforce treats the user-agent and username-password flows as insecure and recommends blocking them. Because Salesforce also acts as an OpenID Connect provider, the same area of Setup ties into the OpenID Connect discovery, token introspection, revocation, and dynamic client registration endpoints that external apps rely on.

An OAuth custom scope is a permission you define in Salesforce to fine-tune what an external client app or connected app can access during an OAuth flow. The standard scopes (api, full, refresh_token, openid, web) are deliberately broad. A custom scope lets you describe a narrower slice of access, often access to a resource that lives outside Salesforce, and have that intent carried inside the issued access token. The feature exists for a specific arrangement. Salesforce acts as the OAuth authorization provider, but the protected data sometimes sits behind an external API gateway that Salesforce knows little about. You create a scope such as order_status, Salesforce validates the user and stamps the scope onto the token, and the external gateway reads that scope to decide what to return. The user sees the scope description on the approval page and consents to it explicitly.

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 decides whether a user can read, create, edit, or delete records of a specific object such as Account, Case, or a custom object. The platform checks object permissions first, before it ever looks at sharing or fields. If a user has no object access, every record of that type is invisible to them, no matter how generous the sharing rules are. Object permissions are declared on profiles and permission sets, and a user's effective access is the most permissive grant across the one profile and all assigned permission sets. This layer sits above Field-Level Security (which controls individual fields) and Record-Level Security (which controls which specific records a user sees). All three must allow access for a user to work with a given field on a given record, so knowing where each layer applies is the foundation of 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 in Salesforce Service Cloud that turns the Omni-Channel work routing engine on for an org and holds its global, org-wide options. From this one page an admin enables Omni-Channel itself, switches on Enhanced Omni-Channel Routing, allows skills-based and direct-to-agent routing, sets the work-item session expiration, and defines the decline reasons agents pick when they reject a work assignment. You reach it at Setup > Feature Settings > Service > Omni-Channel > Omni-Channel Settings. Think of it as the master switch. Until the Enable Omni-Channel checkbox is selected, the rest of the feature stays hidden: Service Channels, Queues, Routing Configurations, Presence Configurations, and the Omni-Channel utility item all stay out of view. Once it is on, the page becomes the control panel for the routing options that every downstream component depends on.

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 is a record on the OpportunityTeamMember standard object that places a single User on the Opportunity Team for one specific deal. Each record links an Opportunity to a User, assigns a Team Member Role from a configurable picklist, and grants that user Read or Edit access to the parent Opportunity. The object is the deal-level counterpart of the Account Team Member, so people can collaborate on one opportunity without inheriting access to every other deal on the same account. The feature matters most when the Opportunity organization-wide default is Private or Public Read Only. In those orgs, a non-owner needs an explicit grant to view or edit a deal, and an Opportunity Team Member record is one way to provide it. Owners always keep full access to their own opportunities, so team members supplement the owner rather than replace them.

Opt Out of Customer Data Access is a Salesforce Setup page where an administrator turns off Salesforce's permission to collect and use the org's data for service improvement. It controls whether Salesforce can study how the org uses its products to make features, search relevance, and recommendations better. It does not change who inside your own org can see records, and it is separate from the access that Salesforce Support uses to troubleshoot cases. You reach it from Setup by typing Opt Out of Customer Data Access in the Quick Find box and selecting the page. If your contract allows the choice, you can turn the consent on or off there. When you switch it off after it was on, no new data is shared. Salesforce keeps any data already collected for up to 30 days for service improvement, then deletes it permanently. The setting is a privacy and data-governance control, not a record-sharing or field-security control.

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 page that turns the standard Order object on and controls how orders behave across your org. From a single screen you decide whether Orders are enabled at all, whether Order Products can carry negative quantities, whether Reduction Orders are available for returns and reductions, whether zero-quantity orders are permitted, and whether orders can exist without a price book. Each checkbox is small, but the downstream effect on fulfillment, returns, and reporting is large. The Order object is a standard part of the Sales Cloud data model. It sits after the Opportunity in the deal lifecycle and records what a customer actually committed to buy. An Order belongs to an Account and can reference a Contract. Order Settings is where an admin first makes that object usable, so it is usually one of the early decisions in a Sales Cloud or commerce rollout.

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-wide cap on a shared resource that the whole org draws from over a set window, such as daily API requests, data storage, file storage, or asynchronous Apex executions. Because Salesforce runs on multi-tenant infrastructure, where many customers share the same servers, these limits protect every tenant from any single org consuming more than its fair share. Org Limits are different from Governor Limits. An Org Limit is a budget the entire org spends across a period (often a rolling 24 hours) or a total ceiling like storage. A Governor Limit constrains what one Apex transaction may do (SOQL queries, DML rows, CPU time) and resets when that transaction ends. You read current Org Limit consumption through the Limits REST API and several Setup pages.

An Org-Wide Default (OWD) is the baseline access level Salesforce gives every user to records they do not own, set per object. It answers a simple question: if you are not the owner, and nobody has shared this record with you, can you see it at all? Each object carries its own OWD at one of several levels, from Private (only the owner sees it) up to Public Read/Write (everyone with object access can view and edit it). OWD is the floor of the Salesforce record-sharing model. Every other access mechanism, including sharing rules, the role hierarchy, manual shares, and teams, can only widen access above that floor. None of them can take access away below it. That makes the OWD on a sensitive object the single most important security decision in an implementation. Set it too open and data leaks; set it too tight and you spend the rest of the project granting access back.

An Organic Search Lead is a record in Salesforce where the Lead Source field is set to a value that represents unpaid search engine traffic, usually a custom picklist value named Organic Search. The record is typically created when a prospect finds your site through a regular search result, not a paid ad, and then submits a Web-to-Lead form. Organic Search is not one of the standard Lead Source values that ship with Salesforce. Admins add it as a custom value so marketing and sales can separate SEO-driven prospects from paid, referral, and list-based ones. Once the value exists, every lead tagged with it becomes reportable, which is how teams measure what search-driven content is actually worth.

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 (often called an Org-Wide Email Address) is a shared, verified email address that Salesforce users can pick as the From address on outbound email instead of their own personal address. Typical examples are support@yourcompany.com, billing@yourcompany.com, or noreply@yourcompany.com. Each address has a friendly Display Name, a Purpose, and a list of profiles allowed to use it. Salesforce confirms ownership through a verification email before the address can send anything. The point is consistency. When several reps email customers, you usually want those messages to look like they come from one branded mailbox, not from a dozen individual logins. A support agent replying to a Case can send as support@, while a finance user sends invoices as billing@. Nobody has to share the password to the real mailbox, and recipients see a sender they recognize. Org-Wide Addresses are set up once in Email administration and then reused across the email composer, Apex, email alerts, and Flow.

An Organization-Wide Default (OWD) is the baseline level of access a Salesforce user has to records they do not own. Each object carries its own OWD, and that setting answers one question: when you did not create the record and nobody shared it with you, what can you do with it? The available levels are Private, Public Read Only, Public Read/Write, Public Read/Write/Transfer (Leads and Cases), Public Full Access (Campaigns), and Controlled by Parent. The full set of object OWDs is the foundation of the org's sharing model. OWD is the floor, never the ceiling. Every other sharing tool (role hierarchy, sharing rules, manual sharing, teams, Apex sharing) can only widen access above this baseline. None of them can pull access below it. Salesforce states this plainly in its documentation. That one rule shapes the whole design approach: lock objects down to the tightest level the business can tolerate, then open access deliberately for the people who genuinely need it. You configure OWD under Setup, Sharing Settings.

An outbound call is a phone call that a Salesforce user starts toward a customer, rather than one that arrives from the customer. In Service Cloud and CTI integrations it is usually placed straight from a record using click-to-dial, so the agent never has to copy a number into a separate phone app. Outbound calls cover proactive contact like case callbacks, follow-ups, renewals, and sales prospecting. The call center or telephony provider connects the line, while Salesforce supplies the record context and writes the activity back to the customer's timeline.

An outbound change set is a collection of metadata components assembled in one Salesforce org so they can be sent to another connected org for deployment. The org where you build and upload it is the source. The org that receives it is the target, where the same package shows up as an inbound change set ready to validate and deploy. Admins create outbound change sets from Setup without writing code or installing tools. They are a declarative way to move customizations like custom fields, objects, Apex classes, and page layouts from a sandbox into production, or between any two orgs that share a deployment connection.

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.

An overlay in Salesforce is a panel that opens on top of the current page so a user can view or work with extra information without leaving the screen they are on. It floats above the page content as a dialog or popup, keeps the work behind it in place, and closes to return the user to exactly where they were. Overlay is mostly a legacy term tied to the original Salesforce Console in Classic, where detail records and custom-link targets could open in a floating panel. The same idea lives on in Lightning, but it is delivered through newer pieces such as console subtabs, split view, and the modal base components rather than the old console overlay itself.

An Owner is the Salesforce user (or queue) recorded in a record's OwnerId field as the person responsible for that record. The owner has full read and edit access to the record by default, and that ownership decides where the record sits in the role hierarchy for sharing and reporting. Ownership is one of the load-bearing parts of the Salesforce sharing model. When someone creates a record, they become the owner, and Salesforce writes a sharing row that grants the owner access. Other users then reach the record through the role hierarchy, sharing rules, manual sharing, or teams. Almost every record has an owner, the main exception being detail records in a master-detail relationship, which inherit access from their parent.

An Owner Only Amount is the forecast value in Salesforce Collaborative Forecasts that counts only the opportunities a user owns directly. It deliberately leaves out the amounts that roll up from anyone below that user in the forecast hierarchy. In the data model it maps to the OwnerOnlyAmount field on the ForecastingItem object. The field sits next to ForecastAmount, which does include subordinate rollups, so a manager can read personal production and team production from the same forecast row.

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.