Salesforce terms starting with T

A Tab in Salesforce is the navigational element for an object, a Visualforce page, a Lightning component, or a web tab pointing to an external URL. Tabs appear in the navigation bar of every Lightning App and in the App Launcher's All Items list. Clicking a tab opens the related list view (for object tabs), the configured page (for Visualforce or Lightning tabs), or the external URL (for web tabs). Tabs are the entry point for users browsing a specific object's records or accessing a specific page on the platform. Custom Tabs are admin-defined and used to surface custom objects, custom Visualforce pages, custom Lightning components, and external URLs as first-class navigation entries. Standard Tabs ship with the platform for every standard object (Accounts, Contacts, Cases, Opportunities, Leads, and others). Each tab has a Tab Style (icon and color), visibility settings (per profile), and an inclusion list (which Lightning Apps it appears in). The Tab is the metadata that lets an object or page show up in navigation, distinct from the underlying object or page itself.

Tableau is Salesforce's enterprise business intelligence platform, acquired in 2019 and now positioned as the broader BI tool alongside CRM Analytics (which serves Salesforce-native embedded analytics). Tableau supports building interactive visualizations and dashboards on any data source, deploying them through Tableau Cloud or Tableau Server, and embedding them in Salesforce, custom web apps, or standalone analytical workflows. Tableau is widely deployed across enterprises that need analytics beyond what any single application platform provides. Tableau Desktop is the authoring tool where analysts build worksheets (single visualizations), dashboards (layouts combining worksheets with filters and actions), and stories (curated dashboard sequences). Tableau Cloud and Tableau Server host the published content and handle scheduled refreshes, sharing, and access control. Tableau Prep supports the data preparation workflow before analysis. Salesforce integration patterns include embedded Tableau visualizations in Lightning pages, Tableau pulling data from Salesforce orgs via connectors, and Tableau dashboards exporting to Salesforce records as snapshots. Tableau is licensed separately from base Salesforce; many customers use both Tableau and CRM Analytics for different analytical use cases.

A Tabular Report is the simplest of the four Salesforce report formats. It returns a flat list of records, one record per row, with the fields you selected as columns. Tabular reports look and behave like a spreadsheet view of the filtered data. The format has no grouping logic, no summary calculations, and no row-group totals. Tabular reports are the right choice when the question you are answering is "show me these records" rather than "summarize these records by something." Their simplicity is their value: they are the fastest report format to build, the cheapest to render, and the easiest to export to CSV or Excel.

In Salesforce, a Tag is a user-defined keyword attached to a record to aid personal categorization and search. There are two Tag types: Personal Tags (private to the user who applied them) and Public Tags (visible to everyone in the org). Tags don't enforce values from a picklist - users type any keyword - which makes them flexible for ad-hoc organization but poor for structured reporting. They're commonly used for "read later" bookmarking, personal pipeline marking, and quick record-grouping outside formal picklists.

A Tag Cloud in Salesforce is a visual display element in Salesforce Classic that shows the personal or public tags a user has applied to records. Tags appear in different font sizes based on how frequently they are used, creating a weighted visual representation where the most-used tags appear largest. Tag Clouds help users quickly identify and navigate to commonly tagged records. This is a UI feature within Salesforce Classic's tagging functionality, not a cloud computing product.

A Task in Salesforce is a to-do record: something somebody needs to do for a customer by a specific date. Tasks carry a Subject, an ActivityDate (the due date), a Status (Open, In Progress, Completed, Waiting on someone else, Deferred, by default), a Priority (High, Normal, Low), an OwnerId, and the polymorphic WhoId and WhatId fields that tie the Task to a Lead or Contact and to an Account, Opportunity, Case, or custom object. Tasks are the unit of measurement for sales-rep activity in most Salesforce orgs: a "ten outbound calls per day" target rolls up into ten Task records per rep per day, each one with Type = Call. Task is one half of the Activity abstraction in Salesforce, with Event being the other half. Tasks are async (no fixed time, just a due date); Events are sync (a start time, an end time, optional location and attendees). Both share the same WhoId and WhatId polymorphic lookups and surface together on the Activity Timeline of any related record. Tasks dominate sales rep workflow because most outbound work (calls, emails, follow-ups, contract reviews) is async; Events show up more in service motion (onsite installs, training sessions, customer-success reviews). Most of the Activity reporting in a sales org is Task reporting; Events fill in the gaps.

In the Salesforce Classic console, the links displayed in the footer (task bar) area of the console that provide quick access to common actions like new record creation without leaving the current workspace.

Tasks is both a Setup area where administrators configure the behavior of task records across the org and the standard Task object itself that captures to-do items, follow-ups, calls, emails, and other activities the team needs to track. The Setup-side configuration controls how tasks behave at the platform level: default notification settings when a task is assigned, what happens when a task is completed, archival rules for old tasks, and the visibility of completed-versus-open tasks across record-detail pages. The Task object is one of the most heavily used standard objects in Salesforce because it is the canonical place to record any action a user takes related to a Lead, Contact, Account, Opportunity, Case, or any other record. Logged calls become Task records. Sent emails become Task records (alongside their Email Message counterparts). Manually entered to-dos become Task records. The combination of Setup configuration plus Task object behavior shapes how the entire org tracks activity and follow-up, which makes it a foundational element of sales productivity, service responsiveness, and operational analytics.

Teams Integration is a Setup page for configuring the integration between Salesforce and Microsoft Teams. It enables features like Salesforce record sharing in Teams channels, CRM data access from the Teams interface, and meeting notifications synced between the two platforms.

A Tenant Secret in Salesforce Shield Platform Encryption is an org-specific cryptographic secret that the customer controls, used together with the Salesforce-managed master secret to derive the data encryption keys that protect sensitive fields, files, and search index entries in the org. The two-secret design (Salesforce master plus customer Tenant Secret) means neither side can decrypt the org data alone; the encryption keys exist only at runtime when both secrets combine. Customers rotate the Tenant Secret on a schedule they control, which forces key rotation across the org without re-encrypting data in place. Tenant Secrets are the centerpiece of the customer-managed encryption story for Salesforce Shield. The platform generates the initial Tenant Secret automatically when Shield Encryption is enabled; customers can rotate to a new Tenant Secret through Setup, Platform Encryption, Key Management. Each Tenant Secret has a status (Active, Archived, Destroyed) and a use case (Data, Search Index, Analytics, etc.). Archived secrets can still decrypt data they previously encrypted; Destroyed secrets cannot. Mature security operations rotate Tenant Secrets quarterly and audit the rotation history annually.

A Territory in Salesforce is a node in the Enterprise Territory Management hierarchy: a named container with assigned users, assigned accounts, child territories, and rules that decide which accounts belong inside. Territories define the structure of a sales organization (Regions, Industries, Strategic Accounts, Channels) and grant the assigned users access to the accounts the territory contains. The hierarchy supports up to 1,000 territories per model and 5 levels deep, with parent territories rolling up the access of their children. Territories are the unit of organization in Enterprise Territory Management (ETM), the modern replacement for the legacy Customizable Territory Management feature. A Territory belongs to a Territory Model (the version of the entire tree, in Active, Planning, or Archived state). Multiple models can coexist in Planning state for planning purposes, with one designated Active at any time. Activation pushes the Territory's account assignments and user access into the live sharing layer, granting the assigned users access to the accounts immediately and at scale.

Territory Planning in Salesforce is the process of designing, modeling, and optimizing the sales territories that determine which reps cover which accounts, prospects, and geographic regions. Salesforce supports this through two product layers: Enterprise Territory Management (the platform feature that assigns Account ownership to Territory records, drives sharing rules, and routes new records) and Salesforce Maps Territory Planning (the advanced add-on for visualizing territories on a map, modeling balancing scenarios, and applying geographic and demographic data). Mature Territory Planning combines both layers. Enterprise Territory Management defines the live operational territory structure that governs day-to-day Account ownership. Salesforce Maps adds the planning tools that let revenue operations teams model new territory structures, balance workload across reps, account for travel time and geography, and stage changes before activating them in production. Territory Planning happens annually for most orgs and quarterly for fast-growing or seasonal businesses; it is one of the most consequential annual activities for any Salesforce sales operation.

In Salesforce Apex development, a metric that shows which Apex classes and triggers are covered by unit tests and which lines of code are exercised during test execution, with a 75% minimum org-wide coverage required for deployment.

A Test Class in Salesforce is an Apex class written specifically to verify that custom code - including triggers, classes, and controllers - works correctly under various conditions. Salesforce requires a minimum of 75% code coverage from test classes before any Apex code can be deployed to a production environment, making them a mandatory part of the development lifecycle.

Test Deliverability is a Salesforce Setup utility that sends a test email from the org to a specified address to verify that outbound email delivery is working correctly. The tool sits under Setup, then Email, then Test Deliverability, and produces a diagnostic email covering all the email service categories the platform supports: System Email, User Email, Email Alerts, and Mass Email. Each recipient address receives one email per category, and the admin can confirm receipt to verify the delivery path. The utility is the right first stop for diagnosing email deliverability problems. When users report that automated emails are not arriving, Test Deliverability quickly confirms whether the issue is on the Salesforce side (no email leaving the platform), on the recipient side (delivered but not arriving in the inbox), or somewhere in between. The diagnostic is fast (the test emails arrive within minutes if delivery is working) and inexpensive (it consumes a small amount of the org's daily email allocation). For any email-related support investigation, running Test Deliverability is the standard first action.

In Salesforce AppExchange, a feature that allows potential customers to try a managed package in a pre-configured trial org to evaluate its functionality before purchasing, providing a hands-on preview.

A Test Method in Salesforce Apex is a method annotated with @isTest that verifies the behavior of production Apex code. Each test method sets up the data the test needs, executes the operation under test, and uses System.assert methods (Assert.areEqual, Assert.isTrue, Assert.fail) to confirm the result matches expectations. Test methods live inside test classes, which themselves carry the @isTest annotation at the class level. The Salesforce platform requires at least 75 percent code coverage across all triggers and most Apex classes before any deployment to production, which makes test methods a mandatory part of every Salesforce development workflow. Test methods run in a special test execution context that isolates them from the rest of the org. The platform inserts the test data, runs the test, and rolls back every record change at the end so the test does not pollute production data. This isolation lets developers run thousands of test methods without worrying about side effects, and lets CI pipelines run the full test suite on every commit.

A Test Organization in Salesforce is a non-production Salesforce org used for development, QA, UAT, training, or any other activity where changes need to be validated before reaching the live production org. The term covers several specific types: Developer Sandboxes, Developer Pro Sandboxes, Partial Copy Sandboxes, Full Sandboxes, and Scratch Orgs. Each type has different storage limits, data refresh behavior, and intended use case. The platform treats every Test Organization as a separate Salesforce org with its own org id, data, and metadata, isolated from production. Metadata and (depending on the type) data flow from production into the Test Organization through sandbox creation or refresh. Changes made in the Test Organization flow back to production through change sets, Salesforce DX deploy, ANT migration, or another deployment tool, never automatically.

Text is a Salesforce field data type that stores a single line of alphanumeric content up to 255 characters. It's the most common field type for short strings - names, codes, brief descriptions, external IDs - and the SOQL WHERE-clause default for equality comparisons. Text fields support unique constraints, case-sensitivity rules, default values, and can be set as External ID for upsert operations. For longer content Salesforce offers Text Area (255 chars, multi-line), Long Text Area (up to 131,072 chars), and Rich Text Area (HTML-formatted).

A Salesforce field data type that stores multi-line plain text up to 255 characters, suitable for short descriptions or notes that may need line breaks but don't require the larger Long Text Area capacity.

Themes and Branding is a Setup page where administrators customize the visual appearance of Lightning Experience, including the org's logo, brand color, loading page background, and default banner image. These settings help organizations align the Salesforce interface with their corporate brand identity.

In Salesforce workflow rules and processes, a time-based trigger that schedules workflow actions to execute at a specified time before or after a date field value on the record (like 3 days before Close Date).

In Salesforce workflow rules, an automated action (field update, email alert, task, outbound message) scheduled to execute at a future time relative to a date field, queued by a time trigger rather than firing immediately.

A Timeout in Salesforce is the maximum time allowed for a transaction, callout, query, or session to complete before the platform terminates it. Salesforce enforces timeouts at multiple layers: synchronous Apex execution (10 seconds CPU time, longer for async), HTTP callouts (60 seconds per callout, configurable down to 1 second), SOQL queries (120 seconds for the platform to return results), user sessions (configurable from 15 minutes to 24 hours), API session lifetime (8 hours default), and Salesforce Connect external object queries (120 seconds). Hitting a timeout terminates the operation and returns a timeout exception to the caller; the partial work is typically rolled back to keep the platform consistent. Timeouts exist to protect the multi-tenant platform from runaway processes that would consume shared resources at the expense of other customers. They are not platform bugs to work around but design constraints to design with: write Apex that completes within governor-limit windows, build integrations that respect callout limits, and architect workflows that fit within session lifetime expectations. Hitting timeouts in production usually means the workload exceeded what the chosen execution context supports.

Token Exchange Handlers is the Salesforce Setup page for registering and managing Apex classes that implement custom OAuth 2.0 token exchange flows. The classes plug into Salesforce's identity layer at the moment a token from one identity provider needs to be converted into a Salesforce session or a token for another system, executing custom logic for validation, claims mapping, and session establishment. The feature implements the OAuth 2.0 Token Exchange specification (RFC 8693), which standardizes how a client can exchange one token for another in scenarios like cross-organization SSO, agent-to-agent delegation, machine-to-machine federation, and identity propagation across cloud boundaries. The handler classes implement the Auth.TokenExchangeHandler interface and define what happens when Salesforce receives a token exchange request: validate the incoming token, map claims to a Salesforce user, mint the response token, and return it to the caller.

Tools is the umbrella section in Salesforce Setup that consolidates developer and administrator utilities for building, deploying, debugging, and monitoring customizations. The section is not a single page but rather a category that groups together the Developer Console, the Apex Test Execution view, the Debug Log Setup, Email Logs, the Deployment Status page, Change Sets, the Workbench-style API tools, and the various tooling pages for working with metadata and runtime behavior. The Tools section exists in two forms across the platform: the Classic Setup tree had a clearly labeled Tools section under Develop, while Lightning Setup has dispersed the same utilities across multiple search-accessible pages. Most experienced admins and developers now reach these utilities through the Setup Quick Find search rather than by navigating a Tools menu, but the conceptual grouping is still useful when discussing or documenting what tooling the platform exposes.

In Salesforce Ideas, a list view that ranks ideas by the highest cumulative vote count since the Ideas community was launched, surfacing the most popular feature requests or suggestions of all time.

A Topic in Salesforce is a standard object that represents a tag or theme used to categorize Chatter posts, Knowledge articles, records, files, and other content across the platform. Each Topic record holds a Name, an optional Description, and a TalkingAbout counter that tracks how often the Topic has been discussed recently. Topics are linked to specific items through the TopicAssignment junction object, which records which Chatter post, article, or record was tagged with which Topic. This shared tagging vocabulary lets users surface related content across object boundaries - clicking a Topic surfaces every Chatter post, knowledge article, and record tagged with it, regardless of their underlying objects. Topics are crowdsourced by default: any user can apply or create Topics, which makes them useful for capturing emergent themes (a product issue, a competitive scenario, a regional event) without requiring admin configuration. Topics also drive Experience Cloud navigation, where Topic pages serve as landing destinations for community content organized around themes rather than objects.

Topics in Salesforce are tag records that group related content (Chatter posts, files, Knowledge articles, and records on most standard and custom objects) under a shared label so users can find and follow conversations and information that share a theme. A Topic record stores the name, a description, optional related topics, and the list of objects it has been applied to. The feature spans Chatter (Topics on posts and groups), Knowledge (Topics on articles), Files (Topics on uploads), and standard objects through the Topics for Objects switch. Each application of a Topic to a record creates a TopicAssignment junction record, which is the underlying data model that drives Topic feeds, related-topic recommendations, and topic-based reporting.

A Trail in Salesforce Trailhead is a curated learning path made up of multiple modules and projects that together teach a coherent topic: Admin Beginner, Developer Intermediate, Sales Cloud Consultant Cert Prep, and so on. Each Trail sequences the underlying modules in study order, so a learner working through it covers prerequisite concepts before moving on to advanced ones, and finishes with a clear sense of mastery on the topic. Trails are the top level of the Trailhead content hierarchy. A Module groups three to seven Units (atomic lessons) into a self-contained subject; a Trail strings together five to fifteen modules around a role, a certification, or a broader theme. Trails are how Salesforce packages its educational content for career growth and exam prep. Most certification study plans on the platform start with a recommended Trail, and most new-hire onboarding programs at Salesforce ecosystem companies build on Trailhead Trails as the curriculum.

Trailhead is the free, gamified learning platform Salesforce launched in 2014 to teach the platform to admins, developers, architects, and business users. The content is organized as Modules (single-topic units, typically 30 to 60 minutes), Trails (curated sequences of modules), Superbadges (project-based challenges with real-world scenarios), and Projects (guided builds in a sandbox). Learners earn Points and Badges that accumulate on a public profile, with Ranks (Hiker, Adventurer, Mountaineer, Expeditioner, Ranger, Double Ranger, and beyond) marking lifetime progress. Trailhead is also the primary preparation path for Salesforce certifications. Every official certification has a recommended Trail, with module sequences mapped to the exam outline. Hiring managers ask candidates for their Trailhead profile URL the way they ask developers for GitHub. The platform has trained a generation of Salesforce talent, and the public profile has become the de facto resume for Salesforce career changers. Trailhead also extends beyond Salesforce-specific content with Trailhead Academy (instructor-led training), myTrailhead (white-label corporate learning), and Trailhead for Students (university-level curriculum).

A Trailhead Playground is a free, persistent Salesforce Developer Edition org tied to a Trailhead profile and used for hands-on challenges, free-form practice, and personal projects. Each Trailhead learner can have up to ten Playgrounds. The Playgrounds are full Developer Edition orgs with the standard 5 MB of data storage, 20 MB of file storage, and the same feature set as any other Developer Edition. They are intentionally disposable: learners can spin them up, build whatever they need, and discard or replace them without consequence. Trailhead Playgrounds are the hands-on layer of Trailhead. Every module that requires the learner to "create a custom object" or "write an Apex class" runs against a Playground. The challenge engine connects to the Playground through the Salesforce Tooling API, queries the metadata, and validates the learner's work against the expected state. The integration is what turns Trailhead from a reading-and-quiz platform into an apprenticeship-style learning environment. Playgrounds are also useful beyond Trailhead: trying a feature, prototyping a custom app, exploring a managed package install.

Training data is the labeled or unlabeled content a machine learning model learns from during training. For a generative AI model, training data is the corpus of text the model reads to learn patterns of language and reasoning. For a predictive AI model in Salesforce (Einstein Lead Scoring, Einstein Case Classification, Opportunity Scoring), training data is the set of historical records the model uses to learn the relationship between input features and the outcome being predicted. The shape and quality of training data determine what the model can do at inference time. Garbage history produces a confident garbage scorer. In Salesforce, training data lives in two distinct worlds. Foundation models behind Einstein Generative AI are trained on public and licensed corpora outside the customer's org. The customer never sees or controls this layer; it is the platform's responsibility. Predictive Einstein features train on the customer's own historical records (closed-won opportunities, resolved cases, completed tasks) and that data must meet volume, freshness, and label balance thresholds before the model can be built. The thresholds are not advisory. Predictive Einstein refuses to build a model when the data does not pass them.

A training phrase is one literal example of a user message that should be classified as a specific intent in Salesforce Einstein Bots or the legacy Einstein Intent Service. Authors write 20 to 100 training phrases per intent, the underlying NLP model learns the cluster of phrases that map to each intent, and at runtime the model classifies new messages by finding the closest cluster. Training phrases are the raw material the model learns from; the variety and realism of the phrases determines how well the bot generalizes to messages it has never seen. Training phrases are the most consequential authoring decision in any traditional bot. The bot can only classify messages similar to its training. A model trained on twenty near-identical phrases matches only near-identical messages in production and frustrates users who phrase things naturally. A model trained on thirty to fifty varied phrases across length, vocabulary, and grammar handles real user variation. Pulling phrases from real conversation logs (email-to-case subject lines, web form submissions, prior chat transcripts) beats inventing phrases every time, because real phrasing contains the slang, typos, and incomplete sentences the bot will actually see.

Transaction Security is the Salesforce policy framework that monitors real-time user activity, detects suspicious patterns, and takes automated action: block the action, require multi-factor authentication, end the session, or notify an admin. Policies are configured in Setup, Security, Transaction Security Policies, and they evaluate against streaming Event Monitoring data, including login events, report exports, API queries, list view exports, and credential changes. The policy framework is the action layer that sits on top of the observability layer. Transaction Security is part of the Shield product family but the Enhanced Transaction Security version (rebuilt in 2020) is included with Salesforce Shield. The older Transaction Security 1.0 used Apex implementing the TxnSecurity.PolicyCondition interface. The new Enhanced Transaction Security uses Condition Builder, a declarative editor that lets admins build policies without code. Both versions coexist for backward compatibility but the new policies replace the old ones for all new use cases. Policies fire in milliseconds against the streaming event stream and can block actions before the data leaves the platform.

An Apex Transaction is the single unit of work the Salesforce platform tracks from the moment Apex starts executing in response to a request (a record save, an inbound API call, a scheduled job, a flow action) until that request returns to the caller. Every governor limit in Apex (SOQL queries, DML rows, CPU time, heap size, callouts, future jobs) is enforced per transaction; when the transaction ends, the counters reset. A transaction either commits or rolls back as a single atomic unit. If any uncaught exception escapes the Apex code, every DML operation in the transaction is rolled back automatically. If the code reaches the end without an uncaught exception, the platform commits all DML at once. Developers can also place explicit Savepoints inside a transaction and roll back to a savepoint without aborting the whole call, which is the only way to do partial rollback in Apex.

A Checkout Transaction in Salesforce B2B Commerce is the financial event that runs when a buyer submits a cart for purchase. It wraps payment authorization, order creation, order summary generation, and the confirmation handoff back to the storefront, and treats the full sequence as one logical unit even though several subsystems take part. The term covers both the runtime sequence that a Checkout Flow executes when a buyer clicks Place Order and the underlying records that get written, including CartCheckoutSession, Order, OrderItemSummary, and any Payment or PaymentAuthorization rows the configured gateway returns. A Checkout Transaction is considered complete only when the Order record has been created and the buyer has received an order confirmation. Until then, the buyer can recover the cart and retry without losing progress.

Translation Language Settings is a Setup page where administrators manage the languages available for translation in the Translation Workbench. It allows admins to enable specific languages for translating custom labels, picklist values, help text, and other translatable metadata components in the org.

A Salesforce setup tool that manages the translation of custom labels, picklist values, field names, page layouts, and other customizable text into multiple languages for organizations with multilingual users.

Trending Topics in Salesforce Chatter is a feature that surfaces the hashtag topics currently receiving the most posts and engagement across the organization. The list updates as activity changes, so it acts as a real-time pulse of what employees are talking about right now rather than an all-time popularity ranking. The feature sits on the Chatter overview page and on topic detail pages, and it ranks topics by a weighted score of recent posts, replies, likes, and views. Clicking a trending topic opens a feed of every post and comment tagged with that topic across the org, regardless of which group or record the conversation started on.

An Apex Trigger is a piece of Apex code that executes before or after data manipulation language (DML) events on Salesforce records, such as insert, update, delete, merge, upsert, and undelete. Triggers allow developers to perform custom actions when records are modified, such as validating data, updating related records, or calling external services.

A Trigger Context Variable is one of a set of implicit static variables that Apex provides inside a trigger to describe the event being processed. They tell the trigger what is happening (insert, update, delete, undelete), when it is happening (before or after the database commit), and which records are involved. The full set covers seven boolean flags for the event type and four collections for the affected records. The flags are isInsert, isUpdate, isDelete, isUndelete, isBefore, isAfter, and isExecuting. The collections are Trigger.new, Trigger.newMap, Trigger.old, and Trigger.oldMap. Every trigger has access to these variables for free; you do not declare them, and you cannot reassign them.

Truncate in Salesforce is the action of permanently removing every record from a custom object while preserving the object metadata (fields, validation rules, layouts, relationships, sharing rules). The operation is faster than a bulk delete because it skips the recycle bin, skips record-level sharing recalculation, and skips fire-by-fire trigger execution. It is the right answer when an admin wants to reset a custom object back to empty without rebuilding the object definition. Truncate is available only for custom objects and only when the object has no related lists, no analytics snapshots tied to it, no remote sites that depend on it, and a few other constraints. Standard objects (Account, Contact, Opportunity, Lead, Case) cannot be truncated through the Salesforce UI; the only way to empty them is record-by-record delete or a mass delete with Data Loader. The feature is intentionally limited because the consequences are irreversible.

Trusted URL and Browser Policy Violations is a Setup page that logs instances where browsers blocked content due to Content Security Policy (CSP) violations. It helps administrators identify and resolve issues where custom JavaScript, iframes, or external resources are being blocked by the browser's security policies.

Trusted URLs is a Setup page where administrators add external URLs to the Content Security Policy (CSP) allowlist, permitting Salesforce Lightning pages to load scripts, styles, images, and frames from those domains. Without an allowlist entry, browsers block external content for security reasons.

Trusted URLs for Redirects is a Setup page where administrators specify external URLs that Salesforce is allowed to redirect users to. This prevents open redirect vulnerabilities by ensuring that users can only be redirected to pre-approved domains from Salesforce pages and custom links.