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.

A Tag in Salesforce is a user-defined keyword or short phrase that you attach to a record to categorize it and find it again later through tag-based search. There are two kinds. Personal Tags are private to the user who applied them, and Public Tags are visible to everyone in the org once an admin turns the feature on.

A Tag Cloud in Salesforce is a Salesforce Classic display element that shows a user's personal and public tags sized by how often each one is used. The tags that appear most frequently render in a larger font, so a glance at the cloud tells you which labels carry the most records. It surfaces on the Tags page and, when an admin adds it, in the Classic sidebar. This is a user-interface feature of Salesforce Classic tagging, not a cloud-computing product or a separate edition. It is a legacy capability. The tag cloud and the broader Tag Manager interface live only in Salesforce Classic, and newer orgs lean on Topics, list views, and global search for the same find-by-theme need.

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.

Task Bar Links are the quick-access links that sit in the footer, or task bar, of the original Agent Console and the later Salesforce Console in Salesforce Classic. They let a support or sales agent start a common action, most often creating a new record, without leaving the console tab they are already working in. This is a legacy concept. It belongs to the Salesforce Classic console experience, where the footer carried a "New" drop-down and custom footer buttons. In Lightning Experience the same idea lives in the utility bar, a fixed footer you configure on a Lightning console app. New build work should use the utility bar rather than Classic task bar links.

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 the Salesforce feature, and its matching Setup page, that connects Salesforce CRM with Microsoft Teams. Once it is on, people work with Salesforce records directly inside Teams channels and chats. They can mention records in a conversation, pin them as tabs, and view or edit details without leaving the Teams window. The integration is built for organizations that run on Microsoft Teams as their main collaboration tool, the same way the Slack integration serves Slack shops. It is available in Lightning Experience for Enterprise, Performance, Unlimited, and Developer editions with Sales Cloud and Service Cloud. The feature reached general availability in the Summer '21 release.

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.

Test case coverage, usually called Apex code coverage, is a metric that reports the percentage of executable Apex lines run by your unit tests during a test execution. Salesforce tracks it per class and trigger, and also as a single org-wide number. The platform enforces a hard rule. At least 75 percent of your Apex must be covered, and every trigger needs some coverage, before you can deploy to production or package code for AppExchange. The number is a gate for shipping, not a measure of test quality on its own.

A test class in Salesforce is an Apex class written to confirm that your custom code behaves the way you expect. You mark it with the @isTest annotation, populate it with sample data, run the logic under test, and check the results with assertions. It exercises triggers, classes, controllers, and batch jobs without touching real production records. Salesforce treats test classes as a platform requirement, not an optional extra. Before any Apex deploys to production or ships in a managed package, at least 75% of your Apex lines must be covered by passing tests, and every trigger needs some coverage. That rule is why test classes sit at the center of the Salesforce 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.

A Test Drive is an AppExchange feature that lets a prospective customer explore a partner's app inside a shared, preconfigured org, without installing anything. The customer clicks one button on the listing and lands in a read-only demo environment, signed in automatically as an evaluation user. Test Drives sit alongside free trials as a low-commitment way to evaluate a managed package. They show the app in action with realistic sample data, so a buyer can judge the product before talking to sales or installing it in their own org.

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.

A Text field is a Salesforce field data type that stores a single line of alphanumeric content up to 255 characters. It holds short strings such as names, codes, reference numbers, and brief labels, and it is the field type admins reach for first when a value is plain, short, and free-form. In the API and in Apex this type is represented as a string, and it is the data type SOQL compares against by default in WHERE-clause equality checks. A Text field can be configured to enforce unique values, act as an External ID for upsert matching, and treat values as case sensitive. For content that needs more room or multiple lines, Salesforce offers Text Area (255 characters, multi-line), Long Text Area (up to 131,072 characters), and Rich Text Area (HTML-formatted). Choosing Text means choosing a deliberate cap and a single line.

A Text Area is a Salesforce custom field data type that stores multi-line plain text up to 255 characters. The "area" part means the input box is taller than a single-line Text field, so users can press Enter and keep line breaks inside the value. It holds plain characters only, with no bold, colors, or images. Text Area sits in the middle of the text field family. Single-line Text also caps at 255 characters but on one line. Long Text Area and Rich Text Area both go up to 131,072 characters when you raise the limit. You pick Text Area when content is short, may span a few lines, and never needs formatting.

Themes and Branding is a Setup feature in Lightning Experience that lets administrators control the visual appearance of an org. From one page you choose an active theme, and a theme bundles a color palette plus brand images such as a logo and a loading-page image. Those choices flow into the global header, navigation bar, tabs, buttons, and page backgrounds that users see every day. Every org ships with the built-in Lightning Blue theme. You can switch to another built-in option or build a custom theme that carries your company colors and logo. Only one theme is active at a time, and the active theme applies across Lightning Experience for all users in that org.

A time trigger is a setting inside a Salesforce workflow rule that schedules actions to run at a point in time relative to a date or date/time field on the record. You define it in days or hours, before or after that field, such as three days before an opportunity Close Date or one hour after a case is created. When the time arrives and the record still meets the rule criteria, the queued actions fire. Time triggers belong to Workflow Rules, which are legacy automation. Salesforce ended support for Workflow Rules on December 31, 2025. Existing rules and their time triggers keep running, and you can still edit, activate, or deactivate them, but no new fixes are coming. For new time-based automation, Salesforce points you to scheduled paths in record-triggered flows, and offers the Migrate to Flow tool to convert old rules.

A time-dependent workflow action is an automated action inside a Salesforce workflow rule that runs at a future moment instead of firing the instant a record meets the rule's criteria. The action is held in a time-based queue and released when a time trigger reaches its scheduled point, measured as a number of days or hours before or after a date field on the record. Time-dependent actions belong to Workflow Rules, an older automation feature. Salesforce ended support for Workflow Rules on December 31, 2025, so existing rules still run but receive no fixes. New scheduled automation should be built in Flow Builder using scheduled paths, and the Migrate to Flow tool can convert older rules that still carry pending time-based actions.

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.

Top All-Time Ideas is a subtab in the legacy Salesforce Ideas feature that lists ideas ordered by their total point score, from highest to lowest, across the entire life of an Ideas community. Points come from votes, where each promote adds 10 points and each demote removes 10, so the subtab surfaces the suggestions that have collected the most net support since the community opened. It is a lifetime leaderboard, not a trending feed. The ranking ignores when the votes were cast and looks only at the cumulative total, which is why a years-old idea with a large vote bank can sit at the top. Ideas is now classified by Salesforce as a legacy service feature, so newer feedback programs are usually built in Experience Cloud or on a custom object instead.

A Topic in Salesforce is a standard object that acts as a tag or theme for categorizing Chatter posts, Knowledge articles, records, and files across the platform. Each Topic record stores a Name, an optional Description, a NetworkId that ties it to a specific Experience Cloud site when relevant, and a TalkingAbout number that counts how often the Topic has been discussed lately. The Topic object has been available in API version 28.0 and later. Topics connect content that lives on different objects through a single shared vocabulary. Click a Topic and you surface every tagged Chatter post, Knowledge article, Account, Case, or custom record at once, no matter which object each one belongs to. Topics are crowdsourced by default, so any user with the right permission can create or apply one. That makes them good at capturing themes that emerge from real usage, like a recurring product defect or a competitive deal pattern, without waiting on admin setup.

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 choose which languages the Translation Workbench can work in, and assign the translators who produce localized text. From Setup, you enter "Translation Language Settings" in Quick Find, open the page, and add a supported language. Each language you add grows the Workbench a new column for translating custom labels, picklist values, field labels, help text, and other customizations. The page sits behind the Translation Workbench feature, so you enable the Workbench first. It does two jobs in one screen. It controls language availability for translation, and it manages the people allowed to translate. A language stays hidden from translators until you add it here, and a translator cannot edit a language until you assign them to it.

A Translation Workbench is a Salesforce Setup feature that manages translations of customizable text and metadata labels into the languages your org supports. It covers items like custom labels, picklist values, custom field names, record type labels, validation rule error messages, and custom tab names, so users see the application in their own language. It is available only for multi-language orgs, not single-language ones. Once enabled, an admin picks the languages to translate, assigns translators, and those translators enter or override text component by component. Salesforce tracks which entries fall out of date when the source value changes.

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 block of Apex code that runs automatically when records on a Salesforce object are changed through a data manipulation language (DML) event. Those events are insert, update, delete, undelete, merge, and upsert. A trigger is tied to one object, and it can run before the database write, after the write, or both. You write triggers when declarative tools cannot do the job and you need code that fires on every change to a record. Common uses are validating data, updating related records, and calling out to other systems. Triggers run for every save path, whether the record comes from the UI, an import, the API, or another piece of automation.

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 in Salesforce that logs the resource requests a user's browser blocked because of Content Security Policy (CSP) rules, plus redirects that were blocked for leaving a trusted origin. Each row records one unique violation, so admins can see exactly which external script, image, iframe, font, or connection a Lightning Experience page tried to load and the browser refused. The page is a diagnostic surface, not a setting. It tells you what broke and why, then you act on it elsewhere by adding the missing host to Trusted URLs. The list keeps only violations that occurred in the last seven days, and a daily process clears anything older.

A Trusted URL is an entry on the Trusted URLs Setup page that adds an external origin to your org's Content Security Policy (CSP) allowlist. The entry tells the browser that Lightning pages, Aura components, Lightning web components, and (when configured) Visualforce may load specific resource types from that origin, such as scripts, styles, images, fonts, frames, or media. By default, Salesforce sends a strict CSP that only permits content from your own org over HTTPS. Anything from a third-party domain is blocked until you list it here. Trusted URLs was previously called CSP Trusted Sites, and the underlying metadata type is still named CspTrustedSite.

A Trusted URL for Redirects is an entry on the Trusted URLs for External Redirects allowlist in Salesforce Setup. It names an external destination that Salesforce is permitted to send a user to when a link, custom button, or formula field points off the platform. Together these entries form the allowlist that the platform checks before it bounces a user to any outside address. The feature exists to stop open redirect abuse. Without an allowlist, an attacker can craft a link that starts on your trusted Salesforce domain and then forwards the victim to a malicious site. By approving destinations ahead of time, you decide exactly where outbound redirects may go, and Salesforce can warn or stop anything that falls outside the list.