Overview
Lightning Data Service (LDS) is Salesforce’s client-side data access layer that simplifies working with Salesforce records in Lightning components. It provides declarative, performant, and secure access to record data without requiring Apex controllers, handling caching, sharing rules, and record-level security automatically.
Key Features
– CRUD operations without Apex: read and modify records using out-of-the-box UI components or the UI API adapters/methods.
– Platform-managed caching: LDS caches records on the client and synchronizes updates across components, reducing server calls and improving performance.
– Security and sharing enforced: respects field- & object-level security and sharing rules automatically.
– Works in Aura and LWC: available through force:recordData in Aura and lightning/ui* modules and base components in Lightning Web Components.
When to use Lightning Data Service
Use LDS when you need to display or edit records in Lightning components and want to avoid writing Apex for simple CRUD operations. It is ideal for:
– Standard record forms (view/edit/create) using base components.
– Multiple components on the same page that need the same record — LDS shares a single cached copy and keeps them in sync.
– Scenarios where platform security (FLS & sharing) must be enforced automatically.
Common ways to use LDS
1) Base Lightning Components (no code):
Use components like <lightning-record-form>, <lightning-record-view-form>, and <lightning-record-edit-form> to quickly add forms and record UI that leverage LDS under the hood.
2) Lightning Web Components (UI API / wire adapters):
Use the lightning/uiRecordApi module for programmatic access — it still uses LDS and the UI API. Example:
import { LightningElement, api, wire } from 'lwc';
import { getRecord } from 'lightning/uiRecordApi';
const FIELDS = ['Account.Name', 'Account.Industry'];
export default class AccountSummary extends LightningElement {
@api recordId;
@wire(getRecord, { recordId: '$recordId', fields: FIELDS })
record;
}
To update records, use updateRecord from lightning/uiRecordApi or use <lightning-record-edit-form> for form-based editing.
Benefits
– Reduced development effort: less Apex and boilerplate code.
– Improved performance: client-side caching reduces round trips.
– Consistent security: platform enforces FLS and sharing.
– Automatic synchronization: multiple components see updates instantly.
Limitations & Considerations
– Not for complex server-side logic: if you need complex queries, aggregations, or business logic, use Apex.
– API limits & large data sets: while LDS is efficient for record-level operations, bulk data processing should use batch Apex or other server-side approaches.
– Partial field support: some UI API features may not expose every field or object type; test before relying on an uncommon object/field.
Best Practices
– Prefer base components for standard record UI to save development time.
– Use @wire adapters for reactive data access in LWC and avoid unnecessary imperative calls.
– Keep UI responsive: rely on cached LDS data where possible and handle loading states.
– Respect limits: for mass updates or complex queries, use Apex or server-side approaches.
Summary
Lightning Data Service is the recommended way to build record-centric Lightning experiences in Salesforce. It reduces code, improves performance through client caching, enforces security automatically, and keeps multiple components synchronized without custom event wiring or Apex controllers.