Salesforce terms starting with N

A Named Credential is a Salesforce configuration that stores the endpoint URL and authentication details for an external service in one named, secured construct. Apex callouts, Flow HTTP actions, and Salesforce Connect external data sources reference the Named Credential by name instead of hardcoding URLs and credentials. This keeps secrets out of code, simplifies environment-specific URL handling, and centralizes credential rotation across every integration that uses the service. Named Credentials sit at the intersection of integration and security. They support multiple authentication protocols (Password, OAuth 2.0, JWT bearer, AWS Signature Version 4, mTLS, and custom headers), handle the authentication handshake automatically, and refresh OAuth tokens as needed without the caller writing any token-management code. The modern Named Credential model (introduced in 2022) separates the endpoint configuration (External Credential, Permission Set Mapping) from the URL routing (Named Credential), which makes credential reuse across multiple endpoints clean and audit-friendly.

Named Query API is a Salesforce feature that lets administrators define and govern reusable SOQL queries that external systems can invoke through the API by name and parameter values rather than by sending the full SOQL string. Each Named Query is a server-side stored query with declared parameters, controlled access, and predictable performance characteristics. The API consumer passes the query's name and parameter values, and Salesforce executes the predefined query. The feature solves several problems with the traditional REST or SOAP query approach. Direct SOQL execution from external clients requires the client to know the data model in detail, including object and field API names. It also requires the org to trust each client with enough access to construct any query. Named Queries reverse the trust model: the admin defines what queries are allowed, the client only passes parameters, and the org governs which clients can call which queries. The result is safer, more performant, and more maintainable than the do-it-yourself SOQL approach.

A Namespace in Salesforce is a unique two-to-fifteen-character prefix assigned to a Developer Edition org that uniquely identifies all metadata components published in managed packages from that org. Every API name, every custom object, every custom field, every Apex class, every Lightning component packaged from a namespaced org carries the namespace prefix when installed in subscriber orgs: namespace__ObjectName__c, namespace.ClassName, namespace:ComponentName. The prefix prevents naming collisions between AppExchange packages and customer-created metadata. Namespaces are AppExchange-partner infrastructure. Salesforce assigns one namespace per Developer Edition org (typically the partner''s Packaging Org), and the partner publishes managed packages from that org. Subscribers installing the package see the namespace prefix on every component, which lets them distinguish package-installed metadata from their own custom work. Customer orgs do not normally use namespaces; the namespace concept is partner-specific infrastructure that exists to support the multitenant packaging story.

A Namespace Prefix in Salesforce is the unique alphanumeric identifier (1 to 15 characters, starting with a letter) registered for a managed package that prepends to every component shipped in that package. Every custom object, custom field, Apex class, Lightning component, page layout, and other metadata element from a managed package carries the namespace prefix in its API name, separated from the local name by a double underscore. The prefix ensures that components from different packages never collide with each other or with customer-org-local components, even when they share the same local name. For example, a custom object named ProjectTask in a package with namespace prefix acme appears in subscriber orgs as acme__ProjectTask__c. The same package's Apex class named ProjectHelper appears as acme.ProjectHelper. Customer-org-local custom fields on the same object remain in the org's default namespace (no prefix), so an admin who adds a field named Region__c to an installed namespace package's object sees it as Region__c (not acme__Region__c). This separation between vendor-shipped and customer-added components is what makes managed packages safe to upgrade without breaking customer customizations.

A native app on Salesforce is a packaged application built entirely on the Lightning Platform using only platform-native building blocks. That means Apex classes and triggers, Lightning Web Components or Aura, Visualforce pages, custom and standard objects, flows, validation rules, and platform events. All data, business logic, and user interface live inside the customer's Salesforce org rather than calling external systems for core functionality. The distinction is sharpest in the AppExchange listing flow, where Salesforce labels every offering as native, composite, or external based on where the work happens. Native apps inherit the platform's security model, sharing rules, field-level security, audit trail, encryption at rest, and disaster recovery automatically. They install through managed packages, share the org's governor limits with everything else running there, and never require a separate login or hosting bill.

A navigation tab in Salesforce is an item that appears in the navigation bar of a Lightning app, giving users a one-click path to an object's list view, a Lightning page, a Visualforce page, a web tab, or a utility item. Each app has its own ordered set of navigation tabs, defined under Setup > App Manager > Edit App > Navigation Items, and admins control which profiles or permission sets see which app. Navigation tabs are the most visible piece of Lightning Experience information architecture. They decide what the user sees first, what is one click away, and what is buried inside the App Launcher. A poorly designed navigation bar pushes daily-use objects to the third or fourth click and parks rarely-used ones in plain view; a well-designed one mirrors the user's actual workflow.

Net Promoter Score is a customer-loyalty metric that ranges from negative one hundred to positive one hundred. Customers answer one question on a zero-to-ten scale: how likely are they to recommend the company, product, or service to a friend or colleague. The score is calculated as the percentage of Promoters (scores 9 and 10) minus the percentage of Detractors (scores 0 through 6). Passives (7 and 8) are excluded from the math but tracked separately. Inside Salesforce, NPS lives wherever the survey response lands. Feedback Management runs the survey through Salesforce Surveys, writes responses into the SurveyResponse object, and links each response to the Account, Contact, Case, or Opportunity it relates to. Reports and dashboards roll the raw scores into the percentage-based NPS metric, segment it by region or product, and feed at-risk accounts into a customer success workflow.

Net Zero Cloud is Salesforce's sustainability management application for tracking, calculating, and reporting an organization's environmental footprint. It captures carbon emissions across Scope 1 (direct operations), Scope 2 (purchased electricity), and Scope 3 (value chain), pulls activity data from utility bills, travel systems, and supplier records, and applies emission factors to produce auditable carbon, water, and waste metrics. The product ships as a managed package layered on top of the Lightning Platform, so emissions data lives in custom objects, governance rules follow standard sharing and audit trail, and reports build in the familiar report builder. Net Zero Cloud connects to common disclosure frameworks such as CDP, GRI, SASB, TCFD, and the EU CSRD, and surfaces benchmarks against industry peers. Common users are sustainability officers, ESG analysts, and CFO offices preparing mandatory climate disclosures.

Network Access is the Salesforce Setup configuration that defines trusted IP ranges from which users can log in without triggering Identity Verification challenges. The page exposes a list of IP address ranges that the platform considers trusted networks (typically corporate office IPs, VPN endpoints, or known partner infrastructure). Users logging in from within these ranges skip the verification prompt that would otherwise fire on a new device or location. Network Access works alongside per-profile Login IP Range restrictions; Network Access is org-wide trust, profile-level Login IP Range is per-profile restriction. The two settings serve different purposes that are often confused. Login IP Range on a profile restricts which IPs users with that profile can log in from; users outside the range cannot log in at all. Network Access lists trusted ranges that exempt users from verification but still allow login from any IP. Most B2B orgs configure both: Login IP Range to restrict integration users to specific data center IPs, Network Access to reduce verification friction for office-based employees.

A New Business quote in Salesforce CPQ is the quote type generated when a customer has no existing subscription or active contract for the products being sold. It is the first quote in a customer relationship for a given product family. CPQ distinguishes between four quote types: New Business, Renewal, Amendment, and Co-Term. The type drives which workflow runs, which pricing rules apply, and how the resulting subscriptions get stamped on the contract. New Business quotes start fresh: every line is a new subscription with a fresh start date, no proration against an existing term, and standard list-price logic. They are usually created directly from an Opportunity with the Generate Quote button, where the sales rep configures products, applies discounts, and submits for approval. Once Order Now or Contracted, the resulting subscriptions become the baseline against which Amendment and Renewal quotes are calculated.

Next Best Action (NBA) is a Salesforce feature that surfaces recommended actions on a record based on rules, predictive models, or both. The user sees a list of recommendations on the page layout (call this contact, offer this discount, escalate this case) and accepts or rejects each one. Behind the recommendation is a strategy in the Strategy Builder canvas: a sequence of load, branch, and prioritize nodes that decides which actions from a defined action set qualify for the current record and in what order. Next Best Action sits between predictive scoring and automation. A predictive score sitting on a record is dormant until someone consumes it. A flow that fires automatically removes the human from the decision. NBA is the in-between: the score informs a recommendation, the user decides whether to act, and the platform tracks acceptance rates. It is one of the most under-used features in the Salesforce AI portfolio because the setup is unfamiliar (Strategy Builder is its own canvas), but for any team running recommendation workflows it is the right tool.

A Next Best Action Strategy is the graph of nodes built in Strategy Builder that decides which recommendations qualify for the current record and in what order. The strategy lives as a metadata record in the org, is versioned, and is referenced by one or more Einstein Next Best Action components on Lightning pages. When the page loads, the platform runs the strategy against the current record context, evaluates each node, and returns the top recommendations to the component. The strategy is where business logic lives in a Next Best Action deployment. Recommendations describe what could be offered. The strategy decides which ones to offer right now, on this record, to this user, based on rules, predictive scores, and external inputs. A strategy can be as simple as load-and-prioritize (show every recommendation, top three by static priority) or as complex as a multi-branch graph mixing Einstein predictions, related-record lookups, and CRM Analytics scores. Strategy complexity is a design choice tied to the team's appetite for maintenance.

Nickname is a standard field on the User object in Salesforce that holds a display name shown in place of a user's full name in specific contexts. The most common use is Experience Cloud (formerly Communities), where the Nickname appears on profile pages, in chatter posts, and in feed items so external community members do not see employees' or other members' real names. Internal users rarely interact with the field because the core Lightning Experience UI uses the Name field instead. The Nickname field is required and unique within an org, and Salesforce auto-populates it during user creation if the admin does not enter one. It defaults to the first part of the username for internal users and to a derivative of First Name plus Last Name for external community users. End users can update their own Nickname through the personal information settings if the admin grants the right.

An NLP model (natural language processing model) is a machine learning model trained to understand or generate human language. In Salesforce, NLP models power the language understanding behind Einstein Bots, the intent classifier behind Service Cloud routing features, the case classification engine that fills in Type and Reason fields automatically, and the foundation language layer that Agentforce builds on top of. The term covers both classical NLP models (intent classifiers, named entity recognizers, sentiment analyzers) and large language models (the transformer-based generative models behind Einstein Generative AI). In an admin's day-to-day, NLP model usually refers to the configurable language model behind a bot or text classification feature. The admin picks the model in Setup, points it at a labeled dataset (utterances for bots, historical cases for classification), and the platform handles training. The model produces a probability distribution over possible labels and the feature consumes the top match. The model is rarely the limiting factor in a project. Data quality and label design almost always are.

Nonprofit Cloud is Salesforce's product suite designed specifically for nonprofit organizations, providing an integrated platform for fundraising, donor management, program delivery, grant management, volunteer coordination, and outcome tracking. The current Nonprofit Cloud product is built on the broader Salesforce Customer 360 platform and replaces the older Nonprofit Success Pack (NPSP) model, although NPSP-based orgs continue to operate and Salesforce maintains a migration path between the two architectures. The Nonprofit Cloud product addresses the specific operational reality of nonprofit organizations: donors are different from customers, grants have multi-year lifecycles, programs need outcome measurement rather than revenue measurement, and volunteer coordination is its own workflow. Each of these is supported by Nonprofit Cloud's data model and pre-built features. Salesforce.org, the nonprofit-focused division of Salesforce, has supported the nonprofit sector for over two decades through the Power of Us program (10 free Salesforce subscriptions for eligible nonprofits) and the Nonprofit Cloud product offering, making Salesforce one of the most widely adopted technology platforms in the global nonprofit community.

A Note in Salesforce is the legacy standard object (Note in the API) that stores short, plain-text annotations attached to a parent record. Each Note has a Title, a Body field (up to 32 KB of plain text), a polymorphic ParentId pointing to almost any standard or custom record, an OwnerId, and an IsPrivate flag that hides the note from anyone except its owner. Notes were the original way users captured ad-hoc context on Accounts, Contacts, Opportunities, Cases, and other records before Salesforce introduced Lightning Notes (the ContentNote object) with rich-text formatting, file attachments, and modern collaboration features. The classic Note object remains in every org for backward compatibility and is still surfaced through the Notes & Attachments related list, but Salesforce recommends using Lightning Notes for all new notes - they support inline formatting, images, multi-record sharing, and survive Lightning Experience migrations cleanly.

Notes in Salesforce is the standard feature for capturing short, free-form text against any record, with rich formatting, images, and a per-record related list. The modern version is called Enhanced Notes and stores each note as a ContentNote record under the Files system, replacing the legacy Note object (now called Classic Notes) that stored notes as plain-text records on the Note sObject. Enhanced Notes supports formatted text (bold, italic, lists, links), inline images, version history, and sharing to other users or records. Users create notes from the Notes related list on a record, from the Global Actions menu, or from the Salesforce mobile app. The feature is enabled by default in new orgs but must be explicitly turned on in older orgs that started before Spring 16.