Salesforce terms starting with L

Language Settings is the group of Salesforce Setup configurations that control which languages an org runs in and how users see translated content. It governs two separate things that admins often mix up: the display language each user sees in the interface, and the content language used to translate picklist values, field labels, and other metadata through the Translation Workbench. Both work together for a multi-language org, but they are configured in different places and behave differently. Salesforce sorts every language into one of three support levels, and that level decides how much translation you get for free. Fully supported languages translate the whole interface, including Setup and Help. End-user languages translate standard object labels and end-user pages but leave Setup, admin pages, and Help in English. Platform-only languages provide no standard translation at all and exist so you can localize the custom apps you build. Knowing which level your target language falls into is the first thing to check before you promise localization.

A large language model (LLM) is a neural network trained on enormous text corpora that can generate, summarize, translate, classify, and reason about natural language. Inside Salesforce, LLMs power Agentforce reasoning and responses, Einstein GPT generation features, Prompt Builder outputs, Einstein Copilot conversations, and a growing list of GPT-flavored capabilities across Sales, Service, Marketing, and Commerce Clouds. The LLM is the foundation; the Salesforce platform layer around it (grounding, masking, governance) is what makes it usable on regulated business data. Salesforce does not train its own foundational LLM. The platform brokers calls to vendor models (Anthropic, OpenAI, Google, plus Salesforce-tuned variants of vendor models) through the Einstein Trust Layer. The Trust Layer enforces data masking, residency, and a no-training-on-customer-data contract that vendor models on their own do not provide. The choice of model per feature is largely a Salesforce-managed decision, with admin overrides available for specific use cases through Model Manager and Bring Your Own LLM.

A Layout in Salesforce is the configuration that decides how fields, related lists, buttons, and actions appear on a record page. The platform runs two layout systems side by side. Page Layouts are the original system that controls the field form, related lists, and actions on a record's detail and edit view. Lightning Pages, built in the Lightning App Builder, control the overall structure of the record page in Lightning Experience, including which components render and where. Layouts are assigned by profile and by record type, so the same object can show different forms to different users. A Lightning Page typically wraps a Page Layout (or a set of Dynamic Forms field sections) inside its component structure. Compact Layouts and Search Layouts are separate layout types that govern the Highlights panel and list or lookup columns. Most modern orgs configure several of these layers together for a single object.

A Lead is an unqualified prospect record in Salesforce: a person or company that has shown interest in what you sell but has not yet been validated as worth the sales team's time. Leads carry name, company, email, phone, status, source, and any other discovery fields your org collects. They sit in a holding pattern (Open, Working, Nurturing, or whatever Lead Statuses your org configures) until they convert into an Account, a Contact, and usually an Opportunity, or they get disqualified out of the funnel. The Lead object exists because Salesforce wants to keep prospects separate from customers until somebody on the team has decided they belong. A Lead is not yet an Account. A Lead is not yet a Contact. Mixing the two breaks reporting (your "active customers" count balloons with people who never actually bought) and breaks sharing (Account-team rules do not extend to prospects who have not been mapped to an Account yet). Lead conversion is the moment a prospect graduates into the customer schema, and the design of that conversion process is one of the best uses of a sales operations team's time.

A lead assignment rule is a Salesforce automation that routes newly created or edited Lead records to the right user or queue based on field values. Each rule contains a prioritized list of entries, and the platform evaluates them in order from top to bottom, stopping at the first match. The matched entry determines the assignee, the email notification, and any associated routing logic. Lead assignment rules are the foundation of every Salesforce sales operation that handles inbound interest at scale. Web-to-Lead forms, marketing automation handoffs, list imports, and partner referrals all flow through them. Without an assignment rule, a new Lead lands on the default owner (the user or queue configured in Lead Settings), which usually means a single person sees every Lead and the workload distribution fails on day one. The rule turns "all leads go to one inbox" into "leads land in the right hands automatically," and the entire downstream funnel benefits.

Lead Settings is the Setup-area page in Salesforce where admins configure org-wide behaviour for the Lead object: the default Lead owner for unassigned records, Lead conversion field mapping, the Web-to-Lead email response template, retention settings for converted leads, and the toggle that allows Lead reassignment from queue to user. It is the single most overlooked configuration area in Sales Cloud, because most admins build leads first and discover Lead Settings later when conversion behaviour does not match what the business expected. The page lives under Setup, Object Manager, Lead, Lead Settings (or directly via Setup, Quick Find, Lead Settings). The settings here change behaviour for every Lead in the org, retroactively in some cases. Editing Default Lead Owner reassigns existing unowned leads. Editing field mapping changes which Lead field values flow into the Account, Contact, and Opportunity at conversion. Editing retention changes how converted leads display in reports. Treat Lead Settings as a project, not a one-click toggle.

Length in Salesforce is the field attribute that sets the maximum number of characters or digits a field can hold. It appears on Text, Long Text Area, Rich Text Area, Number, Currency, Percent, Phone, Email, URL, and similar field types. When an admin creates a custom field, the Length entry is the sizing decision that shapes validation, integration limits, search behavior, and storage. The word also shows up in two other places. LEN() is a formula function that returns the character count of a string, and every standard field carries a fixed length you cannot change. Account.Name allows 255 characters, Opportunity.Name 120, and Contact.LastName 80. Apex and integrations that exceed those limits hit a STRING_TOO_LONG error, so the Length attribute is something both admins and developers have to plan around.

Lens Explorer is the interactive data-exploration tool inside Salesforce CRM Analytics (formerly Tableau CRM, originally Einstein Analytics, originally Wave Analytics). A lens is an ad-hoc query and visualization built against a single dataset. The Lens Explorer is the no-code interface where an analyst drops fields onto chart shelves, filters records, groups results, and drills into subsets. The chart you see is just a view of a query the platform builds for you in the background. Analysts reach for the Lens Explorer to answer one question at a time: revenue by region, conversion rate by source, churn by tenure. A lens can be saved and reused, clipped onto a dashboard, exported, or thrown away after a quick look. Lenses are also the building blocks of CRM Analytics dashboards, so most dashboard work starts as exploration in a lens. Salesforce has steered the broader analytics story toward Tableau, but the Lens Explorer is still the native exploration surface for orgs running CRM Analytics.

A Letterhead in Salesforce is a reusable branding wrapper for HTML emails sent from the platform. It holds the logo, the header and footer styling, the body and background colors, and standing footer content like a legal disclaimer. Any HTML email template that references the letterhead inherits all of that styling, so the template author writes only the message body. Admins build a letterhead once in Setup and point many templates at it. There are two flavors. Classic Letterheads are the original Salesforce Classic feature, built under Setup and consumed by "HTML (using Letterhead)" templates. Enhanced Letterheads are the Lightning Experience successor, created from the App Launcher and attached to a Lightning email template that uses the Handlebars Merge Language. Classic Letterheads cannot be created in Lightning Experience, but ones built earlier still render there. New branding work in Lightning orgs usually starts with an Enhanced Letterhead instead.

A library in Salesforce is a permission-scoped container for files in Salesforce Files and the older Salesforce CRM Content product. Each library has its own membership list and its own library permission, so the people who can read, upload, edit, and manage files are controlled at the library level rather than by the org-wide sharing model. In the data model a library is a ContentWorkspace record, and the files inside it are ContentDocument records with one or more ContentVersion revisions. A library is the right place to organize files by team, project, or function while keeping a clear line between who can edit and who can only view. Members can be individual users, public groups, or roles, and each member is assigned one library permission such as Viewer, Author, or Library Administrator. Libraries can stay internal, or they can be shared with Experience Cloud customer and partner users when you need to publish files outside the company.

A Library Permission is a named set of privileges in Salesforce CRM Content that controls what a member can do inside a particular content library. It is not a profile or a permission set. It is a separate record, created under Setup, then assigned to each user, public group, or role that belongs to the library. The same person can hold one permission in a Marketing library and a different one in an HR library, because each library carries its own membership list and each membership is tied to a permission. Every Salesforce CRM Content org created after the Spring '09 release ships with three ready-made library permissions: Viewer, Author, and Library Administrator. You are free to keep those three, edit them, or build your own with a custom mix of privileges. Library Permissions do not apply to personal libraries, since any Salesforce CRM Content user can save files to their own personal library regardless of membership. Behind the scenes each permission is a ContentWorkspacePermission record, so the model is queryable and deployable through the API and metadata.

A License Management Application (LMA) is the free, Salesforce-supplied managed package that AppExchange partners install to track every customer who installs their own managed packages. The org where the LMA lives is called the License Management Org (LMO), which is usually the partner's business org. Once you connect the LMO and your package in the Salesforce Partner Console, the LMA gives you a License record and a Lead record automatically each time a customer installs your solution from the AppExchange. The LMA is the backbone of the AppExchange partner business model. It lets an Independent Software Vendor (ISV) see who is using a package, for how long, and with how many seats. Partners use those records to follow up on new prospects, renew or expire subscriptions, gate access by seat count, and run reporting on the install base. Without the LMA, a partner has no built-in, programmatic view of their AppExchange customers.

A License Management Organization (LMO) is the Salesforce org where an AppExchange partner installs the License Management App (LMA). When you complete the standard partner signup, Salesforce provisions a Partner Business Org (PBO) with the LMA already installed, and that PBO becomes your LMO. The LMO is where license, package, and lead data lives for every managed package you publish on AppExchange. Each managed package is associated with exactly one LMO. After a package is linked, every customer install writes records back to that org. The LMA creates a Lead and a License record in the LMO each time someone installs your package. From there you track who installed, manage seats, change license status, and reach out to customers. The LMO is the partner side of your AppExchange subscription business, separate from each customer's own subscriber org.

Lightning App Builder is Salesforce's drag-and-drop tool for designing Lightning Experience pages without writing code. It is the canvas where admins assemble Record Pages (the detail view for each sObject), App Pages (custom landing pages), Home Pages (the user dashboard), and Embedded Service pages. Each page is built from Lightning Components, both standard (provided by Salesforce) and custom (built with Lightning Web Components or Aura). The App Builder transformed Salesforce page design when Lightning Experience launched in 2015. Where the classic UI used static page layouts with fixed sections, Lightning record pages built in App Builder can show different components to different users, react to record state, place fields anywhere on the page (via Dynamic Forms), and combine Salesforce-standard with custom components freely. App Builder is the foundation of every modern Salesforce UX customization, and admins who master it can build sophisticated user experiences without involving developers.

A Lightning Bolt Solution is a reusable Experience Cloud package that bundles a customized Experience Builder template, theme, pages, business process flows, and Lightning apps into one installable unit. The idea Salesforce sums up as "build once, then distribute and reuse." A consultant or ISV partner builds a site configuration once, exports it, then ships it to other orgs through AppExchange or a direct package install. This is an older feature. Salesforce promoted the Lightning Bolt brand heavily around 2016 to 2019, with more than 50 prebuilt solutions for healthcare, financial services, manufacturing, and retail. The export and packaging mechanics still exist in Experience Cloud today, but the marketing brand has gone quiet. For deep vertical needs, Salesforce now steers customers toward Industry Clouds like Financial Services Cloud and Health Cloud, and toward the standard Experience Cloud templates.

Lightning Components are the building blocks of the Salesforce Lightning user interface. Each component bundles a template (markup), JavaScript controller, optional Apex backend, CSS styles, and metadata into a reusable unit that admins compose onto pages via the Lightning App Builder. Two generations exist: Aura components (the original Lightning framework from 2014) and Lightning Web Components (LWC, introduced in 2018 and built on modern web standards). New development should use LWC; Aura is supported but deprecated for net-new work. Lightning Components run inside the Lightning Experience UI, the Salesforce mobile app, Experience Cloud sites, and Lightning Out embeds in external pages. They communicate with the Salesforce backend via Lightning Data Service, Apex method calls, or the User Interface API. Page layouts, record pages, app pages, home pages, and Experience Cloud pages are all assembled from Lightning Components, mixing standard components (provided by Salesforce) with custom components (built by admins and developers). The component model is the foundation of modern Salesforce front-end development.

The Lightning Design System (SLDS) is Salesforce's open-source design system and CSS framework that gives Lightning Experience its look and feel. It defines the visual language used across Lightning Experience, the Salesforce mobile app, Experience Cloud sites, and custom Lightning Web Components. SLDS bundles the styling hooks (colors, spacing, typography), the CSS utility classes, the component blueprints, and a public reference site at lightningdesignsystem.com that documents every pattern with markup examples. SLDS is the layer that makes a custom component look like it belongs in Salesforce. A developer adds SLDS classes to component markup (slds-button, slds-card, slds-grid) and the element inherits the Salesforce identity automatically: the same colors, spacing, hover states, and accessibility behavior. Inside Lightning Experience the styles load with no import or static resource. The system is also published on GitHub, so non-Salesforce web apps can install it and share the same visual language. In Spring '25 Salesforce introduced SLDS 2, a new architecture that prioritizes CSS custom properties.

A Lightning Email Template is a reusable email layout built in Lightning Experience and saved as an EmailTemplate record. You design it either in the drag-and-drop Email Template Builder or in an HTML editor, then reuse it anywhere Salesforce sends mail. Each template can carry merge fields, images, and styled content, so a rep clicks once and the recipient's name, account, and case details fill in automatically. Lightning Email Templates are the modern alternative to Classic Email Templates. Both produce EmailTemplate records and both ride the same email infrastructure, but the Lightning ones use a newer authoring surface and the Folders and Enhanced Sharing model for access control. The two systems run side by side. Most orgs keep older Classic templates for established processes and build anything new in Lightning.

Lightning Experience Insights is the set of built-in analytics features that show administrators and executives how people use Lightning Experience and how well it performs. The most visible surface is the Lightning Usage App, a packaged app that reports daily active users, the pages people visit most, how often users switch back to Salesforce Classic, and page-load timing measured as Experienced Page Time (EPT). You open it from the App Launcher by searching for Lightning Usage, and it ships with Lightning Experience at no extra cost. These insights exist because moving from Classic to Lightning was the platform's largest user-experience change. Admins needed a clear answer to two questions: are people actually using Lightning, and are the pages fast enough to keep them there. The Lightning Usage App answers both with ready-made dashboards instead of asking every customer to build reports by hand. Today most orgs run on Lightning, so the data matters less for migration tracking and more for ongoing tuning, such as finding slow record pages and low-adoption features that need a second look.

A Lightning Extension in Salesforce is any artifact that adds new functionality to Lightning Experience beyond what ships out of the box. The term covers several specific concepts: custom Lightning Web Components installed from the AppExchange or developed in-house, App Extensions configured on Lightning Console apps to add utility-bar tools, custom action overrides that replace standard buttons, and the Lightning Web Security extension allowlist that controls which third-party JavaScript can run inside the platform. Lightning Extensions are managed through several Setup pages depending on the type. AppExchange-installed extensions appear under Installed Packages. Org-local custom Lightning Web Components appear in the Lightning App Builder component palette. App Extensions on Lightning Console apps are configured inside the App Manager. The Lightning Web Security allowlist is configured under Session Settings. The unifying idea across all of them is the same: take the standard platform and add carefully scoped capabilities that survive future platform upgrades.

Lightning for Gmail is the 2016-to-2018 Salesforce brand name for the product now called the Gmail Integration. It is a Chrome extension and Google Workspace add-on that embeds a Salesforce panel directly inside Gmail. From that panel, a sales rep can see Salesforce records tied to an email, log messages to those records, and create new records without leaving the inbox. The name has changed several times. Salesforce shipped it first as the Salesforce App for Gmail, renamed it Lightning for Gmail during the Lightning Experience push, then settled on Gmail Integration when the configuration moved under the Setup node named Gmail Integration and Sync. The capability stayed the same across each rename. If you find Lightning for Gmail in an old runbook or AppExchange listing, treat it as a synonym for today's Gmail Integration rather than a separate product.

A Lightning for Outlook is the historical Salesforce name for the Microsoft Outlook add-in that puts Salesforce inside the Outlook client. Salesforce introduced the name in 2016, then folded it into the broader Outlook Integration branding around 2019. The feature itself stayed consistent across the renames: show a Salesforce panel next to an email or meeting, surface the records that relate to the people on that message, log emails and events to those records, and pair with a sync engine for automatic activity capture. The name still appears in older Setup screens, AppExchange listings, and 2017-era documentation, so it is worth knowing. New work should use the current label, Outlook Integration, which you configure under Setup, Outlook Integration and Sync. The add-in runs in Outlook on Windows, on Mac, and in Outlook on the web. It works only with Lightning Experience, and it usually pairs with Einstein Activity Capture for automatic email and event sync.

Lightning Knowledge is the modern incarnation of Salesforce Knowledge built on the Lightning Experience platform. It uses a single sObject, KnowledgeArticleVersion, with record types per article variant (FAQ, How-To, Known Issue), replacing the older Classic Knowledge model that used a separate __kav object per article type. Lightning Knowledge supports the same multilingual, multi-channel, lifecycle-driven publishing workflow as Classic but with a unified data model that simplifies development, integration, and search. Lightning Knowledge is the supported path for new Service Cloud deployments. Classic Knowledge cannot be enabled in new orgs created after 2019 and is in maintenance mode for older orgs. Migration from Classic to Lightning is a one-way conversion: the platform consolidates the legacy __kav objects into KnowledgeArticleVersion with record types, and custom code referencing the legacy objects must be rewritten. Most current Service Cloud customers run Lightning Knowledge, and every new Trailhead module assumes the Lightning model.

The Lightning Out 2.0 App Manager is the Setup interface where an admin or developer creates and configures a Lightning Out 2.0 app, the Salesforce app that lets you embed custom Lightning web components into an external, non-Salesforce website. You build the app in Setup, add the custom LWCs you want to expose, optionally define properties the host page can pass in, and then copy a generated code block straight into the external app's HTML. Lightning Out 2.0 went generally available in the Winter '26 release. It is built on Lightning Web Runtime and completely replaces the older Aura-based Lightning Out (beta), rather than extending it. Each embedded component runs inside an iframe that forms a closed shadow DOM, so the host page cannot reach into Salesforce internals. The framework works with React, Angular, Vue, and plain JavaScript host apps.

Lightning Platform is Salesforce's platform-as-a-service layer, the underlying infrastructure that runs every Salesforce Cloud (Sales, Service, Marketing, Industries) plus any custom application built on top. It includes the multi-tenant database, the declarative metadata layer (objects, fields, validation rules, flows), the programmatic layer (Apex, Lightning Web Components, Visualforce), the sharing and security model, the API surface (REST, SOAP, Streaming, Bulk, GraphQL), and the AppExchange ecosystem for distributing managed packages. The platform was originally called Force.com, then rebranded to Lightning Platform when the Lightning Experience UI launched in 2015. The brand has shifted again in recent years toward "Salesforce Platform" in marketing, but Lightning Platform is still the working name across Setup, developer docs, and pricing pages. Buying a Platform license gives a user access to all the platform features without any of the prepackaged Sales or Service Cloud functionality, which is how ISVs and internal-app teams build custom apps without paying for CRM seats they will not use.

The Lightning Platform App Menu is the set of app permissions that decides which Salesforce apps a user can select and switch between in Lightning Experience. Salesforce builds the App Menu from "assigned app" settings on profiles and permission sets. Those settings specify the apps that users can select in the Lightning Platform app menu, so the menu is really a permission layer, not just a piece of header chrome. Users see the result of the App Menu in two places. The app name dropdown near the navigation bar lets them switch the current app. The App Launcher (the grid icon on the left of the navigation bar) opens a fuller view of every app and item they can reach. Admins shape both surfaces from Setup under App Menu, where they set each app's visibility and drag rows to change the order. The same assigned-app rules feed the App Launcher, so getting App Menu permissions right is what controls a user's whole app-level navigation.

A Lightning Platform builder is any of the point-and-click design tools that Salesforce ships for extending the Lightning Platform without writing Apex. The phrase is an umbrella label rather than a single product. It groups the declarative builders an admin reaches for every day: Lightning App Builder for pages, Object Manager for data, Flow Builder for automation, and Schema Builder for visual data modeling. Each one lives inside Setup and produces metadata that deploys through normal release tools. Salesforce documentation rarely prints the exact words "Lightning Platform builder" as a heading. It instead names each builder directly. You will see "Lightning App Builder" and "Flow Builder" in the Help pages, not a combined app. Treat the phrase as a way to talk about the whole declarative toolset. When you actually need to build something, open the specific builder that matches the job rather than hunting for one master builder.

A Lightning Platform Enterprise App license is a Salesforce user license aimed at people who work mainly in custom apps built on the platform, without needing the standard Sales or Service Cloud features. It gives a user the platform itself (custom objects, custom apps, Flow, Lightning App Builder, reports, and a defined set of standard objects) at a lower price than a full Sales or Service license. In current Salesforce packaging this license sits under the Lightning Platform Plus product and maps to the underlying Salesforce Platform user license. The name "Enterprise App" comes from older Salesforce price lists, where Platform editions were sold as "One App" and "Enterprise App" tiers. Salesforce has since renamed the packaging to Lightning Platform Starter and Lightning Platform Plus, but the older labels still appear in contracts and admin conversations. The license is for internal employees or contractors only, not for external community or portal users.

A Lightning Platform Light App is the lower-cost variant of the Force.com App Subscription user license, meant for internal users who need a single custom app rather than full CRM. The license limits each user to one custom app, defined as up to 10 custom objects and 10 custom tabs, with read-only access to the Accounts and Contacts standard objects. It excludes Sales and Service Cloud objects such as Opportunities, Leads, Cases, Quotes, and Campaigns. The "Light App" name is older Salesforce branding. In current price books the same family appears as Lightning Platform Starter (10 custom objects) and Lightning Platform Plus (110 custom objects), with the paired Enterprise App tier adding read/write Account and Contact access plus Bulk and Streaming API. The license sets the baseline of what a user can touch, so picking the right tier per persona is one of the larger cost levers in a Salesforce contract.

Lightning Scheduler is Salesforce's appointment booking product, used to schedule meetings between customers and internal staff with the right skills, location, and availability. It powers banking branch visits, medical consultations, retail appointments, and any other use case where a customer picks a time and Salesforce assigns the right person from a pool of resources. The product runs inside Salesforce Experience Cloud sites, the standard Lightning UI, or as an embedded widget on a public website. Behind the scenes Lightning Scheduler uses a data model of Service Resources (the people doing the work), Service Territories (where they work), Work Type Groups (what services are offered), Operating Hours (when staff is available), and Service Appointments (the booking records that get created). The appointment-time engine combines all of these to compute available slots in real time, respecting time-off, existing bookings, skill matches, and territory boundaries.

A Lightning Type is a Salesforce metadata feature that pairs a data type with the user interface used to enter and display that data. Each type is built from a JSON schema that describes the shape and validation rules of the data, plus optional configuration that maps the type to a Lightning Web Component for input (an editor) and another for output (a renderer). The custom variety ships as a metadata bundle called LightningTypeBundle, available since API version 64.0. The term is easy to confuse with the broader Lightning family of components and pages, but it means something specific. A Lightning Type answers one question: when a piece of data flows through Salesforce, what component should collect it and what component should show it? Salesforce uses these types to give richer interfaces to Agentforce agent actions, Experience Builder component properties, and flow Structured Outputs, instead of falling back to plain text fields.

Lightning Usage is a Salesforce Setup page that surfaces detailed analytics about how users interact with Lightning Experience, providing metrics on daily and monthly active users, page load performance, most-visited pages, browser distribution, and Salesforce Mobile usage. The page is part of the broader Adoption Assistant suite and is the canonical data source for understanding how users actually consume the platform versus how admins assume they do. The data on Lightning Usage matters because admin-built customizations only deliver value when users actually engage with them. A meticulously crafted dashboard that nobody opens is wasted effort; a flow that no rep uses provides no business outcome. Lightning Usage exposes the engagement reality so admins can iterate based on actual user behavior rather than assumptions. The page also surfaces performance metrics that drive technical optimization: slow-loading record pages, browsers with degraded performance, mobile usage patterns. Combined, the engagement and performance data shapes a productive admin practice focused on what actually moves the needle for users.

The Lightning Web Component (LWC) Framework is the modern UI framework Salesforce ships for building custom components on the Lightning Platform. LWC is built directly on top of web standards: Web Components, ES Modules, Shadow DOM, custom elements, and standard HTML templates. Components are written in JavaScript with a small set of decorators (api, track, wire) and a thin runtime layer that handles reactivity, security, and access to Salesforce data. LWC replaces the older Aura Component framework as the primary path for new custom UI on Salesforce. Aura still exists, still runs, and still ships in some standard pages, but every Salesforce-built UI is moving to LWC and every new tutorial in the developer docs uses LWC. The framework runs in the browser inside a Locker Service or Lightning Web Security sandbox that prevents one component from reading another component's DOM or globals. That isolation is what lets Salesforce drop third-party components from AppExchange into a customer's org without exposing the rest of the page.

A Like is the Chatter engagement action that lets a user signal approval or interest in a feed post or comment with a single click. Clicking the Like button records the user's like, raises the displayed like count, and adds that person to the list of people who liked the item. Each like is stored as a row on the FeedLike standard object, with one like per user per item. In the user interface, Like sits next to Comment and Share as the lightest way to react in the feed. When you like a post, its author is notified, and you start receiving notifications about later comments on that post. Clicking Unlike removes your like and stops those follow-on notifications. Likes you receive also feed into your Chatter activity and influence statistics.

A List Custom Setting is a type of Salesforce custom setting that stores reusable key-value data in the application cache, where every record is the same for every user. Each row is identified by a Name field, and Apex reads it through the generated getValues(name) and getAll() methods. Because the data lives in the cache, those reads do not count against SOQL query governor limits. A List Custom Setting differs from a Hierarchy Custom Setting in one key way: it has no per-user or per-profile precedence. The value is identical for the whole org. That makes it a good fit for configuration that applies to everyone, such as country codes, tax rates, integration endpoints, or a feature kill switch. It is a cached lookup table, not a full custom object, so it carries field-type restrictions and a size cap.

The List Price in Salesforce is the published price of a product as recorded on a Price Book Entry. Every product can sit in more than one price book, and each Price Book Entry stores the list price for that product in that specific book. When a user adds the product to an Opportunity, Quote, or Order, Salesforce defaults the line's price to this list price, which the user can then override with negotiated pricing. The list price is the starting point for almost every pricing flow on the platform, from basic Sales Cloud opportunity lines to Salesforce CPQ quote lines. It lives on the PricebookEntry object, identified by the pairing of a Pricebook2 (the price book) and a Product2 (the product). In Salesforce CPQ the list price is the quote line's initial price, and CPQ pulls it from the product's list price entry in your price book before any discount logic runs.

A list view in Salesforce is a saved set of filter criteria, columns, and sort order that returns a scrollable list of records from one object, shown as a table in the Lightning UI. You open list views from an object's home page, such as the Accounts, Opportunities, or a custom object tab, and use them to find, sort, and act on records that match the saved criteria. Each list view stores which records appear (the filters), which fields show as columns, the default sort order, and who can see the view (its sharing settings). Standard list views like Recently Viewed ship with every object, and admins or users add custom views on top. List views are how most people find and work with records day to day, so a well-built set of them shapes the whole team's workflow.

A Local Name is a Salesforce field that stores a person's or account's name in the native script of a local language, kept alongside the standard name field that usually holds an English or romanized version. The standard objects Account, Contact, Lead, and User support local name fields, with labels such as First Name (Local), Last Name (Local), and Account Name (Local). The standard field holds one representation, and the local field holds the other, so a single record carries both forms of the same name. Local Name fields matter most in markets where people and companies are known by a name written in their own script. A contact recorded as Taro Yamada in the standard fields can carry the kanji form in the local fields. Salesforce stores the value in the account's or user's language, and these fields do not change anyone's user language settings. Without local name fields, an org has to choose one script and drop the other, which weakens search and the customer experience in those regions.

A Local Project in Salesforce DX is the folder on a developer's machine that holds an org's metadata in source format. It is the workspace created with the Salesforce CLI command sf project generate, opened in an editor like VS Code, and tracked in git. At its root sits the sfdx-project.json configuration file, which tells the CLI that the directory is a Salesforce DX project. Below it are package directories (force-app by default) that group every metadata type the developer touches: Apex classes, Lightning Web Components, objects, flows, permission sets, and more. The Local Project is where modern Salesforce development happens. Source moves between the project and an org through the CLI: you deploy with sf project deploy and retrieve with sf project retrieve. Because the source format splits metadata into many small files, the project produces clean diffs that version control systems handle well. That makes branches, pull requests, and code review practical in a way the older Metadata API format never allowed.

A locale is the per-user Salesforce setting that controls how the platform formats and reads dates, times, numbers, currencies, names, addresses, and phone numbers for that user. The Locale field lives on the User record alongside Language and Time Zone, and each of the three is set independently. A user can read the interface in English while using a French locale, so dates render as 14 Oct 2020 instead of Oct 14, 2020 and decimals use a comma. Locale works in two directions. It decides how stored data is displayed to the user, and it decides how typed input is parsed on edit screens before the value is saved. The platform ships a fixed list of locales tied to language and country, such as en_US, en_GB, fr_FR, de_DE, and ja_JP. Administrators choose from that list per user and set an org default; they do not invent custom locales.

A logged-in user in Salesforce is the User record that owns the current session. Every session, whether it runs through the Lightning UI, the REST or SOAP API, a connected app, a flow, or an Apex callout, executes in the context of exactly one user. That user's profile, permission sets, sharing access, role, and locale settings shape what the session can see and do, and the audit trail records the user as the actor behind each change. The concept sits under almost everything because Salesforce security is user-centric. Record access comes from the logged-in user's sharing. Field-level security comes from the profile and assigned permission sets. Report and folder visibility come from the role hierarchy. Formula functions, Apex methods, and Lightning component imports all expose the logged-in user as a basic piece of session state, so identifying and respecting that user is foundational for any build that needs to be secure, auditable, or personalized.

Login Access Policies is the Setup page in Salesforce where an administrator controls who can log in as another user and which packaged publishers users are allowed to grant login access to. It governs the privacy default for impersonation: whether an admin must wait for a user to grant access before using Login As, or whether admins can log in as any user without that consent. The page lives under Setup in the Quick Find box as "Login Access Policies." The page exposes one global toggle, "Administrators Can Log in as Any User," plus a row for every managed package publisher that supports login access. For each publisher you decide whether both users and admins can grant access, or only admins can. The feature is consent-based by default. Even a System Administrator with Modify All Data cannot impersonate someone until that person grants access from their own Personal Settings, and every login-as session is recorded in the Setup Audit Trail.

A Login Flow is a Salesforce feature that runs a screen flow or Visualforce page during the login process, after Salesforce authenticates the user but before the user reaches the org or Experience Cloud site. The flow runs in the user's context and can collect or update data, request that the user accept terms, enforce stronger authentication, or apply a custom access policy. Each Login Flow record ties a flow to a User License and a Profile, so every login for that profile runs the flow. Login Flows work with standard username and password login, delegated authentication, SAML single sign-on, and SSO through a third-party authentication provider. They do not run for API logins or sessions passed through frontdoor.jsp, and they cannot redirect the user to a URL outside the org. The feature is still current and supported, though some scenarios it once handled, such as MFA enrollment, are now covered by built-in identity features.

Login History is the Salesforce log of user authentication events. Every time a user logs in, logs out, or has a session timeout, the platform records the event with the user identifier, timestamp, source IP address, login type, browser user agent, login status, and any associated Auth Provider, Connected App, or Identity Provider. The log is exposed in Setup, accessible to admins with the Manage Users permission, and downloadable as CSV for offline analysis. The Login History is the primary forensic tool for "who logged in from where and when" questions. It complements the Setup Audit Trail (which records configuration changes) and Event Monitoring (which records fine-grained event activity). Where the audit trail tells you what was changed, the login history tells you who connected to the platform in the first place. For any security investigation, the standard order is: confirm the user logged in (Login History), confirm the user made the change (Setup Audit Trail), and confirm what data the user touched (Event Monitoring or Field History).

A Long Text Area is a Salesforce custom field type that stores multi-line plain text up to 131,072 characters (128 KB). It is the larger relative of the Text field, which caps out at 255 characters. Admins reach for a Long Text Area when a field has to hold extended content like product descriptions, case resolution notes, meeting summaries, or any prose that runs past the short Text limit. The field shows up as a multi-line box in record pages, stores the value as entered, and keeps no HTML or formatting. When you create the field you set its character limit. The default is 32,768 characters, the minimum you can pick is 256, and the ceiling is 131,072. Long Text Area behaves differently from a short Text field in ways that matter. It is not indexed for search the same way, it does not appear in standard list view filters, and it has narrow support in report filters and SOQL WHERE clauses. The Rich Text Area field is the formatted cousin, built on the same storage but adding an HTML editor for bold, lists, images, and links.

A Lookup Dialog is the Salesforce search interface that opens when a user fills a lookup field, letting them find and pick a related record. It appears when you click into or beside a lookup field on a record page, presenting a search box, a list of suggested records, and matching results scoped to the field's target object. In Lightning Experience the dialog renders as a typeahead dropdown beneath the field. As the user types, results adjust to records whose Name matches what they entered, drawn from recent items, frequently used objects, and the current object. In Salesforce Classic the same idea appears as a modal popup. The dialog respects record-level sharing, so users see only records they can access, and it respects lookup filters that an admin sets to narrow the field's scope.

A Lookup Field in Salesforce is a relationship field type that links two objects by storing the parent record's ID on the child record. It creates a loose connection, so the child can exist whether or not the lookup is filled in, the child keeps its own ownership and sharing, and deleting the parent does not delete the child by default. Lookups are the most common way to relate records on the platform, and they back nearly every standard parent-child link, including Opportunity to Account, Contact to Account, and Case to Contact. In the user interface a Lookup Field shows a search picker (the magnifying-glass icon), then renders as a clickable link to the parent record. The relationship is queryable in SOQL with dot notation, such as SELECT Account.Name FROM Opportunity. Admins create lookup fields under Setup, Object Manager, by adding a field of type Lookup Relationship. It is the default choice for cross-object links. You pick Master-Detail instead only when the child has no meaning without its parent and you want cascade delete and inherited sharing.

A Lookup Filter is an admin-defined rule on a Salesforce relationship field that restricts which records a user can pick. It applies to lookup, master-detail, and hierarchical relationship fields. The filter limits both the valid values and the results shown in the lookup dialog. Each candidate record is checked against the criteria, and only matching records become selectable. Criteria can reference fields on the source record, fields on the target (lookup) object, fields on the running user, and fields one relationship away from the target.

A Lookup Icon in Salesforce is the small object icon that Lightning Experience renders next to a record so users can tell at a glance which object the record belongs to. The same icon appears in lookup dialog results, global search results, related list headers, the navigation bar, the highlights panel, and list views. It comes from the Salesforce Lightning Design System (SLDS) icon set, which groups icons into action, standard, custom, doctype, and utility categories. The icon is not a separate setting you toggle on its own. It is defined by the object's Tab Style, the color-and-icon pairing chosen for the object's tab. Because every Lightning surface reads that single Tab Style, picking one icon controls how the object looks everywhere, on desktop and in the Salesforce mobile app. Standard objects ship with a default icon, and custom objects choose one when their tab is created.

A Lookup Relationship in Salesforce is the many-to-one relationship that lets one record reference another without taking ownership of it. A Contact has a Lookup Relationship to Account; an Opportunity has a Lookup Relationship to Account; an Activity has a Lookup Relationship through WhoId and WhatId. Each lookup field stores the Id of the target record, and the parent record can have any number of children pointing to it through the lookup. Lookup Relationships are the most common relationship type in any Salesforce data model: most standard relationships are lookups, and most Custom Objects need lookups to standard objects to function. Lookup Relationships are the relational-database analog of a foreign key with no cascade delete by default. The child record carries the parent's Id; deleting the parent leaves the child's lookup field blank (the default cascade behavior is to clear the field, not to delete the child). This makes Lookup Relationships safe for optional or many-to-one connections where the child can survive without the parent. The trade-off is that lookups do not propagate sharing or ownership the way Master-Detail Relationships do; if the child needs to inherit the parent's sharing, lookups are the wrong tool.

Low-code is a software development approach that builds applications mostly through visual, declarative tools instead of hand-written code. On the Salesforce Platform, low-code means configuring business logic and user interfaces with clicks rather than Apex. The metadata-driven architecture is what makes this possible. Things like record lists, detail views, dialogs, and forms come for free, so an admin can assemble working features without programming. Flow Builder, Lightning App Builder, and Schema Builder are the headline low-code tools, and Salesforce documents them as point-and-click or declarative development. Low-code sits between two neighbors on a spectrum. No-code is entirely visual configuration for simple tasks, like building a report or a list view. Pro-code is entirely hand-written using Apex and Lightning Web Components. Low-code is mostly visual with selective code extension when the declarative tools cannot express the logic. Salesforce frames modern app development as low-code tools leading, with native ways for developers to reach pro-code when they need it. Real orgs mix all three levels deliberately.

A Loyalty Member is a customer or business enrolled in a Salesforce Loyalty Management program, stored as a record on the standard LoyaltyProgramMember object. Each member links to one Loyalty Program and to a customer identity (a Contact, Person Account, or Account). The record carries the member type, membership number, enrollment date, and membership status. It is the anchor that every other loyalty record points back to. A common misconception is that the point balance and tier live directly on the member record. They do not. A member's currency balances sit on related LoyaltyMemberCurrency records, and the current tier sits on LoyaltyMemberTier records, one per tier group. The LoyaltyProgramMember object arrived in API version 51.0 (Spring '21) as part of the Loyalty Management product, which is licensed separately and aimed at retail, travel, hospitality, and financial services rewards programs.

A Loyalty Program in Salesforce Loyalty Management is the parent record that defines a rewards program. It holds the program name, the description, the status, and the program type, and it links every member, tier, currency, voucher, promotion, and transaction into one program identity. The record lives on the LoyaltyProgram standard object, available in API version 51.0 and later. One org can run several Loyalty Programs at once, such as a consumer program for individuals and a partner program for companies, each with its own rules and member roster. Loyalty Management is the industries product that hosts these programs. It targets retailers, airlines, hotels, financial services, and any B2B or B2C business that runs a structured rewards scheme. The Loyalty Program record sets the framework. Supporting objects do the operational work: tier groups and tiers define status levels, program currencies hold the points members earn and spend, and transaction journals record activity. The program connects to Marketing Cloud for tier-based campaigns, Service Cloud for member care, and Data Cloud for a unified customer profile.

LWC is the shorthand name for Lightning Web Component, the modern Web Components-based UI framework Salesforce uses for custom Lightning Platform development. The acronym appears throughout developer documentation, Trailhead modules, GitHub repositories, and conversation as the everyday name for the framework. When Salesforce developers say "I built it in LWC" or "the LWC framework supports X", they mean the Lightning Web Component framework released in 2019 as the replacement for Aura. LWC is built on web standards: Web Components, ES Modules, Shadow DOM, custom elements, and standard HTML templates. The framework adds Salesforce-specific decorators (api, wire, track), a security sandbox (Locker Service or Lightning Web Security), and data services (Lightning Data Service for record CRUD, Wire Service for reactive Apex calls). The result is a developer experience closer to React or Vue than to the older Aura framework, with components that can run anywhere Salesforce surfaces Lightning UI: record pages, Experience Cloud sites, Flow screens, the Salesforce Mobile App, and embedded surfaces.