Salesforce terms starting with U

Unfollow is the action a Salesforce user takes to stop receiving Chatter feed updates from a record, person, group, or topic they previously followed. The act removes the EntitySubscription row that linked the user to the followed entity, which means new posts, comments, and field-tracked changes on that entity no longer appear in the user's Chatter feed or notification stream. Unfollow is the symmetric inverse of Follow. Salesforce stores both states in the same EntitySubscription object: when a user follows, a row is inserted; when they unfollow, that row is deleted. Field-level field tracking, post visibility, and notification routing all key off the existence of that row, so removing it has immediate effects across the bell, the digest email, the mobile push channel, and the Chatter feed itself.

The Unified Data Model in Salesforce Data Cloud is the standardized schema that maps incoming customer data from multiple source systems into a common structure that downstream consumers (analytics, segmentation, activation, AI models) can read consistently. Source systems vary widely in shape: Salesforce Sales Cloud uses Account and Contact; Marketing Cloud uses Subscriber and Contact; Service Cloud uses Case and Asset; external systems use whatever schema they were built on. The Unified Data Model harmonizes all of this into Data Cloud standard objects (Unified Individual, Unified Contact Point Email, Unified Engagement, etc.) so the rest of the platform sees one consistent picture per customer. Unification happens through Identity Resolution (matching records across sources based on configurable rules: email match, phone match, deterministic identifier match, fuzzy name match) and through Data Stream mapping (translating each source schema into the standard model). The result is the Unified Profile, the central record that ties every interaction back to one person. The Unified Data Model is the foundation that makes Data Cloud worth the platform investment.

Unified Health Scoring in Salesforce is the composite metric that aggregates multiple individual indicators (clinical risk factors in Health Cloud, engagement and retention signals in Customer Success contexts) into a single number or rating that gives care teams or account managers an at-a-glance view of where a patient or customer stands. The score is computed by a weighted formula over the inputs, displayed on the record page or in dashboards, and used to trigger automated workflows when the score crosses configured thresholds. The same conceptual pattern appears in two distinct Salesforce contexts. In Health Cloud, Unified Health Scoring rolls up clinical indicators (vitals, lab results, social determinants, condition severity) into a Care Risk Score that helps care managers prioritize patients. In Customer Success and Service Cloud, equivalent Customer Health Scoring rolls up engagement signals (product usage, support volume, renewal proximity, sentiment) into a Customer Health Score that drives renewal and expansion plays. The mechanics are similar; the inputs and downstream workflows differ by domain.

In Salesforce development, the API Name (also called Developer Name) assigned to custom objects, fields, and components that uniquely identifies them in code, formulas, and API operations, following the convention like My_Field__c.

A Unit in Salesforce Trailhead is a single instructional lesson within a module that covers one specific topic. Units typically combine a piece of reading content (concept explanation, code walkthrough, or screenshot-driven instruction) with a hands-on challenge or a multi-choice quiz that confirms the learner can apply what they just read. A learner earns points and progress toward the parent module each time they complete a unit successfully. Trailhead structures its content as a hierarchy: Trail (the top-level learning journey), Module (a self-contained subject), and Unit (the atomic lesson). Most modules contain three to seven units, each estimated to take 10 to 30 minutes. Units are the unit of completion that the Trailhead progress tracker counts. Completing every unit in a module unlocks the module badge.

A Unit Test in Salesforce is an Apex method, annotated with @isTest, that exercises a small piece of production Apex code in isolation and asserts the expected outcome. The platform requires unit tests for every line of Apex deployed to production: the org-wide code coverage minimum is 75 percent, and each individual trigger needs at least 1 percent coverage. Tests run in their own transaction with their own governor limits, they cannot see real production data unless the @isTest(SeeAllData=true) annotation is used (which is discouraged), and they roll back any DML they perform at the end of the run. Unit Tests are the gate between developer code and a successful production deploy. Salesforce executes the entire test suite during every metadata deploy to production and during package upload; a single failing test blocks the deploy. The same suite runs as part of every change set, every Salesforce DX deployment, every package upload, and every continuous integration pipeline. Mastering unit tests is therefore one of the highest-impact skills in any Salesforce development team.

Unlimited Edition is the premium tier of Salesforce CRM that bundles every Enterprise Edition feature plus enhanced support, expanded platform limits, additional sandboxes, premier success services, and several add-on entitlements that smaller editions buy separately. Salesforce positions Unlimited as the top tier for enterprise customers who run multiple business units on the platform, depend on Salesforce as a mission-critical system, and need the headroom that the lower editions cap. The edition sits at the top of Salesforce tiered pricing alongside Enterprise Edition, Professional Edition, and the developer-only Developer Edition. Each tier expands the available feature set, the API limits, the storage allocations, and the sandbox entitlements. Unlimited Edition is the choice when an org has already outgrown Enterprise Edition caps, when premier support is a contractual requirement, or when the bundled add-ons (Premier Success Plan, additional Full Sandbox, more API calls per day) cost more separately than the edition uplift.

An Unmanaged Package is a bundle of Salesforce metadata that an admin or developer assembles in one org and installs into another, with no namespace, no upgrade tracking, and no code protection. Unmanaged packages are the original packaging model on the Salesforce platform, predating managed packages and AppExchange. They serve a single use case: moving a set of components from one org to another in a way that is more deliberate than a change set and less ceremony than a managed package. Unmanaged packages are open. Every component installs into the subscriber org as a fully editable artifact. The Apex code is readable, the custom objects are renameable, the Flow definitions are forkable. There is no namespace prefix and no version tracking; once installed, the subscriber owns the metadata. This is the right model for templates, sample apps, training scaffolds, and internal sharing across orgs in the same company. It is the wrong model for any paid software product, because the customer can copy, modify, and resell the code at will.

An Update in Salesforce is any change to one or more existing records that modifies field values without creating or deleting the record. The platform stores updates as the new state of the record plus an audit-trail entry in the Field History (when field tracking is enabled), Setup Audit Trail (for metadata changes), or the Apex Debug Log (for DML operations). Every UI save, API update call, flow record update, and Apex update DML statement falls under this same term. The Update verb shows up across many surfaces. UPDATE is the Apex DML statement, update is the REST API method against an existing sObject endpoint, Update is the action category in Flow Builder for record assignments, and Field Updates are the workflow action that modifies field values declaratively. All four trigger the same platform machinery: validation rules run, before triggers fire, the row is rewritten, after triggers fire, field history is logged, and dependent automation cascades through the order of execution.

Upgrade, Checkout in Salesforce B2B Commerce is the cart-contextual upsell pattern that offers a buyer a higher-tier product, bundle, or service option during the checkout step. The buyer sees the upgrade prompt after they have decided to buy and before they confirm payment, which is the highest-intent moment in the purchase flow. The pattern is a configuration on the B2B Commerce storefront, not a standalone Salesforce product. Admins define which upgrade offers trigger for which cart contents, and the checkout page renders the offer between the cart review and the payment confirmation. The term carries a legacy label because Salesforce B2B Commerce has rebranded the feature several times across its CloudCraze acquisition and its integration into Commerce Cloud. The underlying pattern is alive in the current platform under newer names like Checkout Upsell Offer and Cart Promotion.

Upgrading in Salesforce managed packaging is the process of installing a newer version of a managed package into a Subscriber org that already has an earlier version installed. The platform applies the Publisher new metadata, code, and configuration without disturbing the Subscriber own customizations on top, and without deleting the records and data that already live in the org. Upgrades come in two flavors. Patch upgrades carry the patch number in the version (1.0.0 to 1.0.1) and are intended to be drop-in: bug fixes, security patches, no schema changes. Major version upgrades (1.0.0 to 2.0.0) can carry breaking changes such as schema additions, component renames, or behavior changes that require Subscriber-side reconfiguration. Reading the Publisher release notes before any upgrade is the difference between a smooth install and a midnight support call.

Uploading in Salesforce data management is the process of importing data from external files (CSV, XML, JSON) into Salesforce records using one of several tools: Data Import Wizard for small to medium loads through the UI, Data Loader for desktop-driven CRUD on any object including custom ones, the Bulk API or Bulk API 2.0 for large-volume programmatic loads, and third-party tools like Workato, Mulesoft, or Jitterbit for orchestrated workflows. The term covers both first-time data migration (loading historical records into a new org) and ongoing synchronization (nightly pushes from an ERP or warehouse). Uploading is not the same as inserting through the UI one record at a time. The defining characteristic is bulk: tens, thousands, or millions of records moved through a file-based pipeline rather than typed by hand. The choice of tool depends on the record count, the object, the user persona, and whether the load needs to repeat on a schedule.

URL is a Salesforce field data type that stores a web address as a clickable hyperlink - the field displays as a link on record pages, opens in a new tab when clicked, and stores the raw URL as text underneath. URL fields accept any valid URL syntax (no validation beyond basic format) and are the right type for website references, video links, document URLs, and any external resource a record should link to. Unlike a Text field with a URL inside, the URL field type renders as a live hyperlink without a formula.

A Usage-based Entitlement is a Salesforce Entitlement that tracks consumption of a limited support resource (cases, support hours, or any countable unit) and enforces a cap on how much support a customer can request under the contract. A platinum support contract might include 50 cases per year; once the customer files the 51st case, the entitlement no longer auto-matches and a Flow can prompt the customer for upsell or block the case. The Usage-based pattern is one of the standard variations of Entitlement Management. Usage-based Entitlements are useful in two scenarios. Tiered support contracts where the higher tier includes a finite number of incidents instead of unlimited support. Time-banked support where customers buy a block of hours upfront and the org tracks remaining hours per case. The pattern is rare compared to time-based entitlements (a contract valid for 12 months regardless of case count), but it appears in B2B service deals where the vendor wants to limit support consumption while preserving the right to renew or upsell.

A User in Salesforce is a standard object that represents an individual login account in the org - every person who signs into Salesforce has exactly one User record. The User object stores authentication and profile data including username, email, name, alias, time zone, locale, federation ID, and the assigned Profile that controls baseline permissions. Each User is also associated with a Role (for record sharing), one or more Permission Sets and Permission Set Groups (for additive access), a User License (which determines available features and pricing), and a manager (for hierarchy-based reporting and approvals). Users own records - almost every standard and custom object has an OwnerId field that references a User. Beyond standard logins, the User object also represents Customer Community Users, Partner Users, Guest Users, Site Users, Integration Users, and Automated Process Users, each tied to a specific User License type. Active User counts directly drive Salesforce billing, so admins must deactivate (not delete) departed users to free up licenses while preserving historical record ownership.

User Acceptance Testing (UAT) in Salesforce project delivery is the testing phase where end users validate that the implementation meets business requirements and behaves correctly in real-world scenarios before final sign-off and production go-live. UAT happens after system testing and integration testing have confirmed the technical correctness of the build; UAT verifies that the build actually solves the business problem from the perspective of the people who will use it daily. The phase is mandatory for any non-trivial Salesforce project because business users find issues that developers and testers cannot anticipate. UAT in Salesforce is typically conducted in a Full Copy sandbox or a dedicated UAT environment that mirrors production as closely as possible: same metadata, same integrations enabled, representative sample data, real user profiles and permissions. End users execute scripted test scenarios covering their key workflows and capture findings: passes, failures, change requests, suggestions. Sign-off from UAT is the gating event for go-live; without explicit business signoff, the project does not move to production. The discipline distinguishes successful Salesforce deployments from troubled ones.

User Interface in Salesforce is the visual presentation layer that users interact with to view records, perform actions, run reports, and consume any feature the platform exposes. The current standard UI is Lightning Experience, the responsive, component-based experience Salesforce introduced in 2015 and made the default in 2019. Older orgs may still use Salesforce Classic, a deprecated UI that remains operational for backward compatibility but receives no new investment. Beyond these two primary desktop experiences, the Salesforce UI portfolio includes the Salesforce Mobile App (the native iOS and Android client), Experience Cloud sites (external-facing UIs built on the same platform), and custom interfaces built with Visualforce, Aura Components, or Lightning Web Components. Each surface serves a different audience and use case, but all read from the same underlying data model and metadata, so a record looks consistent (within layout and FLS constraints) across every interface.

A User License is the base license that defines what kind of Salesforce login a user has - Salesforce (full CRM), Salesforce Platform (custom-app-only), Chatter Free, Chatter External, Customer Community, Customer Community Plus, Partner Community, and others. It gates which objects and features the user can ever access; Permission Sets, Permission Set Licenses, and Feature Licenses layer on top to grant specific capabilities within the user type. A user has exactly one User License, assigned at user creation.

User Management Settings is a Setup page where administrators configure global settings for user account management, including enabling enhanced profile management, scrambling user data for deactivated users, and controlling the user self-deactivation feature.

A User Permission in Salesforce is a single named capability that grants a user the right to perform a specific action: View All Data, Modify All Data, Manage Users, Run Reports, Customize Application, Send Email, Edit Read-Only Fields, and roughly two hundred others. Each permission is a boolean flag the platform checks when a user tries to perform the action; if the flag is true on any profile or permission set the user is assigned, the action is allowed. User Permissions are the building blocks of the Salesforce security model alongside Object Permissions (CRUD on objects), Field-Level Security (read or edit on fields), and Sharing (record-level access). A user's complete authority is the union of every permission on their Profile plus every Permission Set assigned to them. The administrator's role is to grant exactly the user permissions each user needs for their job and not a single one more, an exercise in least-privilege design that becomes harder as the org and the user permission catalog both grow.

User Provisioning for Connected Apps in Salesforce is a feature that automates the creation, update, and deactivation of user accounts in third-party applications that have been wired into Salesforce as Connected Apps. The Salesforce org acts as the identity authority, and lifecycle events (a new hire is provisioned, a role changes, an employee leaves) push directly to the target application without manual account management on the receiving end. The feature uses the standard SCIM 2.0 protocol where the third party supports it, and falls back to a custom Apex-based connector where it does not. Salesforce ships a User Provisioning wizard inside the Connected App configuration that maps Salesforce user attributes (name, email, role, manager, custom fields) to the receiving application's user schema and defines which Salesforce events trigger which provisioning actions.

Users is a Setup page that displays all user records in the org and provides tools to create, edit, freeze, and deactivate user accounts. It shows each user's name, username, profile, role, license type, and active status, serving as the central hub for user management.

An utterance is a single user input to an AI conversational system. In a chatbot context, an utterance is everything the user types or speaks in one turn before the bot replies. In NLP training, an utterance is one example sentence the model uses to learn what intent or topic it represents. In Salesforce, the term is most common in Einstein Bots and Agentforce, where the utterance is the customer message that the bot's NLP layer must map to a known intent (or, in Agentforce, to an agent topic) before the conversation can advance. Utterances are the unit of measurement for how well a conversational AI understands its users. A bot trained on 50 carefully curated utterances per intent will recognize a customer's I want to cancel my subscription no matter how it is phrased. A bot trained on five utterances per intent will misroute most variations and dump the customer to a human. Utterance design is the most important and most under-invested part of any bot project. The platform handles the language model. The team owns the utterance set.