Salesforce terms starting with P

A PaaS (Platform as a Service) is a cloud computing model where a vendor hosts the hardware, operating systems, runtime, and development tools, and customers build and run their own applications on top of it. The customer writes the app and owns the data. The vendor handles servers, patching, scaling, and uptime. In Salesforce, the PaaS offering is the Lightning Platform, which debuted in 2008 as Force.com and is now folded into the broader Agentforce 360 Platform. It lets admins and developers create custom objects, fields, logic, and user interfaces that run in Salesforce's multitenant cloud. You never provision a database or rack a server. You define what the app should do, and the platform runs it.

A Package in Salesforce is a container of metadata that can be distributed across orgs as a single deployable unit. Packages bundle objects, fields, Apex classes, Lightning components, page layouts, validation rules, flows, and any other deployable metadata into a versioned artifact that installs cleanly into another org. Packages are how AppExchange ISVs ship their products, how internal teams modularize their org configuration, and how Salesforce DX projects publish reusable components across an enterprise. Salesforce supports four package types: Managed (publisher-owned, locked from customer edits, sold via AppExchange), Unmanaged (open-source-style, fully customer-editable after install), Unlocked (Salesforce DX modern format with source control and dependency declarations, the recommended type for internal team packages), and 2nd-Generation Managed (the modern managed package format for ISVs, replacing the legacy 1st-generation managed). The choice of package type determines distribution capabilities, customer-side editing rights, and the development workflow that produces the package.

A package dependency is a relationship where the metadata in one Salesforce package relies on metadata that lives in another package. The package that supplies the shared components is the base package, and the package that builds on top of it is the dependent package, often called an extension. The base must be present in an org before its dependent package can install or work correctly. Dependencies are how a partner extends a base app with separate, specialized features instead of cramming everything into a single package. In second-generation managed packaging (2GP) and unlocked packaging, you declare each dependency explicitly in the sfdx-project.json file, so every developer can see exactly what a package needs.

Package installation is the process of adding a Salesforce package into an org so its bundled components and functionality become available to users. A package is a container of metadata (objects, fields, Apex, Lightning components, automation, and more), and installing it deploys those components into the target org. You start an install either from an AppExchange listing or by opening a direct installation URL the package publisher gives you. During the install you confirm the target org, agree to the publisher's terms, and choose which users get access. Salesforce then deploys the components and runs any post-install steps the package defines. Once it finishes, the package shows up on the Installed Packages page in Setup, where you manage it later.

Package Manager in Salesforce DX is the tooling and command surface for creating, versioning, distributing, and installing packages, primarily second-generation packaging (2GP) but with continued support for first-generation managed packages. The Package Manager features are exposed through the sf CLI's sf package commands and the underlying Salesforce DX project structure that defines what goes into a package. Package Manager is the foundation of the modern ISV development workflow and the increasingly common pattern of large enterprises packaging their own internal apps as unlocked or unmanaged packages for cross-org distribution. The term encompasses both the developer-side tools (creating packages, building versions, promoting versions through testing environments) and the org-side install experience (installing a package, upgrading to a new version, uninstalling a package). The unified Package Manager surface replaced the older fragmented tooling (separate first-gen and second-gen commands, browser-based install URLs, change-set-based deployment) that made ISV development and large enterprise package management significantly harder than it should have been.

Package Publication in Salesforce is the multi-step process of taking a managed package from internal development to the AppExchange marketplace where customers and prospects can discover, evaluate, install, and use it. The process spans technical preparation (building a release-quality package version, ensuring test coverage, documenting features), business preparation (pricing, licensing, marketing collateral, demo environments), and the Salesforce-mandated Security Review where the package code and architecture are independently assessed for security vulnerabilities before commercial release. Publishing a package to AppExchange is the canonical path for Independent Software Vendors (ISVs) building on Salesforce, but it is also relevant for Salesforce Labs apps, system integrator consulting offerings, and enterprise customers distributing internal apps to subsidiaries. The publication process is rigorous because AppExchange has a strong reputation for quality and security, and Salesforce protects that reputation through the Security Review and listing standards. ISVs that complete the publication process gain access to a massive Salesforce customer base; those that cannot meet the standards do not publish, which is part of how the marketplace maintains quality.

Package Usage is a Setup page in Salesforce that shows license consumption and user assignments for every installed managed package in the org. It serves as the central audit point for understanding who has access to which AppExchange product, how many license seats are used out of the total purchased, and whether the org is over-licensed or under-licensed for renewal negotiations with each independent software vendor. The page lives under Setup, then Installed Packages, with the Manage Licenses link on each package row leading to its specific allocation view. Every managed package that ships with a licensing model exposes its usage here, including both AppExchange products purchased through Salesforce and free packages distributed by partners. Unmanaged packages and metadata-only deployments do not appear on this page because they do not carry a license construct.

A Package Version in Salesforce is a specific numbered release of a managed or unlocked package that can be installed in subscriber orgs. Each version is immutable once released, has a unique 04t Id, and represents a snapshot of the package contents at that point in time. New versions add features, fix bugs, or change behavior; the package's version number (major.minor.patch.build) communicates the nature of changes to subscribers and to dependency-aware tooling. Package versions are the unit of distribution for everything that travels through Salesforce's package mechanism, from AppExchange-distributed ISV apps to enterprise-distributed unlocked packages used across business unit orgs. Understanding how package versions work, how they relate to each other, and how to manage the upgrade path is essential for any team building or consuming packages on the platform. The version model has changed substantially between first-generation packaging and second-generation packaging (2GP), with 2GP introducing source-driven version creation, explicit dependency declarations, and finer control over upgrade behavior.

A Page Layout in Salesforce is the configuration record that controls how a specific record type appears in the Salesforce UI. The Page Layout decides which fields show up on the record detail page, what order those fields appear in, which sections group them, which fields are required versus read-only, which related lists render below the detail section, and which buttons and quick actions surface on the page. Every record type on every object has a Page Layout assignment per Profile, and the combination of Profile and Record Type decides which Page Layout a given user sees when they open a given record. Page Layouts are the original UI customization mechanism in Salesforce. The platform shipped with them in the early Classic UI, and most enterprise orgs accumulated dozens of them over the years: one per major Profile per Record Type per object. The proliferation is part of the design (different users need different views) and part of the maintenance pain (a new field requires touching every Page Layout that should display it). In Lightning Experience, the Page Layout still exists but has been mostly supplemented by Lightning Record Pages, which are a separate configuration layer that can override or augment what the Page Layout produces.

A Parent Account is the account record that sits directly above another account in a Salesforce account hierarchy. The link is created by the Parent Account field, a self-lookup on the Account object that points one account at another account as its parent. Salesforce uses this single field to model corporate structures, where subsidiaries, divisions, or branch locations roll up to a parent company. The relationship can stack many levels deep, so a regional office can have a country headquarters as its parent, which in turn has a global holding company above it. Each account still has its own contacts, opportunities, and cases. The Parent Account field simply records how the accounts connect, which the View Account Hierarchy action then renders as a tree.

A parent category is a data category that sits above one or more child categories inside a Salesforce data category group. It is the higher node in a hierarchy, and the categories nested beneath it are its subcategories. Salesforce uses parent categories to organize Knowledge articles, and historically Ideas and Answers, into a browsable tree by topic. Every data category group starts with a single top node named "All", which is the ultimate parent. Below "All" an admin builds out parent categories and their children, up to five levels deep. The structure controls both how content is grouped and who can see it.

A Partial Copy sandbox is a Salesforce sandbox type that copies all of your production org's metadata plus a sample of its records, where the sample is defined by a sandbox template. It gives teams realistic test data without the storage cost or long refresh time of a full copy. The template you choose controls which objects come across and caps the volume. A Partial Copy sandbox holds up to 5 GB of data and a maximum of 10,000 records per selected object. You can refresh it once every 5 days.

Partial Page is the rendering and update technique in legacy Salesforce Visualforce pages where only a portion of the page is sent back to the server and re-rendered, instead of the entire page reloading. It is implemented through the apex:actionRegion, rerender, and apex:actionFunction tags, and it lets developers build forms that update specific sections (a related list refresh, a dependent picklist) without losing the user's scroll position or unsaved input on the rest of the page. Partial Page belongs to the Visualforce era. Lightning Experience and Lightning Web Components handle the same need through reactive data binding and Lightning Data Service, which means partial-page techniques rarely come up in greenfield development today. The term still matters because thousands of customer-built Visualforce pages remain in production and partial-page handling is the right tool when extending or debugging them.

A Partner in Salesforce is a company or individual you do business with through your sales channel, such as a reseller, distributor, value-added reseller, system integrator, or independent software vendor. Partners sell, deliver, or support your products on your behalf instead of you selling directly to every end customer. In the data model a partner is represented by a partner account, which is a regular business account that has been enabled for partner access. Partners are external to your company, so they are not employees and do not get full internal user licenses. Instead they log in to a partner portal built on Experience Cloud, where they can work the leads, deals, and resources you choose to share. Salesforce groups all of this under Partner Relationship Management (PRM), the set of features that onboard partners, route leads to them, and track how the channel performs.

Partner Accounts are Salesforce Account records that have been flagged as partner-enabled, allowing the platform to provision external users (Contacts under the account) with Partner Community licenses for access to an Experience Cloud partner portal. The flag turns a standard Account into the central record for managing a channel relationship: deal registrations, lead distributions, shared opportunities, partner tier assignments, and any other channel-management data. Once an Account is enabled as a Partner Account, its related Contacts can be enabled as Partner Users in two clicks. The Account becomes the sharing anchor for everything those partner users see in the portal: records owned by their company's partner users, records shared with their company via sharing rules, and records explicitly assigned to them. This Account-centric model is what makes a partner portal feel like a tenant experience for each partner company, even though all partners share the same underlying org.

Partner Experience in Salesforce refers to the Experience Cloud configuration that gives external partner companies (resellers, distributors, channel partners, system integrators) secure access to Salesforce data inside the customer's org. Partners use the portal to register deals, manage shared leads, collaborate on opportunities, log support cases, and access partner-specific marketing and enablement content. The Partner Experience is built on the same Experience Cloud platform that powers customer communities, but it uses a partner-licensed user model with broader access to records: Accounts, Opportunities, Leads, Contracts, and custom objects can all be exposed to partners through a combination of sharing rules, profiles, and permission sets. The Partner Central template is the standard starting point for new portal builds, and most channel programs customize it heavily before going live.

Partner Portal is the legacy Salesforce feature for giving external partner organizations (resellers, distributors, channel partners) controlled access to a customer's Salesforce data: leads they should follow up on, opportunities they share, cases they file on behalf of end customers. The original Partner Portal was a Salesforce Classic feature replaced in 2017 by Experience Cloud (formerly Community Cloud), which subsumed both Partner Portal and Customer Portal under a unified platform with Lightning Experience UI and richer customization. Partner Portal is mostly a historical term now. New deployments use Experience Cloud with a Partner template that delivers the same partner-facing capabilities through a modern UI. Existing Partner Portal deployments in legacy orgs continue to work but receive no new feature investment. The Salesforce documentation still references Partner Portal in places for backwards compatibility, but the recommended path for any new partner-facing site is Experience Cloud. The underlying licensing model (Partner Community licenses) carries over from the Partner Portal era and remains the foundation of partner identity and access in modern orgs.

A Partner Role is a position in a hierarchy assigned to a Salesforce Partner Community user. It defines the partner user's level within their partner organisation and determines which records the user can see based on the role-hierarchy sharing model that Salesforce applies to internal users too. Each Partner Account in Salesforce has its own self-contained Partner Role hierarchy, so a partner organisation's internal access model lives inside that account. The hierarchy under a partner account typically has three levels: Partner Executive, Partner Manager, and Partner User. The hierarchy can be customised with up to three levels by default and renamed per account. The levels mirror the internal Role Hierarchy in behaviour: a Partner Executive sees records owned by Partner Managers and Partner Users below them in the same account. Partner Roles are only relevant for Partner Community licenses and Customer Community Plus licenses configured for role-based sharing.

A Partner User is an external Salesforce user tied to a business partner account who logs in through an Experience Cloud site, usually with a Partner Community license. Partner users are people at your resellers, distributors, agencies, or referral partners. They are not employees of your company, but they need controlled access to the leads, opportunities, and shared resources that let them sell or service on your behalf. A partner user record is created by enabling a contact on a partner-enabled account. That link to a contact and account is what separates a partner user from an internal user. It is also what drives record sharing, role placement, and the data each partner sees. Partner users sit at the center of partner relationship management, where a vendor recruits a channel and gives each partner a slice of the CRM.

A Partner WSDL is a Salesforce-provided WSDL file that describes the SOAP API in a generic, loosely typed way, so a single client application can call any Salesforce org without being rebuilt for each one. Instead of baking in a specific org's objects and fields, it represents every record as a generic sObject and treats fields as name-value pairs. This makes it the standard choice for AppExchange partners and ISVs whose product talks to many different customer orgs. A Partner WSDL stands in contrast to the Enterprise WSDL, which is strongly typed and tied to one org's exact schema. With the Partner WSDL you download and consume the file once per API version, then discover each org's fields at runtime with describe calls. You trade some compile-time convenience for the ability to write one code base that works everywhere.

Password Policies is the Salesforce Setup page where an administrator defines the password rules that apply to user accounts in the org. The settings cover minimum length, complexity, expiration interval, password history, the security question used for resets, and how many failed logins trigger a lockout. These rules form the baseline for every account that signs in with a Salesforce password rather than single sign-on. You set them once at the org level, and you can also override them per profile so different groups of users get stricter or looser requirements.

A patch is a package version that ships bug fixes to a specific major.minor release of a Salesforce managed package, without adding new features. It keeps the same major and minor numbers and increments only the patch segment, so a subscriber on an older release can take the fix while staying on the functionality they already know. In second-generation managed packaging (2GP), a patch lives in the four-part version number major.minor.patch.build. Partners build it from source with the Salesforce CLI, then customers install it as a small, low-risk upgrade. The point is to decouple urgent fixes from feature releases, so nobody has to swallow unwanted changes just to clear a defect.

A patch development organization is a special Developer Edition org that Salesforce generates from a specific major release of a Managed - Released package. An ISV uses it to build patch versions, which are small bug fixes for an existing package version. Customers can install the patch without being forced onto a new major version. The patch org is deliberately constrained. You can fix defects and adjust existing behavior, but you cannot add new components, delete components, or change access controls. That limit is what makes a patch safe to push to live subscriber orgs automatically.

A Patch Release is a minor version of a Salesforce managed package that ships bug fixes and small enhancements without changing the package's major or minor version numbers. The publisher builds it in a Patch Development Org seeded with the prior major version, makes only the metadata changes the patch namespace allows, uploads it, and then delivers it to every subscriber org through a Push Upgrade. Patch Releases exist to give ISVs a safe path to ship a fix without forcing every customer to manually reinstall. The patch namespace forbids breaking changes by design: no Apex API signature changes, no field deletions, no required-field additions, no schema rearrangement that would invalidate existing subscriber data. What you can do is add Apex code, add new metadata, change existing Apex method bodies that do not change their public signatures, and fix flow or validation rule logic. The narrow scope is the price you pay for a feature that can update tens of thousands of subscriber orgs overnight.

Path Settings is the Salesforce Setup page where administrators turn on and configure Path, a visual component that shows where a record sits in a process. Path renders the values of a picklist (such as Opportunity Stage, Lead Status, or Case Status) as a horizontal progress bar across the top of a record page in Lightning Experience. From Path Settings, an admin attaches up to five key fields and up to 1,000 characters of guidance to each step. They can also switch on celebrations so a burst of confetti fires when a record reaches a chosen value. The page is the single control point for every Path in the org.

A Patient Timeline is a Salesforce Health Cloud component that displays a patient's healthcare events in one chronological view. It pulls appointments, encounters, care plan activities, conditions, medications, and other records onto a single horizontal track, so a care team can read the whole history without opening related lists one by one. The timeline shows past, current, and future events together. It runs in the Health Cloud console for staff and on Experience Cloud sites for patients through Health Cloud Empower. Salesforce ships an Enhanced Timeline that admins configure declaratively, alongside an older managed-package version that some orgs still run.

Paused and Failed Flow Interviews is a Setup page in Salesforce that lists every flow interview in the org that is currently paused or has failed. A paused interview is a flow run that hit a Pause element and is waiting on a scheduled resume time or a user action. A failed interview is a run that stopped because an element threw an unhandled error. The page lets an administrator see both states in one place and act on them.

A Payment in Salesforce is a record that captures money received from a customer against an invoice balance. It tracks the amount, the payment method, the date funds were collected, and how that money is applied across one or more invoices. Payments live in Salesforce Billing, which is part of Revenue Cloud, where they sit at the end of the quote-to-cash flow that runs from quote to order to invoice to payment. A Payment can be entered by hand for a check or cash receipt, or created automatically when a payment run charges a gateway. Either way, the record is only useful once it is allocated, meaning the amount is linked to specific invoices so their balances drop and the account stops showing money it has already received.

Peak Hour Scheduling is a configuration option inside Salesforce Scheduler that biases the appointment-booking engine to fill the busiest hours of the working day first before offering openings outside those windows. The result is denser appointment density during peak hours, which is the right operating model for businesses where labor cost per appointment slot is lower during peak periods (most service businesses) or where customer demand naturally clusters during peak hours. The setting is part of the broader Salesforce Scheduler engine, which manages booking across service resources, service territories, and work types. Peak Hour Scheduling sits alongside related configurations like operating hours, time-off rules, capacity constraints, and territory routing. Enabled when the org wants the engine to favor high-utilization scheduling over chronological fairness, the feature shifts which open slots appear first when a customer or scheduler searches for availability.

A People profile in Salesforce is a unified record that represents one real-world individual, built by combining identity data from many source systems into a single canonical view. In Data Cloud (now Data 360), this unified individual is produced by identity resolution, which matches and merges source records from CRM, marketing, commerce, and other streams into one profile per person. The same idea appears in Marketing Cloud Personalization, where anonymous and known activity for a visitor is merged into a Unified Customer Profile over time. Across both products, the goal is the same: stop treating a person as scattered rows and start treating them as one addressable entity.

A Percent (%) Quota is the quota attainment figure shown in Salesforce Collaborative Forecasts, expressing how close a forecast or closed amount is to a rep's assigned quota as a percentage. It is not a separate field you store. It is a calculated display value, derived as the forecast value divided by the quota value for a given rollup and period. You set quotas as plain numbers, either a revenue amount or a quantity, depending on the forecast type. Salesforce then renders the percentage and a progress bar under each forecast on the Forecasts page once you turn on Show Quota % Attainment. A rep at 110% has beaten target, regardless of whether the underlying quota was 500K or 1M.

A permission in Salesforce is a single access right that controls one specific thing a user can do or see. Examples include reading a record on an object, editing a field, calling the API, or running a powerful operation like View All Data. Each permission is a small on or off switch, and a user's full access is the sum of every permission turned on for them. Permissions are not assigned to users directly. They live inside profiles and permission sets, which are the containers that group permissions together. A user gets one profile plus any number of permission sets, and Salesforce adds up the permissions from all of them. If any container enables a permission, the user has it.

A Permission Set in Salesforce is an additive permission grant that layers on top of a User's Profile. Where a User has exactly one Profile, the same User can have many Permission Sets, each granting a specific capability: access to a custom object, edit rights on a specific field, the ability to run a specific feature, visibility into a particular tab. Permission Sets are how Salesforce's permission model handles "this user is mostly a Sales Rep but also needs to approve discounts" without forcing you to clone the entire Sales Rep Profile into a Sales-Rep-with-Approvals Profile. The Permission Set concept exists because Profile-only permission management does not scale. In an org with twenty Sales Reps who all need almost-the-same permissions plus one of three optional capabilities (Approval Rights, Forecast Adjustments, Mass Email), the Profile-only approach produces three Profiles per capability combination (eight Profiles for three boolean flags, all maintained in parallel). The Permission Set approach is one Profile (Sales Rep) plus three Permission Sets (Approver, Forecast Adjuster, Mass Emailer), assigned in any combination. The maintenance shrinks from updating eight Profiles when a new field ships to updating one Profile plus three Permission Sets. Once you have seen the scaling difference, the Profile-only pattern feels like a relic.

A Permission Set Assignment is a standard Salesforce object (PermissionSetAssignment in the API) that records one grant of a permission set or permission set group to a single user. Each record links a user to the access bundle they receive, so the assignment is the actual connection that turns a permission set into live access for someone. A Permission Set Assignment holds an AssigneeId for the user, a PermissionSetId or a PermissionSetGroupId for the access being granted, and an optional ExpirationDate that removes the grant automatically when it is reached. Assignments are how Salesforce delivers its recommended additive model: every user keeps one baseline profile, and extra access stacks on top through assignments that an admin can add or remove without touching the profile.

A permission set group is a Salesforce construct that bundles multiple permission sets into a single assignable unit. Users assigned to the group inherit every permission from every permission set in the bundle, without having to be assigned to each one individually. It is the modern way to manage role-based access in Salesforce, replacing the old pattern of stacking many permission sets directly on each user. Permission set groups debuted in 2020 and have become the recommended permission-management pattern for any org of meaningful size. The bundle approach maps naturally to job functions: a Sales Manager group might contain permission sets for Forecasting, Reports, Opportunity Management, and Pipeline Reviews. Assigning one group is cleaner than assigning five permission sets, and the mapping is auditable at a glance. Salesforce has also confirmed that profiles will be retired over time in favor of permission set groups, which makes mastering this pattern foundational rather than optional.

A Permission Set License (PSL) in Salesforce is a supplemental entitlement that extends what a user can do beyond their base user license. A user license sets the ceiling on available functionality. A PSL raises that ceiling for one user, unlocking gated features without changing their profile or swapping them to a different user license. A PSL on its own grants nothing. It only makes a set of feature permissions eligible to be turned on. The user still needs a permission set that contains those permissions. Salesforce sums these two layers: the PSL says the feature is allowed, and the permission set actually enables it.

A Person Account is the Salesforce data model adaptation for business-to-consumer orgs whose customers are individual people, not companies. Under the default Business Account model, a customer is a company (the Account) with one or more people who work there (the Contacts). Under Person Accounts, the customer is the individual, and the platform fuses an Account row and a Contact row into something that looks like one record on the page but is technically two linked rows underneath. The Account has IsPersonAccount=true. The Contact has IsPersonAccount=true. Both share an Id that the platform threads through every related lookup. Person Accounts exist because the standard Account-Contact split does not fit any B2C industry cleanly. Retail banking, consumer insurance, healthcare, wealth management, residential utilities, and every business whose customer is one human being were shoehorning person data into "Company = Smith Household, Contact = John Smith" before Person Accounts shipped. The result was Account reporting that double-counted, Contact reporting that missed the household context, and sharing rules that needed to know which one was "the customer." Person Accounts collapsed the redundancy. The feature now sits behind a setup toggle that almost every B2C-licensed org turns on, but the toggle has consequences that survive long after the org forgets it flipped one.

Personal Information is a category of user-account data in Salesforce, covering a user's name, alias, email, phone number, address, and work details such as title and company. It lives in the user record and in the per-user settings area, where each person can review and update their own details without filing a request with an admin. The same data also sits at the center of Salesforce privacy controls. Some of these fields are personally identifiable, so Salesforce hides a set of them from external community and portal users by default. Personal Information therefore spans two ideas: the self-service settings a user maintains, and the user attributes that data protection rules govern.

A Personal Settings page is the self-service area in Salesforce Classic where each user manages their own preferences without asking an administrator. A user opens it from the dropdown next to their name at the top of any page, then picks My Settings or Setup depending on how the org is configured. A left-hand menu groups options for personal information, security, display, email, and calendar, and a Quick Find box jumps straight to any page. Personal Settings is a legacy label, but the feature is not dead. The Salesforce Classic interface it belongs to is the older one, and Salesforce has steered customers toward Lightning Experience for years. The identical toolset appears in Lightning under My Settings, reached from the profile picture. Both edit the same user record, so they are one toolset wearing two interfaces. The name survives mostly in older orgs, vintage documentation, and certification material.

Phrase Search in Salesforce is the search syntax that matches a record only when the searchable fields contain a specific sequence of words in the same order. The phrase is entered between double quotes: searching for "Acme Corporation Q1 renewal" matches records with that exact phrase but not records that contain the same words in a different order. Without the quotes, Salesforce treats the input as a keyword search and matches any record containing any of the words. Phrase Search is the canonical way to find records when the order of words matters: a Knowledge article titled "How to reset a forgotten password," a Case with subject "delivery delay due to weather," a Contact named "John Smith Jr." All Salesforce search surfaces (global search, list view search, SOQL/SOSL text predicates) support the phrase syntax. The platform respects up to five phrases per search query before downgrading extra terms to keyword matching.

A picklist is a Salesforce field that lets users pick one value from a controlled list, with the available values defined by the admin rather than typed in by the user. It is the platform's answer to free-text fields for any value that should stay consistent across records, like Industry, Stage, Status, Priority, or Country. Picklists come in two main variants: standard single-select picklists, which return exactly one value per record, and multi-select picklists, which allow several values stored as a semicolon-delimited string. A third form, the global picklist, lets administrators define a value set once and reuse it across multiple fields on different objects, so changing a value updates every reference at once. Picklist values participate in record types, validation rules, reports, list view filters, and Apex code, which is why getting the value set right early matters more than people expect.

Picklist Settings is the collection of configuration options in Salesforce that control how a picklist field behaves: whether its values are restricted to a defined list, how those values sort, which value is the default, and how it relates to other fields. In modern Salesforce, these options live on the field itself and on the value set that feeds it, not on a single org-wide Setup page. The settings matter because picklists drive reporting, automation, and data quality across the whole org. A field with a strict value set rejects bad input at save time. A loosely controlled one lets typos and stale values pile up. Picklist Settings is where an admin decides which way each field leans.

A picklist value set, often called a global value set, is a single list of picklist values that lives on its own in Setup and can be shared by more than one picklist field across different objects. Instead of typing the same options into each field, you define them once and point every field at that one shared list. The Picklist Value Sets page in Setup is where these shared lists are created and managed. When you add or deactivate a value in the set, the change flows to every picklist field that uses it. A global value set is restricted by nature, so only an admin can change its values and users cannot save an unapproved entry, even through the API.

A picklist value is one of the individual options a Salesforce picklist field offers a user during data entry. Each value pairs a label that people read in the dropdown with an API name that code, formulas, validation rules, and integrations reference. Values can be active or inactive, sorted manually or alphabetically, defaulted, and filtered so different record types show different choices. Admins maintain these options in two places. Field-specific values live on a single picklist field. Global picklist value set values are defined once and shared across many fields. Where you store and how you manage these options shapes data quality, reporting accuracy, and how cleanly an org scales over time.

A pinned list is the list view that Salesforce loads by default when you open an object in Lightning Experience. You set it by clicking the pin icon next to a list view, and from then on that view appears first whenever you visit that object's home, instead of the standard Recently Viewed summary. Pinning is a personal setting. Each user picks their own pinned list per object, and the choice does not sync between browsers. Only one list view can be pinned for a given object at a time, so pinning a new view replaces the previous one.

A Pipeline in Salesforce is the aggregate view of every open Opportunity weighted by stage probability. The word does not refer to a database object; it refers to the calculated total of Amount across Opportunities where IsClosed = false, multiplied by each stage's probability percentage, segmented by Close Date. When a sales leader asks "what is our Q3 pipeline," they mean a specific number derived from Opportunity records in the org, usually surfaced through a standard report or dashboard built on top of the Opportunity object. Pipeline is the unit of measurement for the future revenue your sales organization is currently working on. Quota attainment looks backwards (Closed Won amount versus target); pipeline looks forwards (open Opportunity amount versus future quotas). Most sales leadership conversations frame pipeline through a coverage ratio: pipeline amount divided by remaining quota for the period. Different industries and motions target different ratios (3x is common for enterprise, 4-5x for SMB, more for high-velocity), but every motion eventually settles on a target ratio that the leadership uses as the early warning indicator for whether the team will hit the quarter.

Platform as a Service (PaaS) is the cloud computing delivery model in which a third-party provider offers a complete development, deployment, and runtime environment over the internet, removing the need for customers to manage underlying servers, operating systems, databases, or networking infrastructure. The Salesforce Lightning Platform (formerly known as Force.com) is one of the largest and most established PaaS offerings, supporting hundreds of thousands of custom applications built by customers on top of the Salesforce core services. PaaS sits between Infrastructure as a Service (where the customer manages the operating system and runtime themselves, on cloud-provider hardware) and Software as a Service (where the customer just uses a finished application). PaaS gives the customer a development platform (programming languages, databases, deployment tools, monitoring) without the operational burden of running infrastructure. For Salesforce specifically, customers use the Lightning Platform to build everything from internal-facing custom apps that extend Sales Cloud or Service Cloud to entirely new business applications that have no relation to CRM at all.

Platform Cache is a Salesforce feature that stores frequently used data in memory on the Lightning Platform, so your Apex code can read it back fast instead of recomputing it or running the same SOQL query again. It comes in two flavors. Org cache holds data that every user and process in the org can read, and session cache holds data scoped to a single user's session. You allocate Platform Cache capacity into named partitions, then read and write values through the Cache namespace classes in Apex. Each cached value has a time-to-live, after which it expires. Because the platform can also evict entries early when space runs low, cache is a speed boost, not a source of truth.

A Platform Edition is a Salesforce licensing option that gives users the core Lightning Platform for building and running custom apps, without the standard CRM sales and service features. In Salesforce's license catalog it shows up as the Salesforce Platform user license, sold most commonly through the Lightning Platform Starter and Lightning Platform Plus tiers. A Platform Edition user can create and use custom objects, tabs, apps, Apex, Lightning components, Flows, and the API. They do not get sales objects like Leads, Opportunities, Quotes, and Campaigns, or service features such as Cases worked under a Service Cloud license. The trade is simple. You pay less than a full Sales or Service Cloud seat, and in return you give up the prebuilt CRM that you were not going to use anyway.

A Platform Event is a Salesforce event object used to publish and subscribe to messages on the platform's event bus. Publishers (Apex, Flow, Process Builder, or external systems via the API) create event records; subscribers (Apex Triggers, Flows, Lightning components, or external systems via CometD/Pub/Sub API) receive them and react. Platform Events decouple producers from consumers, enable asynchronous and event-driven architecture inside Salesforce, and integrate with external messaging systems through CometD or the newer Pub/Sub API. Platform Events look like custom objects in Setup but have the __e suffix and operate under different rules. Records are immutable: once published, you cannot update or delete them. Subscribers receive events nearly in real time through a high-throughput streaming channel. The platform retains events for 72 hours by default for high-volume events and up to 24 hours for standard events, after which they are removed from the bus. Platform Events are the standard pattern for integration with external messaging systems, for fan-out notifications inside an org, and for event-driven Apex that should not run synchronously during the originating save transaction.

The Platform Event Bus is the Salesforce-managed publish-subscribe infrastructure that delivers Platform Events, Change Data Capture events, and Streaming API messages between publishers and subscribers. It is the event-streaming backbone of the modern Salesforce integration architecture, abstracting message routing, retry behaviour, replay, and durability away from the integrations that use it. Publishers fire events; the Event Bus broadcasts them to every subscriber registered for that event type, without point-to-point coupling between systems. Underneath, the Event Bus runs on Salesforce's distributed message infrastructure (built on Apache Kafka). Events are durable for 72 hours (or longer for High-Volume Platform Events with the right license tier), can be replayed by subscribers using a replay ID, and support multiple concurrent subscribers per event type. The bus is what makes Platform Events scalable to high-volume use cases that would crush a synchronous integration pattern, and what gives Change Data Capture its 72-hour catch-up window for offline subscribers.

A Point in Salesforce is a single geographic location stored as a latitude and longitude pair. It pins one spot on the Earth, such as a customer address, a service appointment, or a sales rep's current position. On the platform this point lives inside a Geolocation field, and the Apex runtime models the same idea with the System.Location class. Points are the raw material for every location-aware feature. Salesforce Maps plots them as markers, the DISTANCE formula function measures the space between two of them, and Field Service uses them to route mobile workers. A point only becomes useful once an address has been geocoded, which is the step that turns a street address into those two coordinates.

Popular Ideas is a list view, shown as a subtab on the Salesforce Ideas tab, that ranks ideas by the recency of their positive votes rather than by their total score. Ideas that have most recently gained supportive votes float to the top, so the list shows what a community is rallying behind right now. Popular Ideas belongs to the Ideas feature, which Salesforce now treats as a legacy capability. It still works inside Experience Cloud sites and the internal app, and it remains useful for understanding older feedback communities, but newer programs often gather suggestions through other channels.

A Popular Questions list was a sorted view inside Salesforce Chatter Answers and Experience Cloud Q&A that surfaced the questions a community engaged with most, ranked by views, replies, or votes. It gave new visitors a fast path to the topics other people kept asking about, so common answers stayed near the top instead of buried in a long feed. This is a legacy idea. The Chatter Answers feature that hosted the original Popular Questions list is retired, and new orgs cannot enable it. The pattern of surfacing high-engagement questions now lives in Chatter Questions feeds and Experience Cloud topic and search experiences, which Salesforce recommends instead.

A Portal Health Check is a Setup tool in Salesforce that reports on the security-related settings of portal and Experience Cloud site users. It surfaces the permissions, object and field access, and sharing configuration that decide what an external user can see, so an administrator can review exposure in one place instead of clicking through dozens of screens. The tool produces four read-only reports built from your portal profiles, organization-wide defaults, and sharing rules. It does not change anything on its own. You read each report, decide whether the access shown is intended, and then go fix anything that looks too broad in the normal Setup areas.

A post is a message published to a feed in Salesforce Chatter. It can carry plain text, rich text, @mentions, topics, files, links, or a poll, and it lands on a person's profile feed, a Chatter group feed, or the feed of a record like an account or opportunity. Under the hood, each post is stored as a FeedItem record. The FeedItem Type field marks what kind of post it is, such as TextPost, ContentPost, LinkPost, PollPost, or QuestionPost. Other people then reply with comments, react with likes, and follow the thread, which makes the post a small unit of collaboration tied to real CRM data.

Post Sharing is a Chatter action that takes an existing public post and republishes it to a new audience, either your own profile feed or a group feed you belong to. The shared copy links back to the original, so readers can jump to the source and see its comments, likes, and attachments in one place. Sharing spreads useful content past its first audience without copying and pasting. It is the Chatter equivalent of a repost. You can add your own remarks above the shared item to give it context. Salesforce still enforces record and group access, so a share never exposes a post to people who could not already see the original.

A Post Template is a Salesforce Setup record that controls which fields appear in an approval request post inside a Chatter feed. It applies to Classic Approval Processes when both Approvals and Chatter are enabled, so approvers see the record details that matter without opening the record. Each template is tied to one object, such as Account or Opportunity. You pick the fields to display, and the approval process references that template when it posts the request to the approver's feed.

A postback request is an HTTP POST that a Visualforce page sends back to the Salesforce server when a user interaction needs the server to do work. Clicking a Save button, an action link, or any control bound to a controller method generates one. The server decodes the page's view state, runs the matching controller logic, and returns refreshed markup. Postback is the older, server-driven request model that Visualforce has used since its launch. It still works and ships in every org, but it predates Lightning. New user interface work is built on Lightning Web Components, which keep more logic in the browser and call the server through targeted Apex methods instead of full-form postbacks.

Predefined Case Teams are admin-defined groups of users with specific roles that can be applied as a bundle to any case in one click. A typical Predefined Case Team for an escalation might include the Tier 2 Engineer, the Account Manager, and the Customer Success Manager, each with a specific Case Team Role determining their access. When the case needs the team, the agent applies the predefined team, and all three users are added at once with the right access. This replaces the manual "add three users one at a time" workflow that slows escalation handling. Case Teams in Salesforce are the lightweight access-sharing model for ad-hoc collaboration on individual cases. Each Case Team Member has a Case Team Role that defines what they can do on the case: View Only, View and Edit, or full access. Predefined Case Teams package commonly used team compositions for reuse. The pattern is most useful in B2B service environments where escalation paths follow consistent patterns (Tier 1 to Tier 2, account manager loop-in for VIP customers) and adding the right team manually on each case slows the response time.

A prediction is the scored output of a machine learning model that estimates a future outcome, a likelihood, or a classification. In Salesforce, predictions appear on records as a number (probability between 0 and 1), a percentage (1 to 99), or a categorical label, and they update as the underlying record changes. Predictions can come from built-in Einstein features (Lead Scoring, Opportunity Scoring, Case Classification), from custom Einstein Prediction Builder models, from Tableau-trained models surfaced into Salesforce, or from third-party models accessed through external connectors. The unifying property is that a prediction is the output of a discriminative or probabilistic model rather than the output of a generative one. Predictions are deterministic: the same inputs produce the same output. They are interpretable: each prediction can be traced back to the features that influenced it. They are typed: a probability is a number between 0 and 1, a classification is one of a fixed set of values. These properties make predictions easier to consume in flows, reports, and routing rules than the free-text outputs of generative AI features.

A predictive model is a machine learning model trained on historical data to forecast a future outcome, classify a record into a category, or score a record on a likelihood scale. In Salesforce, predictive models power Einstein Lead Scoring, Einstein Opportunity Scoring, Einstein Case Classification, Einstein Forecasting, Next Best Action recommendations, and any custom prediction built in Einstein Prediction Builder. The model reads features from the record (industry, source, amount, age, related-record counts) and returns a number or label that downstream code consumes. Predictive models differ from generative models in what they output. A generative model produces free text. A predictive model produces a structured value: a probability between 0 and 1, a category label, or a number. That structured output makes predictive models easy to wire into existing automation. A flow can branch on a score. A workflow can route on a category. The hard work is upstream: collecting clean historical data, defining the right target field, and validating that the model actually learned the pattern instead of a confounding signal.

Predictive routing in Salesforce is a Service Cloud capability that uses Einstein machine learning to send each case to the agent most likely to resolve it well, based on what happened with similar cases in the past. Instead of fixed if-then rules alone, the model learns from closed cases and predicts the values that drive assignment. In practice it works through two linked features. Einstein Case Classification reads a case Subject and Description, then predicts fields like Priority, Reason, or Type. Einstein Case Routing takes those predicted values and feeds them into your existing assignment rules or skills-based routing so the case lands with the right person or queue.

A Preparation Recipe (usually just called a recipe) is a Data Prep workflow in CRM Analytics that cleans, transforms, and combines source data, then writes the result to a dataset. You build it on a visual canvas by chaining nodes, so analysts shape raw data into analysis-ready form without writing transformation code. CRM Analytics is the Salesforce analytics platform that was called Einstein Analytics and then Tableau CRM before the 2022 rename. A recipe sits between synced source data and the datasets that power dashboards and lenses. It reads inputs, applies steps such as joins and formulas, and outputs one or more datasets that downstream exploration depends on.

A Presence Status is an Omni-Channel setting that shows whether a service representative is available to receive routed work. Each status is one of two kinds, Online (the rep can accept work) or Busy (the rep cannot), and reps switch between statuses through the day to signal what they are doing. The status a rep selects is the signal the routing engine reads before it assigns a case, chat, or call. Set to an Online status, the rep is eligible for new work up to their configured capacity. Set to a Busy status such as On Break or In a Meeting, the rep is skipped until they return to an available status.

A price book is a Salesforce object that holds a list of products together with the prices you charge for them. Every Salesforce org that uses products has one Standard Price Book, which Salesforce creates automatically and treats as the master list of products and their default prices. You can also build custom price books that hold different prices for the same products, so a single product record can sell at several prices depending on the book a rep chooses. The price itself does not live on the price book directly. It lives on a join record called a price book entry, which links one product to one price book at one price in one currency. That design lets the same product appear in the Standard Price Book at a baseline price and in custom price books at regional, segment, or promotional prices, all without cloning the product.

A Price Book Entry in Salesforce, called PricebookEntry in the API, is the record that links one Product (Product2) to one Price Book (Pricebook2) and stores the price that the product carries inside that price book. It is the row a sales team actually selects from when adding a product to an Opportunity, Quote, or Order. Without a Price Book Entry, a product has a definition but no sellable price. Each entry holds a UnitPrice, an IsActive flag, a UseStandardPrice flag, a ProductCode copied from the parent product, and a CurrencyIsoCode in multi-currency orgs. Every product needs a Price Book Entry in the Standard Price Book before it can appear in any custom price book or on a transaction. Custom price books then add their own entries to offer different prices to different segments.

A Primary Contact is the single person marked as the main point of contact for a parent record in Salesforce, such as an Account or an Opportunity. On an Opportunity, that person is recorded through an Opportunity Contact Role whose Primary checkbox (the IsPrimary field) is selected. Only one contact can hold the primary spot on a given parent at a time. The primary contact tells reps and managers who to engage first when a record has several contacts attached. It also feeds defaults and filters: report columns that read "primary contact," activity logging, and many automations key off whichever contact carries the primary flag. On an Account, the primary person is usually the main relationship owner; on an Opportunity, it is the buyer or lead decision-maker for that deal.

A primary key in Salesforce is the unique Record ID that identifies every row in every object. The platform assigns it automatically when a record is created, and it never changes for the life of that record, even if the record is deleted and later restored from the Recycle Bin. Every standard and custom object uses the same primary key mechanism. The Record ID lives in the read-only Id field, comes in a 15-character case-sensitive form and an 18-character case-safe form, and is globally unique across the entire org. Lookups, master-detail relationships, API calls, and reports all use this key to point at one specific record.

The Primary Partner is the single Partner Account on a Salesforce Opportunity flagged as the lead channel collaborator for that deal. Out of any number of partners linked to an opportunity through the Partners related list, exactly one carries the IsPrimary checkbox set to true. The primary flag drives commission attribution, partner-portal visibility, and standard reports that filter or group opportunities by their channel owner. Primary Partner is a flag on the OpportunityPartner junction record, not a separate field on Opportunity. The platform enforces uniqueness: marking a second partner as primary automatically clears the flag on the previous primary, so the relationship stays one-to-one at any given time. This single-source-of-truth model is what makes channel reporting and partner compensation predictable; without it, an opportunity with three involved partners would have three competing claims to the deal.

A Primary Tab is the main browser-like tab in the Salesforce Classic console that holds one main work item, such as a case, account, or contact. Each primary tab can contain its own set of subtabs that display related records, so an agent keeps the parent record and everything attached to it inside a single workspace. Selecting a record from a list or navigation item opens it as a primary tab. Primary tabs are a Salesforce Classic feature. The Console in Lightning Experience uses workspace tabs and subtabs to cover the same need, so primary tabs mostly come up when you maintain a Classic console app or plan a move to Lightning.

A Printable View is a Salesforce feature that renders a simplified, print-friendly version of a record, list view, or report. It removes the navigation bar, sidebars, action buttons, and other interactive parts of the application so the content can be sent cleanly to a printer or saved to paper or PDF through the browser. The same idea shows up in several places under the same name. Records expose it as a page-layout action, reports expose it on the report run page in Salesforce Classic, and Lightning list views expose it through a printer icon. Each one opens a stripped-down page that is easier to read on paper than the full app screen.

Privacy Center is the Salesforce administration product that lets companies manage personal data inside their Salesforce org against privacy regulations like GDPR, CCPA, and LGPD. It packages five operational capabilities (Right to Be Forgotten, Right of Access, retention policies, consent tracking, and policy audit) into a single Setup app so the data privacy team can act on a data subject request without writing custom code. Privacy Center is licensed as a paid add-on (not bundled with base Sales or Service licenses) and runs on top of the core Salesforce data model. It does not change where data lives; it gives the privacy team a workflow to find, delete, anonymize, export, or hold that data, plus an audit trail for the regulator. Most enterprise customers buy it after their first formal data subject request reveals how much custom Apex they would otherwise need to write to fulfill one.

A Private Branch Exchange (PBX) is a private telephone system that an organization runs to route calls between its own staff and the outside world. It owns the internal extensions, the call queues, and the lines that connect to the public phone network, so callers reach the right person without going through the carrier for every hop. In a Salesforce context, the PBX is the phone system that sits behind a contact center. It is not a Salesforce feature itself. Salesforce connects to it through a computer telephony integration (CTI) layer, usually Open CTI or Salesforce Voice, so that calls handled by the PBX can trigger screen pops, click-to-dial, and call logging inside the agent's console.

Private Connect is a Salesforce feature that enables private network connectivity between a Salesforce org and external services (primarily on AWS, with growing support for Azure and GCP) without traffic crossing the public internet. The feature uses cloud-provider PrivateLink technology to establish private peering between the Salesforce environment and the customer's virtual private cloud, with traffic flowing over the cloud provider's internal network rather than over the public internet. The result is lower latency, stronger security guarantees, and compliance with network-isolation requirements that prohibit internet-routed traffic for regulated workloads. Private Connect is particularly relevant for financial services, healthcare, and government deployments where data flowing between Salesforce and internal systems must stay off the public internet. It also benefits any organization that has invested in private cloud architecture and wants Salesforce to fit into that model rather than requiring an exception for internet-routed traffic.

Private sharing is a Salesforce organization-wide default (OWD) access level. When an object is set to Private, only the record owner, users above that owner in the role hierarchy, Salesforce admins, and users granted access through sharing can view, edit, or report on those records. Private is the most restrictive OWD setting. It locks records down to their owners as a baseline, then lets you open access back up deliberately through role hierarchy, sharing rules, manual sharing, and other features.

Probability is a standard percentage field on the Salesforce Opportunity record that shows how likely a deal is to close. It runs from 0 to 100 percent and ships on every opportunity in Sales Cloud. The value is usually set by the opportunity Stage. Each stage carries a default probability, so moving an opportunity from one stage to the next updates the number for you. A sales rep can still type a different value when a specific deal does not behave like the average deal at that stage.

A Process API is the middle tier in MuleSoft's API-led connectivity model. It orchestrates and shapes data drawn from one or more System APIs (and sometimes other Process APIs), holding the business logic that turns raw system data into something a specific business process needs. A Process API does not talk to databases or backend systems directly. Instead it calls System APIs, then merges, transforms, and enriches their responses to model a business need. Experience APIs and other consumers call the Process API for that shared logic, so the rules live in one place rather than being copied into every channel.

Process Automation Settings is a Setup page in Salesforce where an administrator configures org-wide options that apply to the automation engine. The page is small, but the handful of fields on it shape how Flow, the retired Process Builder, and the older Workflow Rules behave across the whole org. It covers who appears as the running user when a triggering user is inactive, who receives error emails, and whether people can pause flow interviews. You reach it from Setup by typing Process Automation Settings into the Quick Find box. Most teams set these values once during initial setup and then revisit them only when automation reporting or error handling needs a change. The settings sit underneath every individual automation, so a wrong choice here can quietly affect debugging and audit trails everywhere.

A Process Instance is the runtime record Salesforce creates each time an Approval Process is started on a specific record. It tracks the current step, the assigned approvers, the timestamps of every transition, and the final outcome (approved, rejected, recalled, or still pending). Each running approval on a record produces one ProcessInstance row, accessible through the API and queryable in SOQL alongside its child ProcessInstanceStep and ProcessInstanceWorkitem records. Process Instance is the audit substrate of every Salesforce Approval Process. The Approval Process definition (entry criteria, steps, approvers, actions) is metadata; the Process Instance is the runtime data showing what happened in a specific approval. Auditors, compliance officers, and developers building approval analytics dashboards all query ProcessInstance to answer questions like "how many discounts above 30 percent were approved last quarter" and "average approval cycle time per region." The instance is also the data structure recalled when a user clicks Recall Approval on a pending record.

A Process Instance Node in Salesforce is a record on the ProcessInstanceStep object (and its newer ProcessInstanceNode counterpart) that represents a specific step within an active or completed approval process. Each Approval Process is composed of one or more steps; when a record enters the process, the platform creates a ProcessInstance record to track the overall approval journey, and creates a ProcessInstanceNode record for each step the record passes through. The nodes carry the approver identity, the action taken (approved, rejected, recalled, removed), the timestamp, and any comments the approver added. The objects exist because approvals in Salesforce can be complex: parallel approvers, dynamic approver chains, criteria-based step entry, recall-and-restart cycles. The Process Instance Node records are the immutable audit trail of what actually happened at each step, who acted on it, when, and what they said. Compliance teams and process designers rely on these records for audit, debugging, and process improvement.

Process Visualizer is the read-only Salesforce tool that displays an Approval Process as a flowchart, showing each step, the entry criteria, the assigned approver, the actions on approval and rejection, and the routing path from start to final outcome. It exists alongside the Approval Process setup screen and renders the configured approval logic in a way humans can read at a glance, which is useful for documentation, audit walkthroughs, and onboarding new admins to an inherited org. Process Visualizer reads existing approval processes; it does not author or edit them. The flowchart it produces is a snapshot of the configuration at the time the visualizer opens. Salesforce shipped Process Visualizer before Flow Builder absorbed most declarative automation work, so the tool today is most useful for legacy approval processes that have not been converted to flows and for documenting complex multi-step approval chains that survived multiple org migrations.

A Product in Salesforce is a catalog item your company sells: a software subscription, a hardware unit, a service tier, a consulting engagement, anything you can put on a price list. The Product object (Product2 in the API, a legacy naming choice from the platform's early days) holds the name, the product code, the family, the description, whether it is currently active, and whatever custom attributes your org tracks for catalog management. Every Opportunity Line Item, every Quote Line Item, and every Order Line Item in a Salesforce org traces back to a Product record through a Pricebook Entry. Product describes what your company sells; Asset describes what your customer owns. The distinction confuses new users because in casual conversation people say "I bought the product" to mean both the catalog item and the specific copy they own. In Salesforce data model terms, those are different objects. The Product catalog is a small set of records (dozens to hundreds in most B2B orgs, occasionally thousands in retail or industrial orgs). The Asset table is a large multiple of that, holding one record per customer-owned instance. Understanding the Product-Asset distinction is the first step to building any reporting that crosses sales motion and service motion.

A Product Family is a picklist value on the Product2 object that lets you group products into broader merchandise categories for forecasting, reporting, and quota allocation. Salesforce Sales Cloud uses Product Family to slice the standard Customizable Forecast and the Forecasts hierarchy by category, so a sales leader who sells hardware, software, and services can see a separate forecast number for each line of business instead of one blended total. Product Family is a single picklist field, not a separate object, and a product can belong to exactly one family. The values are admin-defined and used wherever a forecast or report rolls revenue up by category. The same field also drives Quotas in Forecast Categories, lets sales ops set different commission accelerators by family, and acts as a natural filter on Opportunity Product reports when leadership asks how the new SaaS line is pacing versus the legacy hardware book.

Product Settings is the area in Salesforce Setup where an administrator controls how the Product object, Price Books, and product schedules behave across the org. The most consequential choice on this surface is whether to enable product schedules, which let a single product spread its quantity and revenue across multiple dates instead of landing as one lump sum. Most of these controls live in Setup, with related options sitting on the Opportunity and Opportunity Product page layouts and in the Schedules section under Setup. The settings are org-wide, so they shape every sales rep's pricing and forecasting experience, not just one team's.

Checkout is the staged process in Salesforce B2B and D2C Commerce that turns a buyer's cart into a placed order. It runs a sequence of steps that collect a shipping address, calculate shipping and tax, take payment, and create the order record. The whole thing lives inside a single Checkout component placed on a store page in Experience Builder. The way checkout is built depends on the store template. Stores on the older Aura template run checkout as a Flow Builder flow made of smaller subflows. Stores on the newer LWR (Lightning Web Runtime) template use the packaged Salesforce Commerce Checkout, which is a set of Lightning web components you arrange and customize. Both produce the same outcome: an order ready for fulfillment.

A production organization is a Salesforce customer's live org, the environment where real business data lives and end users do their actual work. Sales reps log opportunities here, service agents handle real cases, and the reports leadership reads pull from this data. It is the org you pay for, the one tied to your contract and your editions, and the single source of truth for the business. A production org sits in contrast to non-production environments like sandboxes and scratch orgs, which exist for building and testing. Salesforce provisions the production org when you become a customer, and every sandbox you spin up is a copy of it. Because real users and real records depend on it, changes are meant to be built and validated elsewhere first, then deployed into production through controlled steps.

Professional Edition is a paid Salesforce CRM edition built for small and midsize teams that want full sales and service functionality without enterprise-level complexity. It includes account and contact management, leads, opportunities, campaigns, products and price books, forecasting, and customizable reports and dashboards. Salesforce positions it for any small to midsize deployment that needs straightforward customization, integration, and administration tools. The edition sits in the middle of the current Salesforce lineup, above the Starter and Pro Suite tiers and below Enterprise and Unlimited. Its allocations are generous enough for a growing business but capped below Enterprise. The headline trade-off is around developer features: Professional Edition does not enable the API by default and does not let you write your own Apex, so heavy integration or custom code usually points you toward Enterprise.

A Profile in Salesforce is the foundational permission record that every User must have. The Profile defines what objects a user can read, create, edit, or delete; what fields they can see and modify (field-level security); which tabs and apps appear in their UI; which page layouts and record types render for them; and dozens of system permissions that control specific behaviors (Export Reports, Manage Public List Views, View Setup). Every User in a Salesforce org has exactly one Profile, and that Profile is the floor of their permission set. The original Salesforce design treated Profile as the single source of truth for what a User could do. Admins built one Profile per role (Sales Rep, Sales Manager, Service Agent, Read-Only User) and cloned new Profiles whenever a new role emerged. That worked at small scale but produced an unmanageable proliferation in larger orgs: forty Profiles, each subtly different, each carrying its own copy of every object and field permission, and every time a new field shipped somebody had to touch all forty Profiles. The shift in Salesforce best practice over the last decade has been to flatten Profiles to the minimum (a thin permission floor) and layer Permission Sets on top to grant the actual capabilities a user needs. The Profile becomes a template; the Permission Sets become the menu of options assigned per user.

A Chatter profile is the social, people-facing side of a Salesforce user's record. It pulls together a photo, an About Me statement, contact details, a personal feed, and the lists of who that person follows, who follows them, and which Chatter groups they belong to. Other users in the org can open it to learn who someone is and what they work on. The term is now treated as a legacy label. The same information still exists, but Salesforce folds it into the modern user profile page in Lightning Experience, often surfaced through the People list. Newer orgs rarely call it the "Chatter profile" on its own, yet the photo, About Me, and following model it described are still very much in use.

The Program Management Module (PMM) in Salesforce is a free, open-source application from Salesforce.org (now Salesforce for Nonprofits) that helps nonprofit organizations track programs, services, and client outcomes inside Salesforce. PMM provides the data model and the basic UI for a nonprofit operations team to manage program cohorts, schedule service deliveries, capture attendance, and measure impact across multiple programs and client populations. The module installs as a managed package on top of the standard Salesforce platform; nonprofits use it alongside NPSP (the Nonprofit Success Pack) or Nonprofit Cloud to handle the operational program-tracking needs that those broader products do not cover directly. PMM is designed for nonprofits running services that touch clients repeatedly over time: workforce development cohorts, mental health counseling appointments, after-school program sessions, food pantry distributions. The data model centers on Programs (the umbrella initiative), Program Engagements (a client enrollment in a Program), Service Schedules (the calendar of when the service is delivered), and Service Deliveries (the individual records of service rendered). Reports built on top of this model drive grant reporting, board updates, and program improvement decisions.

A Project in Salesforce DX is a local directory that the Salesforce CLI recognizes as a unit of source-driven development. It holds an sfdx-project.json configuration file, your metadata in source format, scratch org definitions, and the Git history your team works against. The CLI reads the project to know where source lives and how to sync it with an org. People also call it a DX project or a local project. It is the starting point for building, testing, and deploying customizations without clicking through the Setup UI. You generate one with the command sf project generate, then track the whole folder in version control.

A Project Manifest is the package.xml file that lists the metadata components Salesforce moves into or out of an org. It is an XML document that names each component (or asks for all of a type with a wildcard) and sets the API version for the operation. Salesforce uses this manifest with the Metadata API deploy() and retrieve() calls, the Ant Migration Tool, the Salesforce CLI, and the VS Code extensions. Think of it as the shopping list for a deployment. The manifest does not hold the metadata itself. It points to the components by type and name, and the tooling collects the matching source. People sometimes call sfdx-project.json the project manifest too, but that file is the DX project configuration, a separate thing covered below.

Promote is the Salesforce action of moving something to a more advanced, public-ready state. In second-generation packaging, it changes a package version from beta to released so the version can be installed in production and listed on AppExchange. In the older Salesforce Ideas feature, Promote is a vote that adds points to an idea to raise its ranking. The two meanings sit far apart, but they share one idea: promoting takes something tentative and advances it to a more definitive status. The packaging sense is the one most teams use today, and it is run from the Salesforce CLI with a single command.

Prompt Builder is Salesforce's tool for designing reusable prompt templates that combine generative AI with Salesforce data. Each template defines a prompt for a large language model, with merge fields that pull live data from Salesforce records, related records, Knowledge articles, Data Cloud objects, and other grounded sources. The platform substitutes the merge fields at runtime, sends the assembled prompt to an LLM, and returns the generated text. Prompt templates power email generation, sales summaries, service response drafting, and content creation throughout the Salesforce UI and across Agentforce agents. Prompt Builder is part of Einstein's generative AI stack. A prompt template has a type (Sales Email, Field Generation, Flex, Record Summary), an LLM target (Salesforce-hosted, OpenAI via Trust Layer, Anthropic Claude, or custom), grounding sources that pull contextual data, merge fields that inject record values, and a system prompt that frames the LLM's task. Admins build templates without writing code; developers can extend with Apex for advanced grounding. Templates surface in record pages, Sales Engagement, Service Console, Marketing Cloud, and as actions inside Agentforce.

A prototype is an early, purpose-built version of a feature, screen, flow, or whole solution that a team creates to answer a question before committing to a production build. Salesforce design guidance frames it precisely: a prototype is an experiment that answers a specific question in the design and build process. It is meant to be cheap to make, quick to change, and often thrown away once it has done its job. In a Salesforce context, prototypes are usually built fast using low-code tools in a safe environment like a scratch org or a sandbox. A team might wire up a screen flow, drop a few components onto a Lightning page, or stand up a draft Agentforce agent to see how an idea feels in the actual product. The point is to learn early, gather feedback, and reduce the risk of building the wrong thing.

A prototype object is a single sObject held inside a Visualforce StandardSetController. When you set field values on this one record and then call save(), Salesforce copies those values onto every record in the controller's collection. That is what makes it the engine behind mass-update Visualforce pages. The prototype object is not a separate object type you create in Setup. It is a runtime concept that lives inside the controller. You reach it in Apex with the getRecord() method, edit a field or two, and the StandardSetController applies the change across the whole selected set during the save action.

A Provider Organization in Salesforce Health Cloud is the standard data model representation of a healthcare organization or facility that delivers care to patients: hospitals, clinics, specialty practices, group practices, individual provider offices, urgent care centers, and similar entities. Each Provider Organization is stored as an Account record with the Health Cloud Provider record type, carrying healthcare-specific attributes like the National Provider Identifier (NPI), the organization's medical specialties, network affiliations, accepted insurance plans, accreditations, and operating locations. Provider Organizations sit at the heart of Health Cloud's data model alongside Patient records (Person Accounts), Health Plans, Health Conditions, Care Plans, and the various clinical observation objects. The relationships between these objects support the core healthcare workflows: a patient receives care at one or more Provider Organizations through specific Practitioners associated with each organization, and the care produces clinical encounters, observations, conditions, and care plan updates all linked back through the data model. Understanding the Provider Organization concept is foundational to any Health Cloud implementation because almost every clinical workflow involves at least one provider relationship.

A public calendar is a shared Salesforce calendar that holds a schedule of events for a group of users rather than one person. Admins create it in Setup, then decide who can see it and who can add events to it. Common uses include company holidays, training sessions, sales events, project milestones, and team shift schedules. Public calendars sit alongside individual user calendars and resource calendars. They give a team one agreed place for events that everyone needs to see, so people do not have to clutter personal calendars or copy dates by hand. A sales department, for example, can keep one calendar of expos and demo days that the whole team reads from.

A Public Group in Salesforce is an arbitrary collection of users used as a single sharing or access target. Where Role Hierarchy models the formal chain of command and Account Teams model per-record collaboration, Public Groups model anything that does not fit either pattern: a cross-functional Compliance Review group spanning Legal, Finance, and Sales Ops; a Strategic Accounts team spanning AEs from three regions; a Vertical Specialists group spanning sales and service users who all work the Healthcare segment. The Public Group has a Name and a Description, plus a membership list. Public Groups exist because real organizations rarely fit a clean tree. A Salesforce admin can model the org chart through Role Hierarchy, but the org chart describes who reports to whom, not who needs access to what. The actual access patterns in any large company are full of cross-cutting relationships that the hierarchy does not capture. Public Groups let you express those relationships explicitly, then use them as the target of Sharing Rules, List View visibility, Report and Dashboard folder sharing, Manual Sharing, and a handful of other places that need to grant access to a defined set of users.

Public Health Analytics Settings is a Setup page in Salesforce Health Cloud (and Public Sector Solutions) that configures pre-built analytics dashboards designed for public health agencies. The dashboards visualize disease surveillance signals, vaccination program performance, community health indicators, and emergency response coordination metrics. The settings page lets an admin select which dashboards to enable, configure the underlying data sources, and map the dashboards to user roles so the right people see the right metrics during the right operating cadence. The feature sits inside the broader Salesforce Public Health portfolio, alongside contact tracing, vaccination management, case investigation, and outbreak response tools. It targets public health departments at the federal, state, county, and city levels, plus public-facing healthcare organizations that report into national surveillance systems. The pre-built nature of the dashboards is the value proposition: standing up public health analytics from scratch is a multi-quarter project, while enabling the pre-built dashboards is a multi-week one.

A published article is a Salesforce Knowledge article version whose publish status is Online, meaning it is live and visible to the audiences chosen for it. Those audiences are the article channels: the internal app for agents, plus the Customer, Partner, and Public Knowledge Base channels for external readers. Publishing is the moment a draft becomes a real answer that people can find. Until an author or knowledge manager clicks Publish, the content stays in Draft and only authorized users can see it. Each article keeps a version number, and only one version can be Online at a time.

A Published Translation is a translated version of a Salesforce Knowledge article that has finished translation, been published, and is now live for readers in that language. It is the language-specific counterpart to the master article, sharing the same article record but holding its own body, title, and publish status in a target language like French, German, or Japanese. In data terms it is a KnowledgeArticleVersion row whose Language is the target language and whose PublishStatus is Online. When a reader's language preference matches that translation, Salesforce serves them the published translation instead of the master-language version, so a French customer reads French and a Japanese customer reads Japanese from the same underlying article.

Publisher in Salesforce has two distinct meanings depending on context. In Chatter and Experience Cloud, the Publisher is the user (or system) that creates and shares a feed post, a Knowledge Article, a Question, or any other piece of content in a feed or community. The Publisher record is the author identity attached to the content, and the Publisher permissions, profile, and role determine what content they can create and how it gets surfaced to readers. In the AppExchange and managed packaging context, a Publisher is the Independent Software Vendor (ISV) that builds and ships a managed package to Subscriber organizations. The Publisher maintains the source-of-truth Salesforce org (the License Management Org or LMO), owns the package metadata, controls the release cadence, and provides support to Subscribers. Both meanings show up on Salesforce certification exams; understanding which one is in play depends on the surrounding context.

A Publishing Cycle is the recurring schedule on which Salesforce produces, validates, and ships a major platform release to every customer org. Salesforce runs three Publishing Cycles per year (Spring, Summer, Winter) on a fixed cadence, with sandbox previews available roughly four to five weeks before each cycle's general-availability date in production. The term also appears in narrower contexts. Salesforce Knowledge has a publishing cycle for an article (draft, in review, published, archived). Experience Cloud sites have a publishing cycle for site changes (work in progress, preview, publish to live). In every variant, the cycle is the structured sequence of states a piece of content (the platform itself, an article, a site) moves through between authoring and being visible to its audience.

Purchase Rules are the controls in Salesforce B2B Commerce that decide what a buyer is allowed to order and in what quantity. In current Salesforce documentation the feature appears as Purchase Quantity Rules, backed by the PurchaseQuantityRule object, with related entitlement policies governing which products a buyer group can even see. A Purchase Quantity Rule sets the minimum, increment, and maximum amount of a product a customer can add to the cart. The storefront enforces those limits at the point of purchase, so a buyer cannot order 3 units when the contract says they buy in cases of 12.

A mobile push notification is an alert that the Salesforce mobile app delivers to a user's phone or tablet about an event in Salesforce, even when the app is closed. The message can appear on the device lock screen or in the notification center, so the user learns about an approval request, a Chatter mention, a task assignment, or a custom event without opening the app first. Push notifications come in two flavors. Standard notifications cover use cases that Salesforce predefines, such as approval requests and @mentions. Custom notifications are ones an admin or developer defines for business events that matter to a specific org. Both flow through the same plumbing and reach the device through Apple and Google notification services.

Push Notifications in the Salesforce Console are visual indicators that appear in the Salesforce Classic console when a record or field an agent is viewing gets changed by another user or a system process. They keep a support agent's screen current so two people working the same case or account do not step on stale data. The feature is built on the Streaming API and is configured per console app in Setup. This is a Salesforce Classic console feature. It is considered legacy because Lightning console apps, the Service Console and Sales Console, do not carry the same push notification configuration forward. If you are building new, you reach for Lightning list view auto-refresh, Change Data Capture, or Platform Events instead of Classic console push notifications.

A Push Upgrade is the mechanism a managed-package publisher uses to update every installed copy of their package across customer orgs at once, without each admin running the install wizard. The publisher selects a patch version inside the Subscriber Support Console, picks which subscriber orgs receive it, schedules a date, and Salesforce deploys the metadata change on that schedule. The admin sees the new version reflected in Setup the next time they open Installed Packages, and any new components show up where the publisher placed them. Push Upgrades only work for patch versions of a managed package, or for moving a beta to its corresponding general-availability release of the same major version. They never bump the major version, never change the API signature of public Apex classes, and never appear on unmanaged or unlocked packages. The patch namespace forbids breaking changes by design, which is what lets Salesforce promise that a push will not break compiled Apex or break a flow that references one of the publisher's fields in the subscriber org.