Salesforce terms starting with D

A Dashboard is a Salesforce analytics surface that displays multiple report results as visual components (charts, gauges, metrics, tables) on a single page. Each dashboard component pulls from one underlying report, applies an aggregation or visualization, and renders inside the dashboard layout. Dashboards refresh on a schedule or on demand, and the rendered state caches until the next refresh, so consumers see consistent numbers without re-running reports manually. Dashboards are the executive and operator face of Salesforce data. Sales pipelines, support backlogs, marketing attribution, finance close progress, partner health: each is typically a dashboard with five to twenty components arranged for at-a-glance reading. Lightning dashboards support twenty components per dashboard, with filters at the dashboard level that cascade to every component. Each component has a running user, which determines the data context used to evaluate the source report; this is the mechanism that lets one dashboard serve different audiences based on whose access drives the data.

Dashboard Builder is the drag-and-drop Lightning interface for assembling Salesforce dashboards from existing reports. You pick reports as data sources, add components (bar charts, donuts, metrics, tables, gauges, scatter plots), arrange them on a grid, and configure refresh schedules, filters, and viewer permissions. Each component renders the report it points at, scoped by any dashboard filter and the Running User's record access. Dashboard Builder is the successor to the older Classic dashboard editor. The Lightning version supports up to 25 components per dashboard, multiple columns of variable width, real-time component-level filtering, and a Component Builder side panel that lets you change chart types without leaving the dashboard. The underlying object is the Dashboard standard object; components map to DashboardComponent records that store the chart configuration and report reference.

Dashboard Filters are runtime filters applied to a Salesforce Lightning dashboard that scope every component whose underlying report contains the filtered field. Each dashboard supports up to three filters, each with up to 50 filter values. A viewer picks values from the filter dropdown in the dashboard header and the components re-render against the filtered slice without anyone editing the source reports. Dashboard Filters work above the report layer, applied after the source query but before component rendering. A component whose source report does not have the filter field simply ignores the filter; it does not error out or hide. This is what makes the same dashboard usable across regions, account segments, or product lines. One dashboard, three filters, fifty values each, and a sales operations team that does not have to clone the dashboard nine times.

A Dashboard Widget in Salesforce, also called a Dashboard Component, is one of the individual visual tiles inside a Lightning Experience or Classic dashboard that renders data from a single source report. Each widget pulls rows from its report and displays them as a chart, gauge, metric, or table. A dashboard is a layout of multiple widgets; widgets share filters and refresh together but are configured independently. Dashboards exist to surface report data in a way that is faster to scan than the underlying tabular report. A Dashboard Widget condenses a report into one bar chart, donut, metric tile, or summary table that a leader can read at a glance. Salesforce ships a fixed set of widget types (line, bar, donut, pie, funnel, scatter, gauge, metric, table, Lightning Component); each maps to a different visual pattern. The dashboard editor is drag-and-drop; building a widget requires picking a source report, choosing a widget type, and configuring axis or sort settings.

Data Categories in Salesforce are admin-defined hierarchical classifications used to organize Knowledge articles and Answers questions for filtered access, search scoping, and visibility control. Each Data Category Group (Geography, Product Line, Issue Type, Audience) contains a tree of Data Categories (North America > United States > California; Cloud Products > Sales Cloud > Pipeline Management). Articles and questions are tagged with one or more categories from each group; users browse, filter, or search within categories that match their context. Data Categories exist because Knowledge bases grow to thousands of articles, and a flat list becomes unusable. The category hierarchy lets admins control which articles surface for which users (Geography categories let a US user see US-specific articles), which articles appear together (Product Line categories let related articles cluster in search results), and which articles a Knowledge user can access (Category Group Visibility settings gate access per profile). Categories are how Knowledge scales from dozens of articles to tens of thousands.

A Data Category for Articles in Salesforce is a label within a Data Category Group used to classify Knowledge articles by topic, product, region, or any other taxonomy the organization wants to browse Knowledge by. When an author creates or edits an article, they assign one or more Data Categories. Readers in the Knowledge base, Experience Cloud sites, or Service Console can then filter articles by category to find relevant content. Sharing rules can also restrict article visibility based on category. Data Categories for Articles remain a supported, actively used Knowledge feature in modern Salesforce. They are part of Salesforce Knowledge core configuration and continue to work alongside newer additions like Topics (Experience Cloud) and Knowledge AI features. The hierarchical structure of Data Categories is what makes them well-suited to product or geography classification, where there is a natural parent-child relationship between categories.

Data Classification Download is the Salesforce Setup utility that exports the org's current Data Classification metadata (per-field classifications like Sensitivity Level, Compliance Categorization, and Data Owner) as a CSV file. Admins use the download to review classifications offline, share with compliance teams, validate against external data inventory systems, or feed into separate compliance tooling. The downloaded CSV contains one row per classified field with the field's object, API name, label, and the classification values currently assigned. Data Classification Download exists because field-by-field classification review in Setup is slow. A large org with thousands of custom fields needs a bulk view to audit which fields are properly classified, which are missing classifications, and whether the classifications align with the org's data governance policy. The downloaded CSV is the analysis surface; the matching Data Classification Upload utility is how bulk classification changes flow back into the platform.

Data Classification Settings is the Salesforce Setup area that hosts the org's Data Classification feature: per-field classifications (Sensitivity Level, Compliance Categorization, Data Owner) plus the Download and Upload utilities that let admins manage classifications in bulk via CSV. The page is the central surface for Data Classification policy, the configuration UI for per-field metadata, and the entry point for the bulk audit and update workflow that mature data governance teams rely on. Data Classification Settings exists because every regulated org needs to know what data lives in which fields and how sensitive each field is. The classification metadata drives downstream policy: which fields require Shield Platform Encryption, which fields appear in PII compliance reports, which fields the DSR (data subject rights) workflow needs to scope. Without Data Classification Settings, the data inventory lives in a spreadsheet someone updated two years ago; with it, the inventory lives in the platform metadata and stays current with the schema.

Data Classification Upload is the Salesforce Setup utility that ingests a CSV of per-field classification metadata and applies the changes to the org's field definitions in bulk. Admins typically use Upload after downloading the current classification state via Data Classification Download, editing the CSV offline to add missing classifications or update existing ones, and uploading the corrected file. The Upload applies Sensitivity Level, Compliance Categorization, Data Owner, and Data Sensitivity Description values from the CSV to the matching fields without code deployment. Data Classification Upload exists because per-field classification through Object Manager is impractical past a few dozen fields. A regulated org with thousands of custom fields needs the bulk path; the Upload utility provides it. The Download/Upload pair forms the complete bulk audit workflow: download current state, fix gaps and drift offline, upload corrections. The pattern is the only practical way to maintain accurate classifications at organizational scale.

Data Cloud is Salesforce's customer data platform (CDP) for unifying data from across an organization's systems into a single, real-time customer profile. It ingests data from Salesforce orgs, external databases, data warehouses, marketing platforms, web and mobile event streams, and any other source, then resolves identities, builds unified profiles, computes calculated insights, and exposes the unified data back to Sales Cloud, Service Cloud, Marketing Cloud, Agentforce, and external systems. Data Cloud is the platform's strategic play for becoming the operational data layer underneath every customer engagement. Originally launched as Customer 360 Audiences, then Genie, and finally rebranded as Data Cloud, the product has evolved into the foundation Salesforce now uses for Agentforce grounding, Marketing Cloud Engagement personalization, and cross-cloud customer journey orchestration. Data Cloud is licensed separately from base Salesforce, with consumption-based pricing measured in credits across ingestion volume, profile counts, computed insights, and activations. The data lives in Salesforce's hyperscale columnar store (built on Snowflake/Iceberg architecture) optimized for analytical and AI workloads rather than transactional ones.

Data Encryption in Salesforce is the umbrella for the platform features that encrypt data at rest and in transit: Shield Platform Encryption (admin-configurable field-level and file-level encryption with customer-managed keys), Classic Encryption (legacy text field encryption), Transport Layer Security (TLS) for all data in transit between client and server, and at-rest encryption Salesforce applies by default at the storage layer. Together they form the encryption posture every regulated org needs to understand. Data Encryption matters because regulated industries (financial services, healthcare, government) commonly require encryption with customer-managed keys for sensitive fields and files. Without it, the org relies on Salesforce-managed at-rest encryption which is invisible to the customer and not configurable per-field. Shield Platform Encryption is the heavyweight option that gives the customer encryption-key control; Classic Encryption is the lightweight legacy option for one or two highly-sensitive text fields. Most regulated orgs run a combination based on data sensitivity and compliance requirements.

Data Encryption Keys in Salesforce are the cryptographic key material that Shield Platform Encryption uses to encrypt and decrypt the org's protected fields, files, and search index data. Each key is a secret value the platform holds in escrow (Salesforce-managed keys), the customer holds entirely (Bring Your Own Key, BYOK), or the customer manages through Salesforce's Cache-Only Key Service (the key never touches Salesforce storage; the platform fetches it from the customer's key server per request). The key management approach defines the compliance posture; the keys themselves are the cryptographic primitive that makes the encryption real. Data Encryption Keys exist because Shield Platform Encryption is built on customer-managed cryptography. The customer choosing BYOK supplies the master key material; the platform derives per-tenant data encryption keys from it. The customer choosing Cache-Only Key Service keeps the key material entirely outside Salesforce. The choice of key management approach is the most consequential Shield design decision; it determines compliance positioning, operational responsibility, and the audit story.

Data Export in Salesforce is the Setup feature that lets administrators schedule or run on-demand exports of the org's data as a set of compressed CSV files (one file per object) sent to the admin's email as a downloadable archive. Each export captures the data the org has at the moment of run, optionally including attachments and chatter content. Admins use Data Export for backup, archival, off-platform analytics, and compliance retention. Data Export is the simplest backup mechanism Salesforce ships. It runs weekly (Enterprise+) or monthly (Professional), exports every selected object to CSV, and zips the files for download. The feature is not real-time, not granular per-record, and not suited for high-volume replicas; for those needs, orgs use Bulk API exports, third-party backup tools (OwnBackup, Spanning, Gearset Backup), or Salesforce's own Backup product (the newer paid backup add-on). Data Export remains the default lightweight option that ships with every edition.

The Data Import Wizard is a browser-based Salesforce tool for importing records into Accounts, Contacts, Leads, Solutions, Campaign Members, and most custom objects. It runs inside Setup, walks the user through a five-step wizard, and handles CSV files up to 50,000 records per import. It is the lightweight alternative to Data Loader: no installation required, simpler UI, and tightly integrated with the Salesforce platform UX. The wizard handles insert, update, and upsert operations for the supported object types. It auto-detects duplicates using configurable matching criteria (Salesforce ID, name and account, email, or external ID). Field mapping happens through a drag-and-drop interface that suggests matches based on header similarity. After import, the wizard sends an email with a summary report and a downloadable CSV of any error records. The Data Import Wizard is the right tool for most admin-driven, one-off imports under the 50,000-record cap; Data Loader and Bulk API 2.0 take over for larger or more complex jobs.

Data Integration Metrics in Salesforce is the Setup page that surfaces operational telemetry on the org's data integration activity: Bulk API job volume and success rates, REST API request counts, External Object query throughput, Salesforce Connect virtualization performance, Change Data Capture event volume, and Platform Events publication and delivery. The page aggregates per-integration-type metrics so admins can spot trending issues (rising error rates, throttling, latency creep) before they become production incidents. Data Integration Metrics exists because integration health is otherwise invisible. A nightly Bulk API job that started failing on 5 percent of records last week stays unnoticed until downstream reports look wrong; a Connected App with rising token errors stays unnoticed until users complain about authentication failures. The Metrics page is the operational dashboard for integrations; treating it as routine ops furniture rather than as something to check only during incidents is the discipline that separates orgs with healthy integrations from orgs with constant integration surprises.

Data Integration Rules in Salesforce are Setup configurations that enable Lightning Data, a Salesforce-managed data enrichment service that automatically fills in or updates fields on Account, Lead, and Contact records using data from D&B Hoovers, Dun & Bradstreet, or other Salesforce-connected data providers. Each Data Integration Rule maps a specific provider's data set to a target object, defines which fields enrich, sets the update behavior (overwrite vs fill blanks), and runs on a configured schedule. Data Integration Rules exist because manual data entry on accounts and contacts is incomplete, inconsistent, and stale. Reps know the company name but not the DUNS number, the parent company, the SIC code, the headquarters address, the global revenue, the employee count. Lightning Data fills these gaps automatically; the rule is the configuration that maps the data flow from the provider to the org's records. Most sales teams that adopted Lightning Data see immediate enrichment of every new Account; the rule defines exactly which fields enrich and how.

Data Loader is Salesforce's free, official desktop application for loading, exporting, and transforming Salesforce records in bulk. It runs on macOS and Windows, supports all the standard DML operations (insert, update, upsert, delete, hard delete, export), reads and writes CSV files, and uses Bulk API or Bulk API 2.0 under the hood for high-volume operations. Data Loader is the workhorse tool for any Salesforce admin or consultant doing data migrations, periodic loads, or one-off mass updates. The tool has two interaction modes: an interactive GUI for ad-hoc operations and a command-line interface for scripted, scheduled workloads. The GUI walks the user through field mapping, operation type, and file selection. The CLI runs from a configuration file and works well in nightly cron jobs or post-deployment data refreshes. Data Loader authenticates via OAuth (recommended) or the deprecated username-password flow, and respects all the standard Salesforce security model: field-level security, sharing rules, validation rules, and triggers all fire as the user running the load.

Data Manipulation Language (DML) in Salesforce is the set of Apex statements and operations that create, update, delete, undelete, merge, or upsert records in the Salesforce database. The core DML statements are insert, update, delete, undelete, merge, and upsert, applied either as bare statements on a single sObject or list of sObjects, or as Database methods (Database.insert, Database.update, etc.) that return Result objects with per-record success and error information. DML is how Apex code modifies data in Salesforce; SOQL reads, DML writes. DML in Apex is similar in spirit to SQL DML in traditional databases but has Salesforce-specific constraints. Every DML operation runs inside an Apex transaction, is bound by Salesforce governor limits (most importantly 150 DML statements per transaction), and triggers downstream automation: validation rules, triggers, workflow rules, processes, Flows, and any other configured automation cascade from the DML write. Apex developers spend significant effort planning DML to stay within limits and to handle the cascading side effects correctly.

A Data Model Object (DMO) is the canonical entity in Salesforce Data Cloud that represents a real-world concept like Individual, Account, Email Engagement, or Order. DMOs are the harmonization layer above the raw Data Lake Objects (DLOs) that Data Streams produce. The DMO defines a consistent schema across every source system; field harmonization happens via DLO-to-DMO mappings that translate source-specific field names (Sales Cloud Contact.FirstName, Marketing Cloud Subscriber.first_name, external Customer.given_name) into one canonical attribute (Individual.FirstName). Data Cloud ships a standard set of DMOs covering the most common B2B and B2C entities, called the Customer 360 Data Model. Customers can extend the standard DMOs with custom attributes, build custom DMOs for org-specific concepts, and configure relationships between DMOs that mirror real-world record linking (an Individual is related to many Email Engagements, an Account has many Individuals as Contacts). The DMO is what downstream Data Cloud features (Identity Resolution, Segmentation, Calculated Insights, Activations) query and operate against.

Data Protection and Privacy in Salesforce is the umbrella Setup area and configuration toolkit for managing how the org handles personal data subject to privacy regulation (GDPR, CCPA, HIPAA, regional privacy laws). It includes the Data Protection and Privacy settings page, the Individual object (where consent and contactability preferences are stored), the Privacy Center managed app (for handling data subject requests), and the integration with Data Classification and Shield Platform Encryption that together form the org's privacy posture. Data Protection and Privacy exists because privacy regulation is no longer optional in most jurisdictions. Customers, employees, and partners have legally-defined rights to know what data the org holds about them, to correct it, to delete it, to receive a copy, to revoke consent. Salesforce's Data Protection and Privacy features give admins the platform-level tools to honor those rights without building everything custom. Most regulated and consumer-facing orgs configure these features at go-live or during their next privacy program review; orgs that wait until a regulator asks usually find the gap costly to close.

Data State in Salesforce is the lifecycle classification assigned to a field through the Data Classification framework, indicating whether the data in the field is currently Active (in production use), Archived (retained but not actively used), or Purged (deleted or scheduled for deletion). The classification helps the platform and downstream compliance tooling reason about which data is operationally live, which is retained for compliance only, and which has aged out of retention. Admins set Data State per field as part of the broader Data Classification metadata alongside Sensitivity Level and Compliance Categorization. Data State exists because privacy and retention regulations distinguish between operational data the org actively uses and historical data the org keeps only because regulation requires retention. Treating the two the same overstates the org's data footprint and complicates DSR scoping. The Data State classification gives admins a structured way to declare the lifecycle status of each field, which downstream compliance and data governance tools can consume to scope reports, retention automation, and access controls.

A Data Stream is the Salesforce Data Cloud configuration that brings external data into the platform as a continuously updated feed. Each Data Stream connects to one source system (Sales Cloud, Marketing Cloud, Amazon S3, Snowflake, Google Analytics, a custom REST endpoint), ingests records on a defined cadence (real-time, hourly, daily), maps source fields to a Data Lake Object, and lands the data in Data Cloud's storage layer. Data Streams are the entry point for every piece of data that powers segmentation, identity resolution, and customer profile assembly. The Data Stream concept replaces the older one-time bulk-load pattern with a managed, ongoing ingestion pipeline. Each stream tracks high-water-mark cursors so it picks up only new or changed records on each run. The stream stores the raw incoming data in a Data Lake Object (DLO), and downstream Data Model Object (DMO) mappings reshape it into the canonical Customer 360 model. The split between DLO (raw, source-shaped) and DMO (canonical, business-shaped) is what makes Data Cloud's data model flexible across dozens of source systems.

In Salesforce, the database is the persistent relational storage layer that holds every record in your org. Standard objects (Account, Contact, Opportunity), custom objects, metadata, and platform-level configuration all live as rows in tables on a shared multi-tenant infrastructure. You never touch the underlying database directly. Salesforce sits between you and the storage, exposing the data through SOQL queries, SOSL searches, the REST and SOAP APIs, and the user interface. The platform runs on a multi-tenant architecture where every customer shares the same physical database but sees only their own data. Each row carries an organization identifier that Salesforce uses to enforce tenant isolation at the query layer. That design is why you can deploy a custom field in seconds (it adds a column to a shared, pre-allocated table rather than altering a customer-specific schema), and why governor limits exist to keep one tenant's heavy query from starving the others.

A database table in Salesforce is the storage representation of an object. Every standard object (Account, Contact, Opportunity, Case, and so on) and every custom object you create maps to a row in Salesforce's metadata catalog, which the runtime then translates to space inside the platform's shared relational storage. Fields are columns, records are rows, and the table inherits the platform's tenant isolation, sharing, and field-level security automatically. You never write CREATE TABLE or DROP TABLE directly in Salesforce. The Object Manager, the Metadata API, and Lightning Schema Builder are the legitimate ways to define a Salesforce database table. Behind the scenes the platform does not allocate one dedicated physical table per object. It stores most records in a small set of shared, typed-column tables with a metadata layer that maps your specific object and field names onto pre-allocated column slots.

A Dataflow Step is a single node in a CRM Analytics dataflow definition. It is a JSON snippet that pulls in a source, transforms the rows, and hands the output to the next step in the pipeline. Each step has a unique name, an action (sfdcDigest, augment, filter, computeExpression, sfdcRegister, and so on), and a set of parameters that drive what it does. Steps reference each other by name, building a directed graph that ends in one or more registered datasets. Dataflows have largely been superseded by Data Prep recipes since 2023 for new ingestion work, but existing dataflows still run on a scheduled or on-demand basis. Steps are defined in the dataflow's JSON and edited either in the JSON editor or the older drag-and-drop visual editor inside CRM Analytics Studio. A typical analytics dataset is built from 5 to 20 dataflow steps wired together.

Dataloader.io is the cloud-based Salesforce data loading tool from MuleSoft (formerly an independent product, now Salesforce-owned and bundled with most editions) that supports insert, update, upsert, delete, and export operations on Salesforce records through a web interface rather than a desktop client. Admins upload CSV files or connect to cloud storage (Dropbox, Box, FTP), map columns, run jobs on demand or schedule, and review per-record results in the browser. Dataloader.io is the cloud counterpart to the desktop Data Loader application many orgs have used for years. Dataloader.io exists because the desktop Data Loader, while functional, requires installation, runs only on the admin's local machine, and does not support scheduling without third-party wrappers. Dataloader.io eliminates those frictions: nothing to install, runs in the browser, supports scheduled jobs through its cloud infrastructure, and integrates directly with cloud storage. Most modern Salesforce admins use Dataloader.io for ongoing data operations and reserve the desktop Data Loader for the rare scenarios where local-machine execution is required.

DataRaptor is OmniStudio's declarative tool for reading from, transforming, and writing to Salesforce data without writing Apex. You configure source fields, output structure, formulas, and validation in a guided UI, and the resulting DataRaptor becomes a reusable component that Integration Procedures, OmniScripts, FlexCards, and direct API callers can invoke. The four flavors (Extract, Transform, Load, and Turbo Extract) cover the common shapes of a CRUD operation. Starting with Summer '24, Salesforce is renaming DataRaptors to Data Mapper inside OmniStudio (Data Mapper Extract, Transform, Load, and Turbo Extract). The capability is the same, the metadata is the same, and existing references keep working. New documentation and the OmniStudio Designer use the new name, while the underlying API objects still carry the legacy VlocityDataRaptor names for backward compatibility.

Dataset Builder is the visual tool inside CRM Analytics that lets you create a dataset by picking a Salesforce object and dragging in the related objects and fields you want to include. The output is a generated dataflow JSON definition with the right sfdcDigest and augment steps in place; you save and run it, and the dataset is registered for use in dashboards and lenses. It is the fastest way to produce a new analytical dataset without hand-writing a dataflow. The builder shows objects as boxes connected by their lookup and master-detail relationships. You pick a root object (Opportunity, for example), then click related objects (Account, Owner, Stage History) to add them, and check the fields you want from each. When you save, CRM Analytics generates the dataflow steps, registers the dataset, and runs the first extract. Future schema changes (added fields, new relationships) require editing the generated dataflow directly or rebuilding through Dataset Builder.

DataWeave Resources is the Setup page where you view and manage the DataWeave scripts deployed to your Salesforce org. Each DataWeave Resource is a .dwl file (DataWeave 2.x source) that you author in your IDE, package as metadata, and deploy alongside the Apex code that calls it. Once deployed, the script appears under Setup, DataWeave Resources with its name, namespace, and the DataWeave version it targets. DataWeave is MuleSoft's transformation language, embedded in the Salesforce platform since Winter '23. Apex code calls a script through the Dataweave.Script class, passing inputs and receiving the transformed output without writing parsing logic by hand. It is the supported way to convert between JSON, XML, CSV, and Salesforce objects when the shape of the data is complex enough that hand-rolled Apex would be brittle or unreadable.

A date literal is a SOQL keyword that represents a relative date or date range, evaluated at query time against the current date in the user's locale. TODAY, YESTERDAY, LAST_WEEK, THIS_QUARTER, LAST_FISCAL_YEAR, and parameterized forms like LAST_N_DAYS:30 cover most operational queries you would otherwise build with hardcoded date arithmetic. Reports, list views, and dashboards use the same literal vocabulary in their date filters. Date literals exist because hardcoding a date into a query (CloseDate = 2026-05-20) freezes that query to a single point in time. The literal expands at execution into the right calendar boundaries, accounting for time zones, fiscal year setup, and the user's locale. A scheduled report filtered to LAST_QUARTER produces the right window every quarter without anyone editing it.

Dated Exchange Rates in Salesforce are time-specific currency conversion rates that apply for a defined date range, layered on top of the org's default ConversionRate (which is the always-current static rate). With Dated Exchange Rates enabled, the org maintains a history of rates per currency per date range; financial calculations (Opportunity Amount, Quote pricing, roll-up summaries) use the rate that was in effect on the relevant transaction date rather than the always-current rate. The feature is essential for finance teams that need historically-accurate conversion for reporting and audit purposes. Dated Exchange Rates exist because static ConversionRate produces misleading historical reports. An Opportunity worth 100,000 EUR closed in Q1 2024 when EUR/USD was 1.10 produced 110,000 USD in revenue; an always-current rate of 1.05 in 2026 would re-report the same opportunity as 105,000 USD. Finance teams need the historical rate to match what actually happened. Dated Exchange Rates produce the right answer for historical reporting at the cost of maintenance overhead (admins or scheduled jobs must enter new rate rows as periods elapse).

A debug log is the time-stamped trace of everything that happened during a Salesforce transaction: Apex execution, SOQL queries, DML operations, validation rules, workflow actions, callouts, and the governor-limit running totals. The platform captures one when a Trace Flag is active for the running user or for the entity that triggered the transaction. Debug logs are the primary diagnostic surface in Salesforce, used by developers and admins to figure out why a process behaved the way it did. A log is a structured text file divided into event lines, each carrying a category (APEX_CODE, DB, SYSTEM, and so on) and a level (DEBUG, FINE, FINEST, and others). You configure which categories and levels are captured through Debug Levels and which users or transactions produce logs through Trace Flags. Logs live in the ApexLog table for up to 7 days and are accessible through the Developer Console, Setup, or the Tooling API.

Decimal Places in Salesforce is the per-field configuration on Number, Currency, and Percent field types that controls how many digits appear after the decimal point. A Currency field configured with 2 decimal places stores 1234.5678 as 1234.57 (rounded); a Number field with 4 decimal places stores the full 1234.5678. The decimal places setting is part of the field definition; admins set it at field creation and it governs both storage precision (how many digits the platform persists) and display formatting (how many digits users see in the UI). Decimal Places matters because precision requirements differ by use case. Currency for commercial transactions needs 2 decimal places (dollars and cents). Currency for forex trading might need 4 or 6 (basis points). Number for quantity counts needs 0 (whole units). Number for scientific measurements might need 6 or 8. Picking the wrong decimal places at field creation produces either over-precision (storage and display waste) or under-precision (data loss through rounding). The setting is hard to change later for fields with data, so getting it right at creation matters.

A Decision Table is a Salesforce Industries / OmniStudio Business Rules Engine artifact that maps input columns to output columns in a spreadsheet-like grid. Each row is a rule: given a set of input values (or ranges), the matching row's output columns are returned. Decision Tables are how policy, pricing, eligibility, and tier logic gets configured without writing Apex, and they are versioned and deployable as metadata. The table is part of the Business Rules Engine (BRE) that sits inside OmniStudio (formerly Vlocity) and underpins many Salesforce Industries clouds. You define it through the Decision Table Designer or by importing a CSV. Expression Sets and Calculation Procedures invoke a Decision Table by name, pass in the input columns, and receive the matched output. The first matching row wins by default, though you can configure all-matches behavior for cumulative rules.

Deep Clone Product Settings is the Salesforce Setup page that configures the behavior of the Deep Clone feature for Product2 records: which related records (PricebookEntry, ProductFeature, ProductAttribute, related Bundle children, ProductRelatedComponent) are included when an admin clones a Product, what default values are applied to the cloned children, and how the cloned hierarchy preserves relationships from the source Product. The settings page lets admins decide whether Deep Clone is a faithful copy (every related record carries over) or a structured clone (only specific relationships carry). Deep Clone Product Settings exists because Product catalog management at scale produces near-duplicate Product configurations constantly: new SKUs that share most attributes of existing SKUs, regional variants of a global Product, annual refreshes of a seasonal Product line. Manual recreation of every related record (PricebookEntries across multiple Pricebooks, ProductFeatures, related components) is error-prone and slow; Deep Clone automates the duplication with admin-controlled behavior. The settings page is where the admin defines what Deep Clone copies and what it leaves out.

Delegated Administration in Salesforce is the feature that lets a System Administrator grant a subset of admin privileges to specific non-admin users without making them full System Administrators. Each Delegated Group defines which users hold the delegated privileges, which custom objects they can manage, which profiles they can assign to other users, and which permission sets they can grant. The delegated admins can create and manage users within their scope but cannot do everything a full admin can; the scope-limited model is the point. Delegated Administration exists because giving every junior admin the full System Administrator profile is overkill and risky. A team leader who needs to create users in their region, reset passwords for their team, and assign a small set of permission sets does not need the platform-wide power to delete custom objects or change sharing rules. Delegated Administration creates a middle tier: scoped admin power for the specific tasks the role needs, without the keys-to-the-kingdom risk of full System Administrator access.

A Delegated Approver is a user designated on another user's profile to approve or reject approval requests on the original user's behalf. The original approver still receives every approval request, but the delegate also gains the right to act on those requests through the Items to Approve list. The platform records both the original approver and the delegate in the approval history, so the audit trail stays intact. Delegation is set up on the User record (Setup, then Users, then the user's detail page, then Delegated Approver). It is most commonly used for vacation coverage or to give a manager's assistant the ability to clear backlog while the manager focuses elsewhere. Salesforce does not move the request; both users see it, and either can act.

Delegated Authentication in Salesforce is the legacy single sign-on mechanism that lets the org outsource login verification to an external authentication service through a SOAP web service callout. When a user logs in, Salesforce sends their credentials to the configured external endpoint; the endpoint validates against the customer's identity store (LDAP, on-prem AD, custom directory) and returns a true/false response. The pattern predates SAML and OpenID Connect; modern orgs almost universally use SAML SSO, Auth Providers, or Identity Connect rather than Delegated Authentication. Delegated Authentication exists for backward compatibility with very early Salesforce SSO deployments. The mechanism is functional but has significant downsides: it requires an internet-reachable SOAP endpoint, the password traverses the network on every login, the external service must be highly available (downtime equals login failure), and the audit trail is split between Salesforce and the external service. Modern SSO patterns (SAML, OAuth/OIDC) eliminate most of these issues. New SSO deployments should default to SAML or Auth Providers; orgs still on Delegated Authentication should plan migration.

Delegated Authentication Error History is the Salesforce Setup log that captures every Delegated Authentication callout failure: the timestamp, the user attempting login, the error type (endpoint unreachable, certificate invalid, timeout, validation false), and the response detail if available. The log is the diagnostic surface for orgs running Delegated Authentication; failures here mean users could not log in, and the log is how admins reconstruct what went wrong. Delegated Authentication Error History exists because Delegated Authentication failures are silent to the user beyond a generic login-failed message. Without the history, admins have no way to distinguish a network blip from a configuration error from an external service outage. The page surfaces the error type and timing so admins can correlate with endpoint logs, infrastructure events, or certificate expirations. For orgs migrating off Delegated Authentication, the history is also the evidence base for documenting the operational case for migration.

Delete Attachments Sent as Links is the Salesforce Setup feature that automatically deletes file attachments shared as download links in outbound emails after a configurable retention period (default 30 days). The feature applies when Salesforce email composers send files larger than the standard attachment limit by hosting them on Salesforce-managed storage and including a download link in the email. After the retention period elapses, Salesforce deletes the hosted file; the link in the email becomes a 404. The pattern keeps file storage usage from growing unbounded with every email send. The feature exists because email-attached files accumulate quickly. A sales team sending a 5 MB proposal to a hundred prospects via email creates a hundred file copies if attachments are inline; the link-based pattern stores one file and shares the link, dramatically reducing storage. Without auto-delete, the hosted files would accumulate forever. The auto-delete setting bounds the storage cost; admins configure the retention to match the org's needs (longer for active sales follow-up, shorter for compliance retention).

Deliverability in Salesforce is the umbrella Setup area that controls the org's outbound email behavior: which delivery mode is active (Default, System Email Only, No Access), which authentication mechanisms are configured (SPF, DKIM, DMARC alignment), which compliance and archival features are enabled (Compliance BCC, Email Relay), and the various toggles that affect whether Salesforce-sent emails reach recipient inboxes or land in spam folders. The Deliverability page is the central surface for outbound email integrity. Deliverability matters because modern mail providers (Gmail, Outlook, Yahoo) heavily penalize unauthenticated, low-reputation, or policy-violating outbound mail. A misconfigured Salesforce org sends email that lands in spam folders; the recipient never sees it; the sales follow-up or service notification fails silently. Most outbound email issues admins debug trace back to deliverability misconfiguration: missing DKIM, no SPF inclusion, no DMARC enforcement, wrong sender domain. The Deliverability Setup page is where these are configured and audited.

Demote is the Salesforce Knowledge action that reverts a published article back to draft status. The article disappears from agent search, the Knowledge sidebar, and public-facing community sites; authors can then revise the content and republish. Demote is a quick way to pull an article out of circulation without archiving or deleting it, typically used when an article goes out of date overnight or contains an error that the team needs to fix before customers see it. The action is available on any published article version through the Article Actions menu in Lightning Knowledge (where it is labeled Edit as Draft) or the equivalent in Classic. The article goes back to Draft and stays editable until someone publishes a new version. Other versions of the same article remain in their original state; demote only affects the version that was live.

Density Settings is the Salesforce Setup page that controls the default visual density of Lightning Experience: Comfy (more whitespace, larger row heights, easier-to-click targets) or Compact (tighter spacing, more data on screen, denser tables). The org-wide default applies to users who have not personally adjusted; individual users can override their preference through the user settings menu in the Lightning header. Most orgs configure the default based on user population (sales reps lean Comfy, support agents working many records lean Compact) and let users override personally. Density Settings exists because Lightning Experience renders the same data very differently at different density levels. A list view that shows 10 records per page at Comfy density shows 20 at Compact. A record detail page that requires a scroll at Comfy fits in one screen at Compact. The trade-off is real: Comfy is easier to read and click; Compact shows more data per pixel. The right default depends on the org's user population and the dominant screen size; the per-user override accommodates individual preference.

A dependency in Salesforce is a relationship between two metadata components where one references or relies on the other to function. Apex classes depend on the objects and fields they query; validation rules depend on the fields they reference; Flows depend on the objects, fields, and Apex actions they call; permission sets depend on the objects, fields, and apps they grant access to. Salesforce tracks these dependencies and exposes them through the dependency view in Setup, the MetadataComponentDependency object in the Tooling API, and the deployment validation step. Dependencies matter because they govern what you can change safely and what you can deploy. Deleting a field that a Flow references fails with a dependency error. Deploying an Apex class that uses an unreleased object fails with a missing-dependency error. Packaging a custom feature requires every dependency to either ship in the same package or already exist in the target org. Anyone managing change in a Salesforce org spends a fair amount of time chasing dependencies.

A Dependent Field in Salesforce is a picklist field whose available values are constrained by the current value of a related Controlling Field. The pairing (Controlling Field + Dependent Field) creates a dependent-picklist relationship: when the user picks a value in the Controlling Field, the Dependent Field refreshes to show only the values that are valid for that controlling choice. The classic example is Country as the Controlling Field and State or Province as the Dependent Field; picking United States constrains the State picklist to US states, picking Canada constrains it to Canadian provinces. Dependent Fields exist because some picklists only make sense in the context of another picklist. Without the dependency, the platform would show every State or Province in the world regardless of country, letting users pick invalid combinations and degrading data quality. The Dependent Field is the constrained side of the relationship; the matrix of which dependent values are available per controlling value is configured through Field Dependencies in Object Manager. The pattern is essential for any object with multiple related picklists.

In Salesforce, to deploy is to move metadata and code from one org to another. The source is usually a sandbox, a scratch org, or a Git-backed developer environment; the target is another sandbox, a UAT environment, or production. Salesforce supports several deployment channels: Change Sets (UI-based, for related sandboxes), the Salesforce CLI (sf project deploy start), the Metadata API directly, and third-party DevOps platforms such as Copado, Gearset, Flosum, and AutoRABIT. Each deployment moves a set of metadata components (Apex classes, Flows, custom fields, validation rules, page layouts, profiles, permission sets, and so on) into the target org. The platform validates that every component compiles, that dependencies are met, that tests pass at 75 percent coverage, and that the changes do not violate platform constraints. A successful deployment activates the new components immediately; a failed deployment rolls back the entire change set so the org is never partially deployed.

Deployment Manager in Salesforce is the unified Setup interface for monitoring active and recent metadata deployments to the org, regardless of how the deployment was initiated: change sets, source-tracked deploys via Salesforce CLI, DevOps Center promotions, third-party tools (Gearset, Copado), or direct Metadata API calls. The page lists each deployment with status (Pending, In Progress, Succeeded, Failed, Canceled), start time, finish time, components included, and detailed errors for failed deployments. It is the central diagnostic surface for deployment operations. Deployment Manager exists because deployments come from many sources in modern Salesforce environments. Without a unified view, admins jump between change set status pages, CI logs, and third-party tool dashboards to understand what is happening. Deployment Manager surfaces every deployment in one place, with deep-dive into the per-component results that failed deployments produce. The page is essential operational furniture for any org with multiple deployment paths; orgs with single-source deployments rarely need it but benefit when something fails.

Deployment Settings is the Setup page where you authorize change set traffic between related Salesforce orgs. Each connection is one-way unless explicitly enabled in both directions, and both sides have to flip the switch before any change set can move. This is what permits a sandbox to upload an outbound change set to production, or production to upload a change set down to a sandbox. The page lists every org related to yours (production and its sandboxes, or a sandbox and its peers). For each, you toggle Allow Inbound Changes, which determines whether you accept change sets sent to you. The other org separately toggles Allow Outbound Changes to send. Without both, no change set traffic flows. Deployment Settings has no effect on Salesforce CLI or Metadata API deployments, which authenticate per-user rather than per-org.

Deployment Status in Salesforce is the legacy Setup page that monitors change-set-based deployments specifically: change sets received from connected orgs and change sets deployed locally. The page shows each change set with its status (Pending, Deploying, Deployed, Failed, Validation Only), the components included, the deploying user, and detailed errors for failed deployments. Deployment Status predates the unified Deployment Manager and remains the focused view for change-set deployments. Deployment Status exists because change sets have specific lifecycle states that benefit from a focused view: Validate (dry-run), Deploy (commit), Quick Deploy (skip tests on previously-validated), Cancel. The page surfaces these state transitions clearly for change set work. Most modern Salesforce orgs use a mix of change sets (admin-led) and source-tracked deploys (developer-led); Deployment Status covers the change set side, Deployment Manager covers everything.

A deprecated component in Salesforce is a feature, API, Apex class, custom Lightning component, or platform capability that Salesforce or a package vendor has flagged for eventual removal. The component still works, but Salesforce no longer recommends it, will not add new features to it, and may set a retirement date by which all customers must migrate. Common examples include Workflow Rules (deprecated in favor of Flow), Process Builder, Salesforce Classic UI, S-Controls (long-since retired), JavaScript Buttons, and various Apex classes annotated @Deprecated inside managed packages. The deprecation signal varies by component type. For platform features, Salesforce announces deprecation in release notes and the Trust site, often with a retirement timeline. For Apex methods inside managed packages, the @Deprecated annotation hides the method from new subscribers but keeps it callable for existing ones. For Lightning components, the @api deprecated decorator surfaces a warning in the developer tools. In every case, you can still use the component today, but you should be planning the migration.

Design Center is a browser-based visual tool inside MuleSoft Anypoint Platform for designing APIs and Mule flows. It supports API specifications in RAML 1.0, OAS 2.0, and OAS 3.0, lets you mock the API while you design it, and publishes the finished specification to Anypoint Exchange where teams can discover and reuse it. Design Center is the entry point for API-first development on MuleSoft: design the contract before writing any implementation, share it for review, and only then build the runtime. Design Center has two surfaces. API Designer is the API specification editor, with side-by-side YAML and visual previews and a built-in mocking service. Flow Designer is a no-code Mule flow builder for simple integrations, similar in spirit to a Salesforce Flow but targeting MuleSoft CloudHub deployments. Both publish their output to Anypoint Exchange or directly to runtime.

Detail in Salesforce has two distinct meanings depending on context. In data modeling, a detail is the child side of a master-detail relationship: a record whose existence depends on a master record, whose ownership and sharing are inherited from that master, and which is deleted when the master is deleted. In UI configuration, the Detail section (or Detail tab) is the area on a record page that shows the individual field values for that record, organized through a page layout or a Dynamic Forms component. Both meanings come up frequently. Master-detail's detail records appear in roll-up summaries, share visibility with their master, and cannot be reparented without admin permission. The Detail UI section is where users see and edit the bulk of a record's fields, distinct from the Highlights Panel at the top, the Activity timeline, the Chatter feed, and the related lists. The two meanings rarely conflict in conversation, but knowing the difference saves confusion when an admin says add a field to the detail.

Detail View is the full record-view page in Salesforce: the page that shows a single record's fields, related lists, activity timeline, and Chatter feed. It is the primary interface users hit when they click into a specific Account, Opportunity, Case, or any other record. The Detail View is composed of several Lightning components (Highlights Panel at the top, Detail section in the middle, Related Lists and Activity timeline alongside or below) and is configured through Lightning App Builder for Lightning Experience or page layouts for Salesforce Classic. The Detail View is distinct from a List View (the table of multiple records) and from the Edit View (the inline or full-page edit experience). In Lightning, the URL pattern /lightning/r/ObjectApiName/RecordId/view consistently identifies a Detail View, while /edit opens the edit experience for the same record. Configuration choices made in the Detail View affect what every user sees when they open a record, gated by per-profile or per-record-type assignment.

A Dev Hub is a Salesforce org that has been authorized to create and manage scratch orgs. It is the parent that provisions ephemeral development environments on behalf of the Salesforce CLI, tracks their lifecycle, and enforces usage limits. Every project that uses scratch orgs needs exactly one designated Dev Hub for the team or org; most established teams designate the production org as the Dev Hub because it already has the right edition and licensing. Enabling Dev Hub is a one-click toggle in Setup. Once enabled, the org can authorize the Salesforce CLI to create scratch orgs against it, each with its own allocation against the Dev Hub's daily and active limits. The limits scale with edition: a Developer Edition Dev Hub allows three active scratch orgs at any time; paid plans allow many more. Dev Hub also exposes ScratchOrgInfo records in the data layer for monitoring and reporting on the active scratch org population, which is useful for tracking team usage against the entitlement.

Developer Console is the browser-based IDE inside Salesforce, accessed from the user menu, then Developer Console. It lets you write Apex classes and triggers, edit Visualforce pages and Aura bundles, run SOQL and SOSL queries, view streaming debug logs, set checkpoints and heap dumps, and execute Anonymous Apex against the org. It is the only in-browser developer surface and the most universally available, since it ships with every developer-enabled org and requires no installs. The Developer Console is functional but limited compared with VS Code paired with the Salesforce Extensions Pack. It cannot edit Lightning Web Components, has no Git integration, and is slow on large projects. Most professional Salesforce developers reach for the Developer Console only for quick lookups (a fast SOQL query, a tailing debug log, a checkpoint dump) and do the bulk of their work in VS Code. The Console remains the fastest way to run a one-off Anonymous Apex block or inspect an active log.

Developer Edition is the free Salesforce edition Salesforce gives to anyone who wants a full-featured org for learning, building, testing, or evaluating the platform without buying a production license. Each Developer Edition org includes most platform features (custom objects, Apex, Lightning components, Flow, Reports, Dashboards), a small data storage allotment, two user licenses, and access to Salesforce APIs. The edition is the default learning environment for Trailhead, certification preparation, and individual developer work; ISV partners use Developer Edition orgs as the base for building managed packages. Developer Edition exists to lower the barrier to learning Salesforce. A developer or admin who wants to try the platform, build a proof of concept, or work through Trailhead modules does not need to find an existing org with sandbox access; they sign up for a Developer Edition at developer.salesforce.com and have a personal org in minutes. The edition has limits that make it unsuitable for production (2 users, low storage, no service-level guarantee) but those limits are intentional; the edition is for learning and building, not for operating a business.

A Developer Pro Sandbox is a sandbox type that copies your production org's metadata but no production data, with 1 GB of data storage for testing payloads you create yourself. It is the middle option between a standard Developer Sandbox (200 MB, metadata only) and a Partial Copy or Full Copy sandbox (with sampled or complete production data). The 5x storage upgrade over a standard Developer Sandbox is what makes Developer Pro the right choice for integration testing, code with large data dependencies, or training environments that need realistic data volumes. Developer Pro Sandboxes refresh once per day, the same interval as standard Developer Sandboxes. They are included with Performance and Unlimited editions in limited quantities and can be purchased as add-ons. The org's metadata copy is complete (every object, field, Flow, Apex class, custom setting, and Lightning page comes through), so a fresh Developer Pro looks identical to production except for the empty data tables and a few system-only configurations.

A Developer Sandbox is the smallest Salesforce sandbox type: a copy of your production org's metadata with 200 MB of data storage for testing payloads you create yourself. It is the most commonly provisioned sandbox because every Enterprise, Performance, and Unlimited Edition org gets multiple Developer Sandboxes included, and the 1-day refresh interval makes them practical for daily development work. Developer Sandboxes are the right starting point for any individual developer or admin who needs a safe environment to build and test changes. The sandbox copies every metadata component (Apex, Flows, custom fields, profiles, validation rules, page layouts, custom settings) but no records, files, or content. The 200 MB allocation holds roughly 100,000 standard records at 2 KB each, which is plenty for most unit tests and feature work. When you need more storage or production data shapes, you move up to Developer Pro, Partial Copy, or Full Copy. For 80 percent of dev tasks, Developer Sandbox is the right fit.

Development as a Service (DaaS) is the cloud-delivered tooling model that Salesforce embraces for modern application development. Instead of installing IDEs, version control servers, and build infrastructure locally, you use Salesforce-hosted services and CLIs to spin up scratch orgs, run automated tests, deploy metadata, and manage source through Git. Salesforce DX is the umbrella name for Salesforce's DaaS approach, paired with the Salesforce CLI (sf), the Dev Hub, second-generation packaging, and integrations with VS Code, GitHub Actions, and third-party DevOps platforms. The term is also used more broadly across the cloud-services industry to describe any model where developers consume infrastructure and tooling rather than owning it. Salesforce's specific DaaS lineage runs through its 2017 release of Salesforce DX and continues with every release that expands the CLI, the scratch-org definition format, and the Dev Hub capacity. For Salesforce developers in 2026, DaaS is the default model: you barely touch local infrastructure outside the editor and the Git client.

A Development Environment in Salesforce is any org used for building, testing, or experimenting with code, configuration, or data outside the production org that the business actually operates on. The category covers Developer Edition orgs (free standalone learning and ISV environments), sandboxes spun from a production org (Developer, Developer Pro, Partial Copy, Full Copy), scratch orgs (temporary DX-provisioned orgs for source-tracked development), and Trailhead Playgrounds (Trailhead-spawned learning orgs). Each type has a different purpose, scale, and refresh cadence. Development Environments exist because building directly in production is unsafe and disallowed by mature operational discipline. Bug-causing code, schema-breaking metadata, accidentally deleted records all happen during development; they happen in development environments without touching the data the business runs on. The right environment for the work depends on what the work is: ad-hoc proof-of-concept goes to a Developer Edition or scratch org, multi-developer collaboration goes to source-tracked sandboxes, integration testing goes to Partial Copy or Full Copy sandboxes, UAT goes to Full Copy.

DevOps Center is Salesforce's first-party release management tool, generally available since December 2022. It replaces Change Sets with a Git-backed workflow: developers and admins work in sandboxes or scratch orgs, the platform tracks their changes as work items, and DevOps Center promotes those changes through a pipeline of environments (Dev to UAT to Production) by writing to a GitHub repository. The tool is free for any org and is Salesforce's recommended replacement for sandbox-to-sandbox Change Sets. DevOps Center bridges the gap between Change Sets (limited but easy) and full Salesforce DX with the CLI (powerful but expects CLI fluency). Admins and low-code builders use it through the Salesforce UI, while developers can still use the CLI and Git directly because everything lives in the same GitHub repo. The pipeline is configurable: define your environments, the order they connect, and what triggers promotion.

Dial-Tone Multi-Frequency (DTMF) is the touch-tone signaling standard that telephone keypads use to send digits over a voice line. Each key produces a pair of audio tones that the receiving system interprets as a specific digit or symbol (0-9, star, hash, and A-D in some legacy systems). In Salesforce, DTMF support is part of Service Cloud Voice and Salesforce CTI integrations: contact-center systems use DTMF tones for IVR menu navigation, queue selection, account number entry, and conditional routing before a call ever reaches an agent. Service Cloud Voice surfaces DTMF capture through its Amazon Connect Contact Flow editor, where admins define prompts that collect DTMF input and route based on the digits. Recorded DTMF tones are also surfaced in call transcripts and analytics, with optional tone suppression to mask sensitive entries like PINs in the recording. The actual customer interactions happen via the telephony provider (Amazon Connect for Service Cloud Voice; legacy CTI providers for older setups).

Dialed Number Identification Service (DNIS) is a telephony feature that tells the receiving system which phone number the caller dialed. When a business has multiple inbound numbers (one for sales, one for support, one per region), DNIS is what lets the contact center route the call to the right queue before any IVR menu plays. In Salesforce, DNIS values flow into Service Cloud Voice and other CTI integrations as a routing attribute on the call record, available to Contact Flows and to Apex automation. DNIS is the inbound counterpart to ANI (Automatic Number Identification, which surfaces the caller's number). Both arrive with the call, but DNIS describes what the customer dialed, not where they called from. A toll-free 800-number with DNIS routing can send sales calls to one queue, support calls to another, and warranty calls to a third, all from the same physical number-pool, without the caller ever pressing a key.

Digital Experience in Salesforce is the modern name for what was previously called Community Cloud and is now formally Experience Cloud. The platform lets you build branded portals, customer help centers, partner communities, learning sites, and embedded customer experiences without writing the underlying infrastructure. Each site is a configured collection of Lightning Web Runtime (LWR) or Aura templates wrapped around Salesforce data, with its own URL, theme, navigation, content, and access model. The rebrand from Community Cloud to Experience Cloud (Spring '21) reflected a broader scope: not just internal communities, but any customer-facing digital touchpoint that consumes Salesforce data. A 2026 Digital Experience site can be a help center on help.example.com, a partner portal on partners.example.com, a learning portal with branded content, an embedded chat experience inside another web app, or a microsite for a campaign. All run on the same platform and share infrastructure with the core Salesforce org.

Digital Process Automation (DPA) is the broader industry category for end-to-end automation of customer-facing processes: account opening, claims filing, service requests, order intake, employee onboarding. In Salesforce, DPA is delivered through a combination of OmniStudio (OmniScripts for guided customer flows, Integration Procedures for server-side orchestration), Flow (record-level automation), Industries clouds (vertical-specific accelerators), and Einstein automation (AI-driven decisions in the flow). The result is a digital customer journey that handles itself from web form to closed case without manual handoff. DPA is distinct from BPM (Business Process Management), which historically targeted internal workflow. DPA emphasizes the digital customer experience: branded UIs, mobile-responsive flows, omnichannel handoff (web to chat to email), and AI-driven decisions. A typical Salesforce DPA implementation strings OmniScripts together for the customer-facing portion, hands off to Integration Procedures for server-side work, calls Apex for custom logic, and lands data in Salesforce records that Flow then automates further.

Direct Inward Dial (DID) is a telephony service from a carrier that assigns a block of phone numbers to a single inbound trunk, allowing each number to ring through to a specific destination without an operator. In Salesforce contact centers, DID is the underlying service that makes routed inbound numbers possible: your sales line, support line, and warranty line might all share one trunk, but DID assigns separate numbers that DNIS-based routing in Service Cloud Voice or another CTI system uses to route each call to the right queue. DID has nothing specific to Salesforce; it is a generic telephony concept. What matters in the Salesforce context is that DID is the layer that provides numbers, while DNIS is the layer that identifies which DID number was dialed, and Service Cloud Voice or another CTI integration is the layer that turns DNIS into a routing decision. Buying DID service from your carrier is the prerequisite for everything downstream.

A Directory Number (DN) is the unique number assigned to a single phone line or extension in a telephone system. In a Salesforce contact center, the DN is what identifies an individual agent's phone or workstation: when a call is routed to agent A, the call rings A's DN. The concept predates Salesforce by decades, dating to PBX architectures of the 1970s, but it remains relevant in modern contact-center deployments because each agent still has a phone (soft or hard) reachable at a DN. DNs sit alongside DIDs and DNIS in the contact-center vocabulary. DID provides the inbound numbers customers dial; DNIS identifies which DID was dialed; DN identifies the destination extension that the call is routed to. In Service Cloud Voice on Amazon Connect, the DN concept maps to the agent's Connect login: each agent is identified by a username and a soft-phone endpoint that effectively acts as their DN, even if no traditional telephone number is involved.

Discovery Framework Sample Templates is the Salesforce Setup area that ships pre-built question-and-answer templates for the Salesforce Discovery Framework, the platform feature for building guided assessment forms used in sales qualification, customer onboarding, needs assessments, compliance questionnaires, and similar structured-interview workflows. The samples cover common industry and use case patterns; admins clone the templates as starting points and customize the questions, branching logic, and output mapping to fit their org's specific workflow. The samples exist because building a Discovery Framework assessment from scratch is non-trivial: define the questions, configure branching logic, map answers to record fields, design the rendering layout. Starting from a sample template that covers a similar use case saves significant configuration time and surfaces best practices the org might not know to apply. Most orgs that use Discovery Framework start with a sample template, customize it for their specific needs, and ship the customized version within a fraction of the time a from-scratch build would take.

The Dispatcher Console is the central scheduling interface in Salesforce Field Service. Dispatchers use it to view, assign, and optimize service appointments across a team of mobile workers. The console presents work orders on a Gantt chart timeline, a map of technician locations, and a list of unassigned appointments waiting to be scheduled. From there, a dispatcher can drag appointments onto technicians, trigger an optimization run, monitor live status updates from the field, and respond to schedule disruptions. Field Service (formerly Field Service Lightning) is one of Salesforce's Service Cloud add-ons, designed for industries with mobile workforces: home services, utilities, healthcare home visits, telecommunications, equipment maintenance. The Dispatcher Console is the cockpit; the Field Service Mobile App is the cab. Dispatchers see what is coming, what is in progress, what is delayed, and which technician is best positioned for the next appointment, all in one screen.

DKIM Keys in Salesforce is the Setup area where administrators manage the DomainKeys Identified Mail cryptographic keys the platform uses to sign outbound email. Each DKIM key is a public/private RSA pair: Salesforce holds the private key and uses it to sign every outbound email from the configured domain; the customer publishes the public key as a DNS record so receiving mail servers can verify the signature. The page lets admins create new keys, view active keys, rotate keys, and import keys generated externally (Bring Your Own Key for orgs with strict key management policies). DKIM Keys exist because email authentication is the foundation of modern outbound deliverability. Receiving mail providers (Gmail, Outlook, Yahoo) check DKIM signatures on inbound mail; unsigned or invalid-signature mail lands in spam or gets rejected. Without DKIM, the org's outbound emails fail authentication and inbox delivery rates drop sharply. The DKIM Keys page is where the cryptographic foundation is configured; the Authorized Email Domains setup wires the keys to specific sending domains.

A Document is a standard Salesforce object that stores binary files inside a folder-based hierarchy, used mainly to hold images referenced from HTML email templates, public Sites pages, and Visualforce markup. Documents predate Salesforce Files and rely on a separate sharing model where access is granted at the folder level rather than per record. Each Document record holds a Name, a folder assignment, a Body up to 5 MB, a description, a keyword field, and an IsPublic flag that controls whether the file can be streamed without a Salesforce session. The object remains relevant because the modern Files framework cannot host an image that an external email client will fetch without authentication, and several rendering paths inside Visualforce and Sites still expect the legacy servlet URL. Administrators rarely create new Documents today, but every long-lived org carries hundreds of them tied to email templates and brand assets that nobody wants to break. Treat the object as legacy infrastructure: keep what works, audit what is public, and route new file storage to Files.

A Document Library is a folder in Salesforce's Documents tab or CRM Content section used for storing, organizing, and managing files such as templates, brochures, and reference documents. Documents can be shared internally or embedded in pages and records.

A Donation in Salesforce represents a single contribution from a donor to a nonprofit organization. In the Nonprofit Success Pack (NPSP), Donations are stored on the standard Opportunity object with Type = Donation and configurable Stage values (Prospecting, Pledged, Posted, Paid, Closed Won) reflecting the donation lifecycle. In the modern Nonprofit Cloud, Donations live on the dedicated Gift Transaction object, separating them cleanly from the sales-pipeline Opportunity model. Each Donation captures the donor (linked through Account, Contact, or Account-Soft-Credit), the Amount, the Close Date (gift date), payment method, designation (which fund or program receives the gift), associated Campaign, and any matching gift, in-kind valuation, or attribution details. Donations are the operational unit of nonprofit fundraising. Every dollar received maps to a Donation record, providing the queryable financial backbone for revenue reporting, donor stewardship, IRS Form 990 compliance, and grant-funder accountability.

A Draft Article is a Salesforce Knowledge article in editable, unpublished state. Draft is the lifecycle stage where authors create new articles, revise existing ones, or hold pending changes before they go live. Drafts are not visible to agents in the Knowledge sidebar, not searchable in customer-facing communities, and not surfaced in support flows. Authors and editors with the right permissions can see and modify them; everyone else sees only the previously published version (if one exists). The Draft state is the first stop in the Knowledge article lifecycle. Authors create a Draft Article, fill in content and metadata (data categories, validation status, language), have it reviewed (formally or informally), and then Publish it. Existing published articles can be returned to Draft through the Edit as Draft action (formerly Demote), letting editors fix mistakes or update content without taking down the published version until the new one is ready.

A Draft Translation is a non-master language version of a Salesforce Knowledge article in Draft state, waiting to be reviewed and published. When an English (master language) article changes, Salesforce Knowledge can automatically queue Draft Translations in each enabled language for translators to work on. Each Draft Translation is its own KnowledgeArticleVersion record with the same parent article but a different Language value. Until the translator publishes it, the previous translated version (if any) stays live. Draft Translations are the bridge between source-language authoring and multi-language Knowledge deployment. Without them, the platform would have to wait for all languages to be ready before any could publish, which would slow content delivery. With them, English ships immediately and French, German, Japanese, and Spanish trickle in as their translators complete the work, each on its own schedule.

Duplicate Error Logs are the audit records produced by Duplicate Jobs and Duplicate Rules when a write or batch operation collides with existing data the platform considers a match. Each log entry captures the source record, the matched record or set, the rule that fired, the action taken, and a timestamp, giving administrators a forensic trail of duplicate detection events without manually pulling reports against the source object. The logs surface in the Duplicate Record Sets list view and through the DuplicateRecordSet and DuplicateRecordItem objects, both queryable through SOQL and reportable through the standard report builder. In practice, the logs are how data stewards turn an abstract Duplicate Rule into a workable backlog. A rule can fire thousands of times during a batch import or a year of front-line user activity, and the only sustainable way to triage the matches is through a queue. The logs provide that queue. They also feed the Lightning Duplicate Management UI on the record page, where end users see "Potential Duplicates" surfaced from the same backing data.

Duplicate Management is the Salesforce feature set that detects and prevents duplicate records across standard and custom objects through Matching Rules, Duplicate Rules, Duplicate Jobs, and a logging layer built on the DuplicateRecordSet object. Matching Rules define how the engine compares records, including fuzzy matching, edit distance, and exact field comparisons. Duplicate Rules wire matching rules to user actions and decide what happens when a duplicate is found: block the save, allow with an alert, or allow silently and log for later review. Duplicate Jobs run matching rules against existing data in batch, producing the same logs as real-time rules. The feature is included in every Sales Cloud and Service Cloud edition above Group, and ships with prebuilt rules for Account, Contact, and Lead. Custom objects gain duplicate detection by creating a new Matching Rule and a corresponding Duplicate Rule. Cross-object matching is supported, so a Lead can be checked against existing Contacts and vice versa. The whole framework is configurable through Setup with no Apex required, and the audit logs are queryable through SOQL and reportable through the standard report builder.

A Duplicate Rule is the Salesforce configuration that tells the platform what to do when a user or an API call attempts to create or edit a record that matches an existing one. Each Duplicate Rule references a Matching Rule (which defines the comparison logic) and specifies separate actions for Create and Edit events: Block the save, Allow with alert, or Allow with report. The rule also defines who it applies to, which record types trigger it, and any field-level filter conditions that scope the check. Duplicate Rules sit between Matching Rules and end-user actions. The Matching Rule decides whether two records are similar enough to count as duplicates; the Duplicate Rule decides what happens next. Out of the box, Salesforce ships Duplicate Rules for Account, Contact, and Lead, including cross-object rules that compare Leads to Contacts. Custom objects need a new rule created from scratch. Up to 5 Duplicate Rules can be active per object simultaneously, with rules evaluated in the order shown in Setup.

A DX Project is the source-controlled directory that anchors a Salesforce DX workflow. It contains the metadata for one or more Salesforce orgs as files in a standardized layout: force-app/main/default for source, config for scratch-org definitions, manifest for explicit manifest XML files, and sfdx-project.json at the root for project configuration. The Salesforce CLI (sf) operates on a DX Project: deploy, retrieve, test, and package commands all assume you are inside one. A new DX Project is scaffolded by sf project generate --name MyProject, which creates the directory structure and the project file. From there, you connect to a Salesforce org (the Dev Hub for scratch orgs and any target org for deployment), retrieve initial metadata, commit to Git, and you have a working source-driven Salesforce project. The DX Project is the source of truth that scratch orgs are spun up from, that CI pipelines deploy from, and that managed packages are versioned from.

A Dynamic Dashboard is a Salesforce dashboard that displays data based on the security profile of the user viewing it, not a single fixed running user. Each viewer sees only the records they have access to, gated through their profile, role, sharing rules, and territory assignments. This contrasts with a standard dashboard, which always runs as the same predefined user (the dashboard''s Running User), and so shows the same data to every viewer regardless of permissions. Dynamic Dashboards are how Salesforce supports manager dashboards in role hierarchies: a sales director sees all their team''s deals, while each rep sees only their own. The same dashboard, viewed by different users, shows different data. There are licensing constraints (Enterprise Edition gets 5 Dynamic Dashboards by default; Unlimited gets 10) and the dashboard cannot be scheduled for email refresh, which are the two trade-offs that make Dynamic Dashboards a deliberate choice rather than the default.

Dynamic Forms is a Salesforce Lightning feature that breaks the traditional page layout into individually placeable, conditionally visible fields on a Lightning record page. Where a classic page layout defines a static block of fields shown identically to every user, Dynamic Forms lets admins drop fields anywhere on the page, group them into tabs and accordions, and show or hide them based on field values, user roles, or device type. The feature was the long-awaited successor to traditional page layouts on Lightning. Released for custom objects in 2020 and standard objects (Account, Contact, Opportunity, Case, Lead) starting Winter 2023, Dynamic Forms now covers most of the everyday record-detail experience. It works alongside Dynamic Actions (the parallel feature for record-page actions) and Dynamic Related Lists Single (per-record-page related list filtering) to make Lightning record pages fully configurable through the App Builder. Migration from classic page layouts to Dynamic Forms is a one-way operation; once migrated, the record page becomes the source of truth for field placement.

Dynamic Visualforce Binding is a Visualforce expression syntax that references fields by name at runtime, rather than hardcoded at compile time. Standard Visualforce bindings look like {!Account.Name}; dynamic bindings look like {!Account['Name']} or {!Account[fieldNameVariable]}, where fieldNameVariable is an Apex string. This lets Visualforce pages handle different fields based on user input, custom configuration, or runtime decisions, without needing a separate page per field combination. Dynamic bindings are useful for building flexible UIs: a page that displays whichever Account fields a user has configured in their preferences, a generic record viewer that shows fields appropriate for any object, or a list table that lets users pick which columns to display. The trade-off is type safety: the compiler cannot verify field names that come from runtime variables, so typos or missing fields produce runtime errors instead of compile errors.