Salesforce terms starting with L

Language Settings is the Salesforce Setup configuration that controls which languages are enabled for an org and how users interact with multi-language content. The page exposes two distinct concepts that are often confused: end-user display language (the language the Salesforce UI shows for each user) and content language (the language of records, picklist values, and translated content stored in the org). Both work together to provide a multi-language experience, but they configure separately and have different downstream effects. End-user display language is set per user on the User record (Language field). The available choices come from the Languages list configured in Setup. Salesforce supports over 30 fully translated languages and additional partially translated languages. Content language uses the Translation Workbench to translate picklist values, field labels, custom labels, page layouts, and email templates. Enabling a language for translation makes it available as a content-translation target without changing what individual users see by default.

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 defines how fields, related lists, and actions appear on a record page. The platform supports two distinct layout systems that coexist: Page Layouts (the classic system, still primary for many features) and Lightning Pages (the modern App Builder-driven system for Lightning Experience). Page Layouts control field order, field requirement, and section grouping on record edit and detail views; Lightning Pages control which components render on the record page and where. Most modern orgs use Lightning Pages for the overall page structure and Page Layouts for the field-level form layout within them. Layouts are assigned per profile and per record type, producing a multidimensional grid where each user sees a specific layout based on their profile and the record's type. This per-assignment model is the source of much administrative complexity in larger orgs: 10 profiles times 5 record types per object produces 50 layout assignments to maintain. Tools like Field Accessibility surface the effective layout per combination, but the underlying assignment matrix is admin-managed and grows linearly with profile and record type counts.

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 defines the maximum number of characters or digits a field can store. It appears on every Text, Long Text Area, Rich Text Area, Number, Currency, Percent, Phone, Email, URL, and similar field types. The Length setting is the foundational sizing decision that admins make when creating a custom field; it directly affects validation, integration, search indexing, and storage. Once a field is created, Length can be increased without data loss but rarely decreased without risk of truncation. Beyond the field-level meaning, Length also surfaces as a function in formulas (LEN() returns the character count of a string) and as an attribute of the standard fields. The standard Account.Name field has a length of 255, Opportunity.Name 120, Contact.LastName 80; integrations and Apex code must respect these limits or face DML exceptions. The Length attribute also drives field-type display: Text fields above 255 characters become Long Text Areas, which behave differently for search, formulas, and report filtering. Understanding the Length implications of each field type is the foundation of good Salesforce data modeling.

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 visualization of a dataset; the Lens Explorer is the no-code interface that lets analysts build the lens by dragging fields onto chart shelves, filtering data, drilling into subsets, and pivoting groupings. Lenses can be saved, embedded in dashboards, exported, or kept as throwaway exploration sessions. The Lens Explorer is the workhorse tool for self-service analytics in CRM Analytics. Power users open a dataset, build a lens to answer one question (revenue by region, conversion rate by source, churn by tenure), save it for repeat use, and move on. Lenses are the building blocks of dashboards; an analyst designs a dashboard by composing multiple saved lenses on a single canvas. Salesforce''s strategic direction has moved the broader analytics conversation toward Tableau and Tableau Pulse, but the Lens Explorer remains the native exploration tool inside CRM Analytics for orgs invested in the platform.

A Letterhead in Salesforce is a reusable branding template for HTML emails sent from the platform. It defines the header image (logo), the colors, fonts, and a footer (legal disclaimer, unsubscribe link) that every email template using the letterhead inherits. Admins build letterheads once under Setup, Classic Letterheads, and reference them from any HTML Email Template. The letterhead ensures the company''s emails carry consistent visual identity without each template designer having to copy-paste the same branding. The feature is a legacy Salesforce Classic capability. Lightning Experience replaces the letterhead concept with Enhanced Email and Lightning Email Templates, where branding is built into each template or controlled at the org level via Email Brand Settings. Orgs migrating from Classic to Lightning often retire letterheads as part of the email-template refresh. Existing letterheads still work, but new email-template work in Lightning typically does not use them.

A Library in Salesforce is a permission-scoped container for files in Salesforce CRM Content and Salesforce Files (the modern unified file system). Each Library has its own membership list, sharing rules, content types, and tags. Users add files to a library; library members access the files via their library permission. Libraries support both internal-only files (shared with Salesforce Users) and external-facing files (shared with Experience Cloud Customer Community users). The Library concept evolved over Salesforce releases. The original Salesforce CRM Content product introduced libraries as the permission boundary for files. Salesforce Files (launched with Chatter) modernized the UI and merged libraries into the broader Files surface. Lightning Experience presents files via the Files Home tab with a Libraries section. Each library is governed by its own permission set: library members get Viewer, Author, or Library Administrator access. The library model is the right tool for organizing files by team, project, or function while controlling who can edit and who can only read.

A Library Permission in Salesforce defines what a user can do with files in a specific Content Library. Each Library is the container for a curated set of Files, and Library Permissions grant member access at one of three levels: Viewer (read-only), Author (read and contribute new files), or Library Administrator (full control including managing members and tagging). The permission model is library-specific: a user can be Viewer in one library and Author in another, with no global "Files admin" role beyond the standard Modify All Data permission. Library Permissions complement standard Files sharing. Files exist as ContentDocument records and can be shared individually to records and users. Libraries provide a curated organizational layer on top: marketing assets in a Marketing Library, sales collateral in a Sales Library, internal HR documents in an HR Library. Each library carries its own member list with permissions. The combination of record-level Files sharing and library-level permissions provides the full access model for Salesforce Files.

The License Management Application (LMA) is the Salesforce-supplied managed package that AppExchange partners install in their License Management Organization to track every customer install of their managed packages. The LMA exposes standard objects (License, Package, Package Version, Subscriber) that record each customer''s subscription details, license count, expiration date, and contact information. When a customer installs the partner''s managed package from the AppExchange, Salesforce automatically creates a License record in the partner''s LMA-enabled org and populates it with the install details. The LMA is the foundation of the AppExchange partner business model. It lets ISVs (Independent Software Vendors) provision licenses, expire licenses on contract end, identify the subscriber org for support engagement, monitor adoption, and run partner-side reporting on the install base. Without the LMA, a partner would have no programmatic visibility into their AppExchange customers. The application is free to install for any Salesforce Partner Community member with a managed-package offering; the related License Management Organization (LMO) is the org where the LMA lives.

The License Management Organization (LMO) is the Salesforce org that an AppExchange partner designates as the home for their License Management Application (LMA). Every managed package an AppExchange partner offers gets linked to exactly one LMO; when customers install the package, Salesforce creates License records in that LMO. The partner uses the LMO to track every customer install, manage subscriber data, run partner-side reporting, and integrate with their billing system. The LMO is the partner-side mirror of the customer''s Salesforce subscription business. Designation of the LMO is a one-time decision made when the partner registers their first managed package with the Salesforce Partner Program. Most partners use their primary internal Salesforce org as the LMO; some create a dedicated org separated from internal sales-and-service operations. The decision is permanent in practice: re-pointing managed packages to a different LMO requires Salesforce Partner Support intervention and risks losing License history. Picking the LMO wisely at registration is one of the highest-stakes early decisions for any new AppExchange partner.

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.

Lightning Bolt Solutions were Salesforce''s pre-built, industry-specific community templates that packaged a complete Experience Cloud site along with Lightning components, custom objects, automation flows, and example data. Salesforce launched Lightning Bolt in 2016 to let customers stand up vertical-specific community experiences (retail banking community, healthcare provider portal, B2B partner portal) without building everything from scratch. Partners and Salesforce itself shipped bolts targeting specific industries. Salesforce has been quiet on the Lightning Bolt brand since around 2020-2021, and the term rarely appears in current product marketing. The underlying capability (packaging Experience Cloud sites, components, and metadata together) lives on in the Experience Cloud Templates system and the broader Salesforce Industries Cloud product lines. Customers still occasionally encounter Lightning Bolt references in inherited orgs, in older AppExchange listings, and in legacy training material. The concept remains valid: pre-built industry solutions exist, just under different names today (Salesforce Industries Templates, Experience Cloud Templates, vertical Industry Clouds).

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 that defines the visual language, component patterns, and CSS framework used across Lightning Experience, the Salesforce mobile app, Experience Cloud sites, and custom Lightning Web Components. SLDS provides the design tokens (colors, spacing, typography), a CSS framework (utilities, layout grids, component classes), and a reference site (lightningdesignsystem.com) documenting every available pattern with code examples. SLDS is the layer that makes a custom Lightning Web Component look like it belongs in Salesforce. Developers reference SLDS classes in their LWC markup (slds-button, slds-card, slds-grid) and the component picks up the Salesforce visual identity automatically: same colors, same spacing, same hover states, same accessibility behavior. The system is also publicly maintained on GitHub, so non-Salesforce developers can use SLDS in standalone web applications. Salesforce updates SLDS with each platform release, and the recent SLDS 2 refresh modernized the underlying CSS to align with current web standards.

Lightning Email Templates are the modern Salesforce email template system that replaces the legacy Classic Email Templates with a Lightning-native authoring experience, richer formatting capabilities, and improved sharing model. Users build templates in a WYSIWYG editor with drag-and-drop layout components, merge field insertion through a guided picker, and HTML output that renders consistently across modern email clients. Templates are stored as EmailTemplate records with a Type of "custom" and surface through the Lightning email composer, List Email tool, and Send Email actions in Flow. The Lightning system coexists with Classic email templates rather than replacing them. Classic templates remain functional for organizations with legacy investments, but new template work should go in Lightning. The two systems use different underlying storage and editing tools, but both produce EmailTemplate records that the platform sends through the standard email infrastructure. Most modern orgs have a mix: legacy Classic templates for established workflows, Lightning templates for new template development.

Lightning Experience Insights is the suite of analytics features inside Lightning Experience that surfaces user-adoption, performance, and feature-usage data to administrators and executives. The most prominent surface is the Lightning Usage App (formerly Lightning Adoption Dashboard), an Analytics-Cloud-powered app that shows how many users are active in Lightning, what features they use, what pages they visit, and how page-load times compare across releases. Insights also includes the Optimizer report, the Lightning Adoption assistant, and various per-feature analytics dashboards baked into specific products. The feature exists because Lightning Experience adoption was Salesforce''s single biggest UX transition for the platform. Customers migrating from Classic needed visibility into who was actually using Lightning, which pages worked, and where users got stuck. Lightning Experience Insights answered those questions with packaged dashboards rather than asking each customer to build them from scratch. Today, with the vast majority of orgs on Lightning, the analytics matter less for migration tracking and more for ongoing UX optimization: monitoring page-load times, identifying slow custom Lightning Pages, and surfacing low-adoption features that need attention.

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 was the original Salesforce-branded name for the Chrome extension and Google Workspace add-on that embeds Salesforce inside Gmail. Salesforce rebranded the product several times: Salesforce App for Gmail (early), Lightning for Gmail (2016-2018), Salesforce Inbox / Gmail Integration (2019 onward). The functionality stayed essentially the same: render a Salesforce sidebar inside Gmail, log emails to Salesforce records, surface contextual information about the email''s sender, and (with Einstein Activity Capture) sync emails automatically. The Lightning for Gmail name persists in older Setup nodes, AppExchange listings, and customer training material. Modern Salesforce documentation uses Gmail Integration as the canonical name; the modern node lives under Setup, Gmail Integration and Sync. Customers running long-lived orgs may still see Lightning for Gmail in inherited internal documentation, but no new deployments should reference the older name. The underlying capability is identical to the current Gmail Integration product, just with the historical brand attached.

Lightning for Outlook was the historical Salesforce-branded name for the Microsoft Outlook add-in that embeds Salesforce inside the Outlook client. Like its Gmail counterpart, the product has been renamed several times: Salesforce App for Outlook (early), Lightning for Outlook (2016-2018), Salesforce Outlook Integration / Outlook Integration and Sync (2019 onward). The functionality stayed essentially the same throughout: render a Salesforce panel inside Outlook, surface Salesforce records related to the email or meeting, log emails to specific records, and sync calendar events. The modern product is configured under Setup, Outlook Integration and Sync. It works in Outlook on Windows, Mac, and the web Outlook 365 client. The add-in pairs with Einstein Activity Capture for automatic email-and-event sync (the modern default) or with Lightning Sync (deprecated but still available). Lightning for Outlook references persist in older Setup pages, AppExchange listings, and 2017-era documentation, but no new deployments should reference the legacy name.

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.

Lightning Out 2.0 App Manager is the Setup interface where admins configure Lightning Out applications, the framework that lets Lightning Components run inside non-Salesforce hosts: external websites, Visualforce pages, custom mobile apps, and Heroku apps. Lightning Out delivers a self-contained bundle that includes the requested Lightning Components, the underlying dependencies, and the JavaScript needed to render them, all served from the Salesforce-supplied lightning.force.com endpoint. The 2.0 version represents the modernized framework that supports Lightning Web Components alongside the original Aura Components. The App Manager in Setup, under App Manager, lets admins create the Lightning Application records that define which components are exposed via Lightning Out. Each Lightning Application bundles a set of components into a deployable unit; external pages reference the application URL to embed the Salesforce experience. Common use cases include embedding a Salesforce-driven order-status component into a public website, surfacing a Salesforce dashboard inside a Visualforce email digest, or running Salesforce-aware Lightning Components inside a Heroku-hosted application.

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 dropdown menu in the upper-right corner of Salesforce Lightning Experience that lets users switch between apps. Each entry in the menu corresponds to a Salesforce App (a packaged collection of tabs, brand, and Lightning pages) the user has access to. Common apps include Sales, Service, Marketing, and any custom apps the admin has built. The menu is the user''s primary way to navigate the Salesforce experience at the app level, distinct from the per-app navigation tabs. Admins control the App Menu under Setup, App Menu (now part of App Manager in modern releases). The page lists every App in the org and lets admins set the visibility, the order, and which apps appear in the App Launcher (the grid that opens when users click the waffle icon). The App Menu is the top-level navigation; the App Launcher is the discovery surface. Both rely on App permissions to determine what each user sees.

Lightning Platform Builder is a generic term that appears in older Salesforce documentation referring to the suite of declarative platform-building tools: Lightning App Builder, Object Manager, Flow Builder, Process Builder, Schema Builder, and Lightning Page Builder. The phrase Lightning Platform Builder is not a single product but a label for the collection of low-code or no-code tools an admin uses to extend Salesforce without writing Apex. Modern Salesforce documentation does not use the umbrella term as often; instead each specific builder (Lightning App Builder, Flow Builder, etc.) is referenced by its proper name. The term''s relevance has shifted as Salesforce''s platform tools matured. Around 2015-2018, marketing material grouped the builders under the Lightning Platform Builder banner to emphasize the unified declarative experience. Newer documentation prefers product-specific naming. Customers still occasionally encounter the term in older Trailhead modules, partner-training material, and AppExchange marketing copy. The underlying capabilities are exactly the tools listed above; pick the specific builder that matches the use case rather than searching for a single Lightning Platform Builder app.

Lightning Platform Enterprise App is the Salesforce user license type aimed at full-feature custom apps built on the Lightning Platform, without including the standard Sales or Service Cloud functionality. Users with this license get unlimited custom objects (up to org-edition limits), full access to declarative tools (Flow Builder, Lightning App Builder), full Apex and Lightning Web Component development capabilities, and access to most standard objects that are not specifically Sales or Service Cloud branded (Account, Contact, Activity, Files, Chatter). The license is the right choice when an org needs Salesforce platform capabilities for custom-app users who do not need Opportunity, Case, or other Sales/Service-specific features. The Lightning Platform Enterprise App license sits in the Lightning Platform license family alongside the lighter Lightning Platform Light App license. Both are priced at a fraction of a full Sales or Service license, making them cost-effective for users whose primary work is in custom apps rather than standard Salesforce CRM. Most large enterprises mix license types: full Sales licenses for the sales team, Enterprise App licenses for internal-app users (HR portal, asset management, project tracking), and Light App licenses for limited-access users.

Lightning Platform Light App is a Salesforce user license type at the lower-cost tier of the Lightning Platform license family, intended for users who need limited Salesforce access. Light App users get access to a smaller subset of custom objects (typically up to 10), a smaller subset of standard objects (Account, Contact, Activities, Files, Chatter), and limited or no access to Sales and Service Cloud-specific objects. The license trades full platform power for substantially lower per-user pricing, making it a fit for users who only occasionally interact with Salesforce in narrow ways. Common use cases include lookup-only users (employees who need to find customer records but never edit them), light-touch internal-app users (HR self-service portal where employees check their own information), and partner-tier users (external partners with a tiny scope of access). Light App licenses sit alongside the broader Lightning Platform Enterprise App license and the full Sales or Service Cloud licenses; picking the right tier per user persona is one of the biggest cost-optimization levers in any 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.

Lightning Types refer to the family of component and metadata types that Salesforce supports across the Lightning ecosystem: Lightning Web Components (LWC), Aura Components, Lightning Apps, Lightning Pages (Home, App, Record), Lightning Record Pages, Lightning Email Templates, Lightning Bolt Solutions (legacy), and Lightning App Builder layouts. Each type has its own metadata representation, its own design surface in Setup or developer tools, and its own deployment model. Understanding which Lightning Type fits a given build is foundational for any modern Salesforce development. The umbrella term Lightning Types groups these into a single mental model: everything that ships under the Lightning brand and runs on the Lightning runtime. The breakdown matters for licensing (some types are platform features, others are licensed separately), for development (each type has different tooling and APIs), and for deployment (each type ships as a distinct metadata XML file). Salesforce documentation sometimes uses the term in marketing contexts; technically each type is a separate first-class metadata concept with its own documentation.

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.

Like is the Chatter engagement action that lets a user signal approval, interest, or appreciation for a post, comment, or file. Clicking the Like button increments the post''s LikeCount, adds the user to the list of users who liked it, and produces an entry in the FeedLike standard object. The action is the lightweight feedback mechanism that drives Chatter engagement: posts with many likes rise in the Chatter algorithm and contribute to the post author''s Influence score. Like is the simplest Chatter engagement primitive, sitting alongside Comment and Share. Each FeedLike record is permanent (no like history, just current state), one per user per item, and is removable via an Unlike action that deletes the FeedLike row. The action works on Chatter posts (FeedItem), comments (FeedComment), and content shared in the feed. Like contributes to the Chatter Influence score the user accumulates; the author of a heavily-liked post gets ranking credit.

List Custom Settings are a type of Salesforce Custom Setting that store key-value pairs accessible from Apex without consuming SOQL query limits. Each record is identified by a Name field; code retrieves records by name through the generated getValues(name) or getAll() methods. List Custom Settings differ from Hierarchy Custom Settings by the absence of per-user or per-profile precedence: every record is the same to every user, identified by name only. They are the right tool for configuration data that does not vary per user but does need to be cached for performance. Common uses include environment-specific configuration (API endpoints that change between sandbox and production), application reference data (currency rates, country codes), and feature toggles that apply to everyone (a kill switch for a feature being beta tested). List Custom Settings cap at 10 MB total across all settings in the org and have field-type restrictions, so they are not a replacement for full custom objects. They occupy a specific niche: cached configuration small enough to fit the cap.

The List Price in Salesforce is the published, standard price of a product as defined on a Price Book Entry record. Every Product can have multiple Price Book Entries (one per Price Book), and each entry stores the List Price for that product in that price book. When a user adds a product to an Opportunity, Quote, or Order, Salesforce defaults the line''s Unit Price to the List Price; the user can then override it with negotiated pricing while preserving the List Price as the reference baseline. List Price is the foundation of every Salesforce pricing implementation, from the standard Sales Cloud opportunity-line pricing to the more sophisticated Salesforce CPQ quote-line pricing. The price lives on the PricebookEntry standard object, identified by the combination of Pricebook2 (the price book) and Product2 (the product). Each entry can be active or inactive, multi-currency in multi-currency orgs, and can carry custom fields for additional pricing metadata. The reporting on List Price vs. negotiated Unit Price drives discount-analysis, margin-protection, and pricing-governance programs.

A List View in Salesforce is a saved filter and column configuration that returns a paginated set of records from a single object, presented as a table in the Lightning UI. Users open list views from the object''s tab (Accounts list view, Opportunities list view, custom-object list view) and use them to scan, sort, filter, and bulk-edit records that match the saved criteria. Each list view stores its filter criteria (which records appear), column selection (which fields show), sort order, and sharing settings (who can use the view). List views are the primary way users navigate large data sets in Salesforce. The Lightning Experience UI surfaces list views prominently with inline editing (click a cell to edit), Kanban toggle (show records as cards by status), and chart overlay (visualize the list as a bar or pie chart). Admins create org-wide list views shared with all users or specific roles; individual users create personal list views for their own workflow. Modern list views include filter logic, custom-field-based criteria, and integration with Reports for deeper analysis.

Local Name in Salesforce is the localized version of a person''s or account''s name in a non-English alphabet, stored alongside the English-equivalent name field. The standard objects Account, Contact, Lead, and User all have Local Name field variants (Local Name, First Local Name, Last Local Name) that admins enable when the org operates in markets where customers and employees go by names that have both an English-transliterated form and a native-script form (Chinese, Japanese, Korean, Russian, Arabic). The fields store the native-script value while the main Name field holds the English transliteration. Local Name fields are essential in Asian markets and any other market where bilingual record-keeping is the norm. A Japanese customer named TARO YAMADA in English has a local name written in kanji. The customer-facing experience uses the local name; the internal Salesforce search and reporting can use either. Without Local Name fields, the org has to pick one alphabet (typically English) and lose the local representation, which hurts customer experience and search accuracy in those markets.

A Local Project in Salesforce DX is the developer''s local folder structure that holds source-format metadata for a Salesforce org. It is the workspace a developer creates with sf project generate, opens in VS Code, edits source files in, and deploys to a Salesforce org via the Salesforce CLI. The local project contains the sfdx-project.json manifest at the root, plus folders for every metadata type the developer is working with (force-app/main/default/classes, lwc, aura, objects, etc.). The Local Project is the foundation of modern Salesforce development. Every operation flows through it: pulling metadata from an org with sf project retrieve, pushing to a scratch org with sf project deploy, version-controlling with git, running Apex tests, generating new components, and deploying to production via DevOps Center or CI pipelines. The project format follows the SFDX source format, a folder structure designed for source control and team collaboration. Salesforce moved away from the older Metadata API-format projects (the Force.com IDE-era format) in favor of SFDX source format because it works better with git, scratch orgs, and modern CI/CD.

Locale is the per-user Salesforce setting that controls how the platform formats numbers, dates, currencies, names, and time displays for that user. The Locale field on the User record is independent of the Language field: a user can display the UI in English while using a French locale for date formats (DD/MM/YYYY instead of MM/DD/YYYY) and currency symbols. Locale also affects how the platform parses user input on edit forms, accepting locally-appropriate formats and converting to the storage representation. The Salesforce platform supports a long list of locales corresponding to ISO standards (en_US, fr_FR, ja_JP, de_DE, en_GB, etc.). Each locale defines date format, time format, decimal separator, thousands separator, currency symbol position, calendar conventions, and other formatting details. The locale list is managed at the platform level; administrators do not add custom locales. Most orgs default each user's Locale to match their geographic location, but global support staff sometimes use a different locale to match the customer they are serving.

The Logged-In User in Salesforce is the User record that owns the current session. Every Salesforce session, whether through the UI, the API, a Connected App, or a flow, runs in the context of one user. The session''s permissions, sharing access, profile settings, and audit trail all derive from this user. Formula functions ($User.Id, $User.FirstName), Apex methods (UserInfo.getUserId(), UserInfo.getProfileId()), and Lightning Component context all expose the logged-in user as a fundamental piece of session state. The concept matters because Salesforce''s entire security model is user-centric. Record access is determined by the logged-in user''s sharing; field-level security is determined by the user''s profile and permission sets; report visibility is determined by the user''s role hierarchy and folder access. Every Apex call, Visualforce page, Lightning Component, and integration callout runs as a specific user. Knowing how to identify, log, and respect the logged-in user is foundational for any Salesforce build that needs to be secure, auditable, or personalized.

Login Access Policies is the Salesforce Setup configuration that controls whether administrators can log in as another user (Login As) for support purposes. The setting governs the global Login As capability that lets an admin impersonate a target user to debug a problem or verify a configuration from that user's perspective. By default, administrators with Modify All Data can use Login As, but the target user must explicitly grant access through the Grant Account Login Access mechanism on their own User record, providing a time-limited window during which the admin can impersonate them. The page also configures policy details: whether users can grant access for varying durations, whether certain administrator roles can bypass the grant requirement, and how Login As events are audited. Compliance-sensitive orgs tighten these settings beyond defaults; the impersonation capability is powerful and audit teams want strict controls around when and by whom it can be used. The Setup Audit Trail captures every Login As event with the admin name, target user name, and timestamp.

Login Flows are the Salesforce mechanism for running a Flow during the user login process, after authentication succeeds but before the user lands on their home page. The flow runs in the user's context with access to their User record fields, and it can be used for forced consent acknowledgments, terms-of-service acceptance, MFA enrollment prompts, branded login walls, password reset workflows, and any other interaction the org wants to mandate at login time. Each Login Flow is associated with a specific Login Type (Standard, Community, Mobile, etc.) and a User License, with the flow running for users matching the configuration. The feature predates many modern alternatives. For consent and acknowledgment, Lightning In-App Guidance and platform features like Identity Verification cover most use cases without needing a Login Flow. For pre-login decisions like MFA, the platform's MFA enforcement now handles the prompts directly. Login Flows remain useful for highly customized login experiences that the standard tools cannot produce: regulatory consent specific to one industry, complex branded landing experiences, or org-specific data collection at first login.

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 the Salesforce field type for storing text up to 131,072 characters. It is the larger sibling of the Text field (capped at 255 characters); admins pick Long Text Area when the field needs to hold extended prose like product descriptions, case resolution notes, custom audit logs, or any text content that exceeds the 255-character cap. The field renders as a multi-line textarea in Lightning Experience, supports basic plain-text content, and stores the value as-is without HTML or formatting. Long Text Area fields differ from regular Text fields in several important ways beyond just length. They are not searchable by default (admins enable indexing per object), they don''t appear in standard list view filters, and they cannot be used in standard SOQL relationship queries. Long Text Area fields are the right choice for content storage and the wrong choice for searchable identifiers. The Rich Text Area field type is the alternative when formatted content (bold, italic, lists) is needed; Rich Text Area is built on top of Long Text Area with an HTML editor.

The Lookup Dialog is the Salesforce UI component that opens when a user clicks the magnifying-glass icon next to a lookup field, letting them search for and select a related record. The dialog presents a search box, recent records, and search results filtered to the related object''s scope. In Lightning Experience, the Lookup Dialog renders as a typeahead dropdown beneath the field with real-time search results and supports keyboard navigation. In Salesforce Classic the dialog opens as a modal popup. The Lookup Dialog is the everyday way users link records together. Picking a Contact on an Opportunity, an Account on a Case, a Product on an Order all use the lookup dialog. The dialog respects record sharing (users see only records they have access to), lookup filters (admins narrow the dialog''s scope to relevant records), and search behavior (the dialog uses Salesforce search, which indexes name and selected other fields). Configuring lookup dialogs well is one of the highest-leverage UX improvements an admin can make.

A Lookup Field in Salesforce is a relationship field type that creates a soft link between two records, storing the parent record''s ID on the child. Unlike Master-Detail relationships, a Lookup is a soft foreign key: the child can exist without a parent (the lookup field can be blank or set to null), the child has its own sharing model, and deleting the parent does not cascade to children by default. Lookup Fields are the most common relationship type on Salesforce custom objects and the foundation of nearly every standard parent-child link (Opportunity.AccountId, Contact.AccountId, Case.ContactId). Lookup Fields produce the magnifying-glass-icon picker in the UI, render as a clickable link to the parent record on display, and expose the relationship via SOQL relationship queries (SELECT Account.Name FROM Opportunity). Admins create lookup fields under Setup, Object Manager. The lookup field type is the default choice for most cross-object relationships; pick Master-Detail only when the child has no meaning without the parent and you want cascade-delete and shared sharing.

A Lookup Filter is a configuration on a Salesforce lookup field that narrows the records the user sees in the Lookup Dialog by applying admin-defined criteria. The filter evaluates each candidate record against the criteria; only records that match appear in the dialog. The filter can reference the source record''s fields, the target record''s fields, formulas, and user attributes, letting admins build context-aware filters like Contact.AccountId = $Source.AccountId or User.Profile.Name = ''Sales Manager''. Lookup Filters are the standard tool for preventing data-quality problems at the source. Without a filter, a user filling in an Opportunity.PrimaryContact lookup sees every Contact in the org and may pick a wrong one. With a filter restricting the dialog to Contacts on the same Account, the wrong-record problem disappears. Filters can be required (block save when the chosen record fails the criteria) or optional (suggest but allow override). Admins configure them under the lookup field''s definition; once saved, every dialog opening of that field respects the filter.

The Lookup Icon in Salesforce is the visual identifier (typically a small SVG or PNG icon) that represents an object across the Lightning Experience UI: in the navigation menu, in lookup dialog results, in related list headers, in global search results, and on the record header. Each standard object ships with a default icon (the Account building, the Contact person, the Opportunity briefcase), and admins can customize the icon for custom objects via the Tab Style configuration. The icons are part of the Salesforce Lightning Design System (SLDS) icon library. Lookup Icons matter because they provide visual chunking in dense interfaces. A search result list mixing Accounts, Contacts, Opportunities, and Cases is far more scannable when each row has its object''s icon than when the rows are plain text. Salesforce ships hundreds of standard icons under SLDS, organized by category (action, custom, standard, utility, doctype). Custom objects can pick from the standard set or upload a custom image. The icon choice affects the entire user experience subtly but consistently.

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 the software-development approach that builds applications primarily through visual, declarative tools rather than hand-written code. In the Salesforce context, Low Code is the philosophy behind Flow Builder, Lightning App Builder, Object Manager, Schema Builder, OmniStudio, Experience Builder, and the broader set of declarative tools that let admins ship business logic without writing Apex. Salesforce''s strategic direction has been Low Code-first since the Lightning Experience launch; many capabilities that historically required code now have declarative alternatives. The term sits on a spectrum: No Code (entirely visual configuration, suitable for simple workflows) at one end, Pro Code (entirely hand-written, full developer toolchain) at the other end, and Low Code (mostly visual with selective code extension) in the middle. Real Salesforce orgs typically mix all three. Admins build core automation in Flow Builder (Low Code), developers extend with Apex Action when declarative tools fall short (Pro Code), and end users sometimes build their own custom list views and reports (No Code). Picking the right level for each piece of work is the modern Salesforce delivery skill.

A Loyalty Member in Salesforce Loyalty Management is a customer or business enrolled in a loyalty program, tracked as a record on the LoyaltyProgramMember standard object. Each Loyalty Member links to a Contact, Person Account, or Account, holds the member''s current point balance, tier status (Bronze, Silver, Gold), enrollment date, and accumulated lifetime activity. The Member record is the central node connecting transactions, point accruals, point redemptions, tier-progression events, and reward catalog interactions in the Loyalty Management product. Salesforce Loyalty Management ships as part of the Industries Cloud product family, targeting retailers, airlines, hospitality companies, financial services, and any B2C or B2B business running structured rewards programs. The Loyalty Member record sits at the center of a rich data model that includes Loyalty Program (the parent program definition), Loyalty Program Tier (Bronze/Silver/Gold), Loyalty Ledger (each point-changing transaction), Voucher (issued rewards), and Promotion (campaign-driven point multipliers). The product is licensed separately and is the foundation of modern Salesforce-based loyalty operations.

A Loyalty Program in Salesforce Loyalty Management is the parent configuration that defines a rewards program: the tier structure (Bronze, Silver, Gold), the point-earning rules, the redemption catalog, the promotion templates, and the enrollment settings. The Loyalty Program record (on the LoyaltyProgram standard object) ties together every member, every transaction, and every reward into a single coherent program identity. A single org can run multiple Loyalty Programs simultaneously (a B2C consumer program and a B2B partner program, for example), each with its own rules and members. Salesforce Loyalty Management is the Industries Cloud product that hosts loyalty programs, targeting retailers, airlines, hotels, financial services, and any B2B or B2C business running structured rewards. The Loyalty Program record defines the rules; supporting objects (LoyaltyProgramTier, LoyaltyProgramMember, LoyaltyLedger, LoyaltyPromotion, Voucher) store the operational data. Loyalty Programs typically launch as part of a customer-engagement strategy and integrate with Marketing Cloud for tier-driven campaigns, Service Cloud for member care, and Data Cloud for unified customer profiles.

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.