Salesforce terms starting with F

In Salesforce, a Facet is a reusable UI building block that injects content into a named region of a parent component. Its most common form is the Visualforce tag apex:facet, which places markup inside slots like the header, footer, or caption of data components such as apex:dataTable, apex:pageBlockTable, or apex:column. The named-region pattern lets parent components declare extension points without knowing what content the developer will provide. The term also appears in Experience Cloud, Einstein Search, and Salesforce CMS, where a facet is a filter panel that lets users narrow a list or search result by category, record type, or custom field value. The two meanings are conceptually related (a facet is a slot or filter that focuses content) but operationally distinct: Visualforce facets are markup constructs, search facets are user-facing filter controls. Context tells you which is meant.

A Feature License in Salesforce is a per-user license that grants access to a specific feature beyond the user's base Salesforce license. Where a base license (Salesforce, Salesforce Platform, Customer Community) defines the overall product the user is authorized to use, a feature license adds discrete capabilities on top: Marketing User, Service Cloud User, Knowledge User, Sales Cloud User, Mobile User, Live Agent User, CRM Content User, and similar named features. Each feature license has a separate allocation count, and assigning one to a user consumes one unit from that allocation. Feature licenses are visible on the User record as checkboxes (or a more complex feature-license related list, depending on the license type) and on the org's Company Information page as a list of all feature licenses with used and available counts. They sit between base licenses and permission sets in the Salesforce licensing model: a feature license unlocks the platform-level capability, and permission sets or profiles then grant the user-level permissions to use specific objects, fields, and Apex classes within that capability.

A Feed Attachment in Chatter is a file or content item attached to a Chatter post (FeedItem). When a user posts a feed update with a file uploaded inline or a Content Document referenced, the platform creates a FeedAttachment record linking the FeedItem to the underlying file. Feed Attachments are how files appear inline in feed posts in Salesforce, Experience Cloud sites, and the mobile app. The Feed Attachment is a junction record between FeedItem and ContentDocument (or Attachment in older orgs). One FeedItem can have multiple Feed Attachments; each attaches a different file. The FeedAttachment object exposes the title, type (Content, Link, Image), and the link to the underlying file''s storage location. Reports on FeedAttachment count attachments per feed post, attachments per user, and attachment volume per channel.

A Feed Filter in Chatter is a per-user UI filter that narrows what posts appear in the Chatter feed view. Standard filters include All Updates, To Me (posts mentioning the user), Bookmarked, Most Recent, and feed-specific filters on individual record pages. Custom filters can be configured by admins to surface specific post types, post authors, or related-record contexts. Feed Filters are a UI convenience, not a security control. They do not change what records the user can see; they just hide posts that would otherwise appear in the feed. The user can switch filters at any time to see different views of the same underlying feed data. Feed Filters live in the feed component''s dropdown menu in Lightning Experience and in similar dropdowns in Classic and the mobile app.

A Feed Item in Salesforce is a single Chatter feed post stored on the FeedItem object. Each FeedItem represents one entry in someone''s feed: a status update, a record-change post (StageChanged on an Opportunity, OwnerChange on an Account), a question, a poll, or a file share. The object holds the post body, the author (CreatedById), the parent record the post relates to (ParentId), the post type (TextPost, ContentPost, LinkPost, PollPost), and metadata like LikeCount, CommentCount, and IsDeleted. FeedItems are the central record type in Chatter. They appear in feeds across the platform: the Chatter Home page, record pages, Group pages, and Experience Cloud sites. The FeedItem table can grow large in active orgs (millions of records is normal in mature orgs with engaged communities). Reports against FeedItem drive engagement analytics: posts per user, posts per topic, sentiment over time, top performers.

Feed Tracking is the Salesforce Setup feature that controls which fields on which objects generate Chatter feed posts when they change. When a tracked field on a record is updated, the platform automatically writes a feed item visible on the record's Chatter feed and to anyone following the record. The feature is the engine behind the collaboration capability of Chatter: rather than relying on manual posts, the system surfaces every important change as a feed event, so anyone following the record sees the activity history. Field-level granularity is the point. Administrators enable Feed Tracking on the object in Setup, then check each field that should produce feed events on change. A typical configuration tracks Stage on Opportunity, Status on Case, and Owner on Account, while leaving high-churn fields (LastActivityDate, system audit fields) untracked to avoid feed noise. The setting is org-wide per object; once a field is tracked, every record of that type produces a feed item when the field changes.

A Field in Salesforce is a single column on an object: one piece of data captured per record. Account.Name, Contact.Email, Opportunity.Amount, Case.Status are all fields. Fields have a data type (Text, Number, Date, Picklist, Lookup, Formula, and so on) that determines what values they accept and how they behave in queries, formulas, and the UI. Each field has an API name (used in code) and a label (shown to users), plus metadata for length, help text, default value, and required flag. Fields are the smallest unit of customization on the platform. Salesforce ships standard fields for every standard object (Industry on Account, Title on Contact, StageName on Opportunity). Admins add custom fields to track org-specific data, marked with the __c suffix on the API name. The platform supports roughly 18 field types and dozens of variants; the choice of field type determines what features the field unlocks (a Picklist gets a dropdown, a Lookup gets reference behavior, a Formula is computed at read time).

Field Accessibility is the Salesforce Setup view that shows, for any given field on any object, exactly which users can see it and edit it based on the combination of profile, permission set, record type, and page layout assignments. The page presents a single field's effective access across every profile and record type in the org as a color-coded matrix, exposing the often-confusing interaction of field-level security with page layouts. It is the canonical answer to "why can't this user edit this field?" and the fastest path to verifying that a configuration change produced the intended permission outcome. The view does not change permissions; it only reports the current state. Administrators use it to diagnose access issues raised by end users and to audit field exposure before releasing a new field or record type. The matrix accounts for the layered model: field-level security (FLS) on the profile or permission set, the page layout's read-only or required setting, and any record-type-specific page layout assignment. The combination of these layers produces the user's effective access, which is what Field Accessibility surfaces.

A Field Dependency in Salesforce is a configuration that ties one picklist field''s available values to another picklist''s currently selected value. The controlling picklist determines which values appear in the dependent picklist. A classic example: Lead Source as the controlling field (Web, Phone, Trade Show) drives Lead Subtype as the dependent field (Web restricts to Form, Email, Chat; Phone restricts to Inbound, Outbound; Trade Show restricts to Booth, Demo, Networking). Field Dependencies are Salesforce''s declarative way to encode if-then logic into picklist UX. Without them, every dependent value would appear regardless of context, and users would pick inappropriate combinations (Trade Show + Form). With them, the platform enforces the relationship: the dependent picklist''s options change as the controlling value changes. The dependency lives as metadata, not as a separate validation rule; it deploys with the picklist fields themselves.

Field History Tracking is the Salesforce feature that records changes to specific fields on an object into a durable audit log. When a tracked field changes, the platform writes a History record (AccountHistory, ContactHistory, OpportunityHistory, etc.) capturing the old value, the new value, the user who made the change, and the timestamp. The log is the canonical answer to "who changed what when" for audit, compliance, and dispute resolution purposes, and it persists independently of the source record. Up to 20 fields can be tracked per object. The retention is 18 months by default, with Field Audit Trail (a Shield add-on) extending retention up to 10 years. The history records are queryable through SOQL and reportable through standard report types, but they are not editable: once written, a history row cannot be modified or deleted except by the platform during retention expiration. This immutability is the property that makes the log trustworthy for compliance.

Field Service is the current name of Salesforce's product for managing field operations, dispatching mobile workers, scheduling appointments, and tracking work orders. Salesforce dropped the "Lightning" qualifier from the product name as part of broader product-naming cleanup, so Field Service and Field Service Lightning refer to the same product. The current marketing uses Field Service; older documentation and the deeply-installed community shorthand still use Field Service Lightning or FSL. The product covers the same scope under either name: Work Orders, Service Appointments, Service Resources, Service Territories, the Dispatcher Console, and the dedicated Field Service Mobile App. It is Salesforce's primary product for field operations across industries like utilities, telecommunications, home services, manufacturing field operations, and any business that dispatches technicians or crews to customer sites. Field Service is licensed separately from Service Cloud, sold to enterprises running service operations that need scheduling, dispatch, mobile workflows, and inventory tracking beyond what Service Cloud Cases alone can provide.

The Field Service Mobile App Builder is a Setup-based configurator for the Salesforce Field Service mobile app that technicians use on iOS and Android. The builder lets admins customize what each technician sees: which record screens, which fields, which actions, which Lightning components, which offline behaviors. The configuration deploys to the mobile app and changes the technician experience immediately on next sync. Branded buttons, custom forms, photo capture flows, signature workflows, and inventory lookups are all configured here. Field Service Mobile App Builder sits in Setup, then Field Service Mobile, then App Configuration. It is the technician-facing counterpart to Field Service Settings (which configures dispatchers, work orders, scheduling). The mobile app uses Lightning Web Components for its UI surface; Mobile App Builder lets admins place, configure, and conditionally show components per technician profile or service territory.

Field Service Mobile Settings is the Salesforce Setup page that controls org-level configuration for the Field Service mobile app: which technicians can use the app, how the app handles offline data, what authentication is required, and what global behaviors apply across every technician''s mobile experience. It sits in Setup, then Field Service Mobile Settings, alongside the more granular App Configurations that drive per-screen layouts. Field Service Mobile Settings is the org''s policy layer for mobile. While the Field Service Mobile App Builder configures what individual screens look like, Mobile Settings defines who can log in, how often the app syncs, what authentication ceremony is required, whether the app respects MFA, and how offline cache is managed. The two pages work together: Settings sets the rails; App Configurations style the train.

Field Service Settings is the Salesforce Setup page that controls the dispatcher-side configuration of the Field Service product. It is where admins enable Field Service, configure default scheduling policies, define optimization rules, manage service territories, set up status flows, and configure the Dispatcher Console. While Field Service Mobile Settings handles the technician side, Field Service Settings handles everything dispatchers, schedulers, and back-office teams see. Field Service Settings sits in Setup, then Field Service Settings. The page is the canonical configuration surface for the Field Service add-on; without it enabled, no Field Service objects (Work Order, Service Appointment, Service Resource) function. Beyond enablement, the page exposes hundreds of options across scheduling, optimization, work order management, service report generation, and integration with related Salesforce features (Knowledge, Surveys, Surveys Insights).

A Field Set is a grouping of object fields that Salesforce admins define once and reference from Visualforce pages, Lightning Web Components, or managed-package code. The field set lists which fields to display in the consuming code, in what order, and which are required versus optional. Developers reference the field set by name; the rendered output dynamically pulls the current field list. If an admin adds or removes a field in the field set, every page or component referencing it updates without code changes. Field Sets are most useful in managed packages and dynamic forms where the customer should be able to customize which fields appear in a developer-built component without editing source code. The classic use case is a Visualforce page (Edit My Profile) that uses a field set named PersonalInfo; the developer ships the page once, and customers add their custom fields to the PersonalInfo field set to extend the form. Field Sets are configured per-object under Object Manager. They are a niche feature that solves a specific problem well but does not replace standard page layouts or dynamic forms for general-purpose record layouts.

A Field Update is a Workflow action that automatically sets a specific field on a record to a defined value when the workflow rule fires. The action is one of four classic Workflow action types (Field Update, Email Alert, Task, Outbound Message), and historically was the foundation for declarative data automation in Salesforce. Field Updates can set the field to a literal value, a formula result, or clear it entirely. They run before or after the record save depending on configuration, with implications for downstream automation. The action is functionally available in modern Salesforce but mostly retired in favor of Flow. Workflow Rules and their Field Update actions were officially deprecated in 2022, with Salesforce announcing the path forward as Flow Builder. Existing Workflow Rules continue to run, but new automation should be built in Flow. Understanding Field Update still matters because thousands of legacy orgs run on Workflow, and migration to Flow requires reproducing Field Update behavior in Flow Update Records elements.

Field-Level Help is the Salesforce feature that displays a hover tooltip next to a field on a record page, explaining what the field means or how to fill it in. The text is configured per field in Setup and appears as a small information icon beside the field label; users hover the icon to see the help text. The feature is one of the simplest forms of in-product documentation, requiring no formatting, no permissions, and no separate help system. The intent is to reduce the gap between Setup metadata and user understanding. A field named Net Revenue might mean different things to different users; the field-level help removes ambiguity by giving the official definition right where the user enters the data. The feature applies to custom fields and a subset of standard fields, with the help text stored as part of the field metadata and deployed through changesets like any other field property.

Field-Level Security in Salesforce is the per-field Read and Edit permission that decides whether a user can see and change a specific field on a specific object. FLS is configured per Profile and per Permission Set, and it operates independently of the object-level CRUD permissions that decide whether a user can access the record at all. A user with full Read access to Opportunity but no FLS on the Amount field sees an Opportunity record with the Amount field blank or hidden, even when the field actually contains a value. Field-Level Security is the granular layer that makes Salesforce usable for compliance-regulated organizations. Most data-protection regimes (GDPR, HIPAA, PCI-DSS, financial-services regulations) require that sensitive fields be hidden from users who do not need them, even when those users can access the record. Without FLS, every user with object access would see every field on every record, which is incompatible with any meaningful data-protection program. FLS lets you grant access to the Opportunity but hide the AnnualRevenue field, grant access to the Patient record but hide the Diagnosis field, grant access to the User record but hide the Compensation field. The behavior is silent by design.

A File in Salesforce is a document, image, PDF, video, or other binary artifact stored on the platform. Files are the modern file-storage primitive (replacing the legacy Attachment model since around 2014), backed by the ContentDocument and ContentVersion objects in the API. Every File has versioning support, sharing controls, preview generation, and metadata: title, description, type, size, owner. Users upload files through the Files tab, drag-drop on record pages, the Chatter composer, the mobile app, or external integrations. Files are how Salesforce stores and surfaces documents alongside records. A Sales contract attached to an Opportunity, a Case-resolution PDF, an internal training video, a campaign creative asset, all live as Files. The platform supports preview rendering for common formats (PDF, Word, Excel, PowerPoint, images), full-text search of supported file types, and granular sharing through File Collaborators, File Viewers, File Owners, and library-based access control.

A File Collaborator in Salesforce is a user or group granted read-and-edit access to a Salesforce File. Collaborators can view, download, comment on, and upload new versions of the file. They cannot delete the file or change its sharing settings; those rights belong to the File Owner. Collaborator is the middle tier of Salesforce file sharing, sitting between Viewer (read-only) and Owner (full control). File Collaborators are configured through the ContentDocumentLink object''s ShareType field (value: C for Collaborator). The link record connects a Salesforce File to a User, Group, Record, or Library, with the ShareType controlling permission level. Most production file-sharing flows assign Collaborator access to internal users who need to participate in document iteration, while customers and partners get Viewer access for read-only review.

A File Owner in Salesforce is the user with full control over a Salesforce File: ability to edit, delete, transfer, and re-share. By default, the File Owner is the user who uploaded the File; ownership can be transferred to another user through the file detail page or programmatically through the OwnerId field on ContentDocument. The File Owner has rights that no other user, regardless of sharing, can override. File Owner is the top tier of Salesforce file sharing, above File Collaborator (read+edit) and File Viewer (read-only). It corresponds to ShareType I on the ContentDocumentLink. Most files have exactly one Owner, though multiple users can be linked with ShareType I if business needs require shared ownership. File Owner status survives deactivation in most cases; ownership transfer is a deliberate action that must happen before the owner leaves the org.

File Upload and Download Security is the Salesforce Setup page that controls how the platform handles file content when users upload to or download from Files, Attachments, and Documents. The settings determine whether the browser is told to display the file inline or download it as an attachment based on MIME type, with separate handling for trusted and untrusted file types. The page exists primarily as a defense against the most dangerous file-based attack: cross-site scripting through HTML, SVG, or other browser-executable file types served from the Salesforce domain. The default settings strike a balance between usability and security. Common file types (PDF, JPG, PNG, DOCX) display inline, which is what most users expect. Higher-risk types (HTML, SVG, JS) default to forced download, meaning the browser saves them as a file rather than rendering them in the browser's security context. Administrators can override these defaults per file type, but every relaxation increases the attack surface, so any change to defaults should be reviewed carefully.

A File Viewer in Salesforce is a user or group granted read-only access to a Salesforce File. Viewers can view, download, and comment on the file but cannot edit, delete, change sharing, or upload new versions. Viewer is the most restrictive sharing tier, sitting below Collaborator (read+edit) and Owner (full control). The ShareType field on ContentDocumentLink uses V to indicate Viewer permission. File Viewer is the right permission for read-only audiences: customers reviewing a contract, executives viewing a finalized report, partners consuming reference documentation. They need to see and download the file, but the file authors and Collaborators retain control over edits. Viewer access is also common when sharing through records: users with record access often inherit Viewer-level access to attached files unless the link explicitly specifies Collaborator.

A Private File in Salesforce is a File visible only to its Owner. No other users in the org can see, download, or edit it; the file does not appear in anyone else''s Files tab, search results, or related lists. Private is the most restrictive of Salesforce''s four file privacy states (Private, Privately Shared, Your Company, Public on the Web), and it is the default when a user uploads a File directly to the Files tab without any record context. Private Files are how Salesforce supports personal-storage use cases: drafts you are working on, scratch notes, files you want to keep on the platform without sharing yet. Once you share a Private File with a user, group, or record, it transitions to one of the broader privacy states. The transition is one-way unless you explicitly remove the sharing; Private is the starting point, and you choose when to widen visibility.

A Privately Shared File in Salesforce is a File visible only to its Owner and a specific set of users, groups, or records the Owner has explicitly shared it with. The privacy state sits between Private (Owner only) and Your Company (all internal users); it is the most common state for production files because nearly every file ends up linked to a record or shared with collaborators. The privacy state is computed from ContentDocumentLink records; explicit sharing transitions a Private File to Privately Shared automatically. Privately Shared is the working state for almost all team-collaboration files. A sales contract linked to an Opportunity, a creative asset shared with the marketing team, a Knowledge draft shared with the editor: all are Privately Shared. The platform classifies the state based on what sharing records exist; a file with ContentDocumentLink records pointing to specific users, groups, or records (but not to an org-wide audience) qualifies as Privately Shared.

A Your Company File in Salesforce is a File visible to every internal user in the org. It is the most permissive of the standard file privacy states short of Public on the Web; everyone with a Salesforce internal license can view, download, and (depending on permission level) edit the file. Your Company is the right state for org-wide reference content: HR policies, company-wide announcements, brand guidelines, training materials. The privacy state is computed from ContentDocumentLink records. A file becomes Your Company when it is shared with an org-wide Public Group (typically called All Internal Users or AllOrgEmployees) or published to a Library accessible to all internal users. The platform classifies the state automatically; there is no explicit Your Company flag to toggle. Removing the org-wide sharing transitions the file back to Privately Shared.

The Files Tab in Salesforce is the navigation entry point for accessing, managing, and organizing all Files visible to the current user. It appears as a standard app tab in Lightning Experience and Salesforce Classic; from there, users can upload new files, browse existing ones, filter by privacy state or library, search by content, and act on files (share, download, edit, delete). The Files Tab is the primary UI for file management when files are not yet attached to a specific record. The Files Tab surfaces filtered views: Owned by Me (files the user uploaded), Shared with Me (files explicitly shared), Recent (recently viewed), Libraries (organized workspaces), and Followed (files the user follows for change notifications). Each view applies the appropriate ContentDocumentLink filter to show only relevant files. The tab supports drag-and-drop upload, in-place preview, and the same Share, Download, and Edit actions available on record-page file related lists.

A Filter Condition or Filter Criteria in Salesforce is a logical expression that narrows a set of records to those matching specified rules. The concept appears across the platform: list view filters (show only Open Cases), report filters (Opportunities closing this quarter), Flow Decision conditions, validation rules, Workflow Rule criteria, formula fields, and SOQL WHERE clauses. Each context uses slightly different syntax, but the underlying idea is the same: an expression that returns true or false for each record. Filter conditions are foundational to almost every Salesforce automation, report, and UI customization. A condition typically references a field, an operator (equals, greater than, contains, starts with), and a value or another field. Conditions combine with AND/OR logic to express compound criteria; parentheses group nested logic. The platform evaluates conditions against each record, returning only those that match.

Filter Email Tracking is the Salesforce Setup setting that excludes specific email addresses or domains from being tracked when users open or click links in emails sent through Sales Cloud features like Email Templates, List Email, and the Sales Inbox. When email tracking is enabled, the platform embeds a pixel and link-rewriting in outbound mail to record opens and clicks. The filter list lets administrators exclude internal domains, partner addresses, or test recipients from this tracking, both for privacy reasons and to keep tracking data clean. The page is small but matters disproportionately because uncorrected tracking data produces misleading sales metrics. A sales rep forwarding a tracked email to a colleague generates spurious open events. Marketing dashboards counting opens against the recipient inflate engagement metrics. The filter list is the mechanism for excluding these known-noisy addresses so the tracking data reflects actual customer engagement rather than internal traffic.

Final Approval Actions in Salesforce are the actions that fire automatically when a record completes an Approval Process with a positive outcome. The Approval Process configuration defines what happens at the moment of final approval: update fields on the record (Status = Approved, Locked = True), send Email Alerts to stakeholders, create follow-up Tasks, send Outbound Messages to external systems. Final Approval Actions are distinct from per-step actions (which fire at each approval step) and from Final Rejection Actions (which fire when the approval ends in rejection). Final Approval Actions are the way an Approval Process tells the rest of Salesforce that a decision is final. The configurations live on the Approval Process detail page in Setup, alongside Initial Submission Actions, Final Rejection Actions, and Recall Actions. Each action is reusable: the same Email Alert can fire from Final Approval Actions, from Workflow Rules, and from Process Builder. The Approval Process orchestrates them in the right context.

Final Rejection Actions in Salesforce are the actions that fire automatically when a record completes an Approval Process with a rejection outcome. The Approval Process configuration defines what happens at the moment any approver rejects: update fields (Status = Rejected, mark the record for resubmission), send Email Alerts to the submitter and other stakeholders, create follow-up Tasks (review feedback, revise and resubmit), send Outbound Messages to external systems. Final Rejection Actions are the rejection-side counterpart to Final Approval Actions; together they cover the two terminal outcomes of any approval. Final Rejection Actions matter because rejection is rarely the end of the story. Most rejected approvals lead to revisions and resubmissions; the Final Rejection Actions kick off that next cycle. Common patterns: unlock the record so the submitter can edit, set a Status field back to Draft, send an email explaining the rejection, create a Task to address feedback. The platform makes the rejection-handling explicit through these actions.

Financial Services Cloud (FSC) is Salesforce's industry product for banking, wealth management, insurance, and asset management. It extends standard Salesforce CRM with financial-services-specific data models, workflows, and integrations: household and relationship-based client views, financial accounts and goals, insurance policies and claims, retail banking workflows, and the regulatory considerations specific to financial services. FSC is licensed separately from base Sales Cloud and Service Cloud, sold to wealth advisors, retail bankers, insurance carriers, and asset managers. The product structures around the Person Account and Household concepts: clients are individuals (Person Accounts) grouped into Households for relationship-based servicing. Financial Accounts (investment accounts, bank accounts, insurance policies) attach to Person Accounts and Households with rich attribute data. The Action Plan framework orchestrates multi-step processes like new account opening, mortgage origination, claims processing, or compliance reviews. Like Health Cloud, FSC is one of Salesforce's industry clouds tuned for the workflows and regulatory requirements of its target verticals.

Fiscal Year is the Salesforce setting that defines the period over which the org tracks revenue, quotas, and forecasting. Two configurations exist: Standard Fiscal Year follows the calendar (January through December) with the start month configurable, while Custom Fiscal Year lets an organization define its own period structure (4-4-5 retail calendar, 13 periods, fiscal year starting in any month with non-standard quarter alignments). The choice cascades through every revenue-related feature: Opportunity Close Date interpretation, Forecast tabs, Quota allocation, and most Sales Cloud reports that aggregate by period. The setting is org-wide and changes are not casual. Switching from Standard to Custom Fiscal Year, or changing the start month, recalculates every Opportunity's fiscal period assignment, breaks every report grouped by fiscal year or quarter, and resets in-flight forecasts. Salesforce requires explicit confirmation before applying the change and provides limited rollback options. Most orgs configure Fiscal Year during initial implementation and rarely revisit it; mid-life changes happen only during a major business event (acquisition, business model shift) and warrant a dedicated migration project.

A Flag in Salesforce is a user-initiated marker that brings attention to a piece of content or a record: an Experience Cloud community member reporting an inappropriate post for moderation review, a Chatter user flagging a feed item, a customer marking a Knowledge article as outdated, an admin tagging a record with a custom Flag field. The platform supports several flagging mechanisms across products, all sharing the same core idea: surface something that needs human attention without taking action on it directly. Flag mechanics differ by context. Experience Cloud moderation uses a built-in NetworkActivityAudit object to log community-member flags on feed items, comments, and files; moderators review the flagged content and take action (delete, hide, warn). Knowledge has Flag as Inappropriate and Flag for Review options that route to content owners or moderators. Other products use custom Flag fields (a checkbox on a Lead called Flag_for_Manager_Review__c) to drive list views, filters, and Flows. The common thread: flags are signals, not enforcement.

A FlexCard is an OmniStudio component that displays formatted, read-only data from one or more sources in a configurable card UI. FlexCards combine information from Salesforce objects, external systems (through DataRaptor calls), and computed values into a single visual surface: an account summary card showing tier, balance, recent transactions, and quick-action buttons. They live on Lightning record pages, in OmniScripts, on Experience Cloud sites, and embedded in standard Salesforce pages, providing context-rich data displays without requiring custom Lightning Web Components. FlexCards are part of OmniStudio (formerly Vlocity) and the Industries Cloud suite. Building one is declarative: a designer canvas with drag-and-drop fields, headers, action buttons, and conditional blocks. The data source is typically a DataRaptor Extract (now Data Mapper Extract) or an Integration Procedure, returning structured JSON that the card maps to display elements. Salesforce''s industries customers use FlexCards heavily because they encapsulate complex data displays into reusable, configuration-driven components.

Flow is the current Salesforce declarative automation framework, used to build everything from screen-based wizards that guide users through data entry to background processes that fire on record save, scheduled time intervals, or external events. Salesforce introduced Flow in 2012, expanded it through the late 2010s, and made it the strategic automation tool when announcing the deprecation of workflow rules and Process Builder. As of 2026, Flow is the only automation framework where Salesforce accepts net-new declarative builds in production orgs. A flow is a sequence of elements (Decision, Assignment, Get Records, Create Records, Loop, Screen, Subflow, Call Apex, and several dozen others) connected on a visual canvas. Each flow has a trigger that defines when it runs: a record save, a user clicking a button, a scheduled time, an inbound platform event, or another flow. Flows handle bulk DML, governor limits, and complex branching that the older frameworks struggled with, and they expose every Apex-callable surface to declarative authors. Flow is now the centerpiece of any automation roadmap, and proficiency with it is a baseline expectation for Salesforce administrators and developers alike.

Flow Builder is the declarative, point-and-click automation designer in Salesforce Setup. Admins use it to model business logic as a visual sequence of elements that read data, branch on conditions, write back to records, call Apex, hit external systems, and present screens to users. Flows execute on the same multitenant platform that runs Apex, but they require no code. A single tool produces five flow types: record-triggered, screen, autolaunched, schedule-triggered, and platform-event-triggered. Each saved flow lives under Setup, Flows as a versioned metadata record, and only one version is active at a time. Salesforce retired Workflow Rules in 2026 and is sunsetting Process Builder, so Flow Builder is now the only supported declarative tool for new automation work.

Flow Creation with Einstein is the Salesforce feature that lets administrators describe an automation in plain English and have Einstein generate the corresponding Flow. The admin types a description ("when an Account's Annual Revenue changes to over $1 million, create a high-priority task for the account owner"), the agent parses the intent, generates the Flow structure (trigger, decision elements, action elements), and shows a preview. The admin reviews, edits, and saves. The work that historically took a Flow architect 30 minutes collapses to a one-sentence request and a review pass. The feature is one of the early concrete uses of generative AI inside Salesforce Setup, and a precursor to the broader Setup with Agentforce surface. It works best on flows that follow common patterns (record-triggered flows, schedule-triggered flows, screen flows with simple branching) and less well on flows with complex external integration or unusual decision logic. The right mental model: Einstein speeds up the routine 80 percent of flow building; the architect's judgment still matters for the 20 percent that needs unusual structure.

A Flow Interview is a single running instance of a flow. When a user launches a screen flow, a record triggers a record-triggered flow, or Apex calls an autolaunched flow, Salesforce creates one Flow Interview to track that execution. The interview holds the current element, the value of every flow variable, the running user context, and the audit trail from start to finish. Most interviews finish in milliseconds and never appear in the database. Paused screen flows, scheduled-path entries, and any interview that hits a Pause element persist as rows in the FlowInterview standard object. Admins can monitor in-progress interviews under Setup, Paused and Waiting Interviews, resume them on behalf of the user, or delete them when the underlying scenario no longer applies.

Flow Orchestration is the Salesforce feature for sequencing multi-step, multi-user business processes on top of Flow Builder. Where a single flow handles automation that runs end-to-end for one user or one record, an Orchestration chains many flows together across stages, assigns work to different users at each step, and waits for each step to finish before moving on. Built into Flow Builder under the Orchestrator trigger type, an orchestration is itself a flow definition. Each stage holds one or more steps; each step calls either an autolaunched flow (background work) or a screen flow (a task assigned to a user or queue). Steps within a stage can run in parallel; stages run sequentially. Salesforce launched Flow Orchestration in Winter 22 and made it generally available with no extra license cost in Summer 23.

A Flow Trigger is the event that starts a flow. Salesforce supports five trigger types: record-triggered (a DML event on a chosen object), screen (a user launching the flow), schedule-triggered (a cron-like recurrence), platform event-triggered (a published platform event), and autolaunched (a call from Apex, REST, or another flow). The trigger is chosen at flow creation time and shapes which elements are available, how the flow runs, and which governor limits apply. The trigger also dictates whether the flow runs in the same transaction as the original action, in a future async context, or on a queue. A record-triggered flow with a before-save trigger executes inside the save itself; the same flow set to after-save runs in a separate phase after validation. Picking the wrong trigger combination is the most common reason a brand-new flow does not behave the way an admin expects.

A Folder in Salesforce is the access-control container for Reports, Dashboards, Email Templates, and Documents. Each item lives in exactly one folder, and the folder's sharing settings determine who can see and modify the items inside. Folders predate the modern record sharing model and operate on their own access rules: an item is visible to a user if and only if the user has access to its folder. This means folders are the only place where Report or Dashboard sharing happens, separate from record sharing on other objects. Folders come in two types. Public folders are accessible to specified users, roles, or public groups based on the folder's share settings. Private folders belong to one user (typically the creator) and are not shareable; items in a private folder are visible only to the owner. Salesforce historically used folders for nearly all content management, but the modern Files framework moved away from them in favor of library and record-based sharing. Reports, Dashboards, Email Templates, and Documents remain on the folder model.

Follow is the Chatter action that subscribes a user to updates from another user, a record, a group, a topic, or a file. Once a user follows something, every post, comment, file share, or feed-tracked field change on that object appears in their What I Follow Chatter feed. The action is bidirectional in spirit but not in mechanics: following a user does not require their approval, and followers cannot see anything they would not already have permission to see. Salesforce introduced Follow as the core Chatter engagement model in 2010. The same primitive powers What I Follow on the Home page, the Chatter tab record feed, mobile notifications, and most of the legacy social-style features. Feed tracking on an object decides which field changes generate a follow-worthy post; without feed tracking, following the record gives nothing more than manual posts and comments.

Forecast Amount is the projected revenue contribution of an Opportunity (or Opportunity Product line) as it rolls into Salesforce Forecasts. Each in-flight deal contributes a Forecast Amount that aggregates up the forecast hierarchy into every manager's number. The amount that lands in any given forecast cell depends on the Opportunity's Forecast Category, its Close Date, and the forecast period the user is looking at. Forecast Amount is not the same as Opportunity Amount. Opportunity Amount is one field on one record. Forecast Amount is a calculation that sums opportunity-level or product-level amounts grouped by category and period, then adjusts for overlay splits, manager adjustments, and currency conversion. A 100k Best Case deal contributes 100k to the rep's Best Case row, 100k to their manager's Best Case row, and 100k to the VP's, because the forecast hierarchy chains the rollup together.

A Forecast Category is the classification Salesforce applies to each Opportunity Stage to indicate how confidently the deal is expected to close. Standard Forecast Categories are Omitted (excluded from forecast), Pipeline (in flight but not committed), Best Case (optimistic estimate), Commit (promised to make the number), and Closed (already won). Each Opportunity Stage maps to one Forecast Category, and Collaborative Forecasts aggregates opportunities by category to show the sales team's expected revenue at multiple confidence levels. Forecast Category is the bridge between deal-level Stage data (which sales reps maintain) and forecast-level confidence (which leadership consumes). A typical sales process has 6 to 8 stages, and the Forecast Category mapping collapses those stages into 4 confidence buckets. The mapping is configured once in Setup, applies org-wide for every Opportunity, and rarely changes. Tuning the mapping is one of the highest-leverage decisions in Sales Cloud configuration: the same pipeline data can read as "on track" or "in trouble" depending on which stages map to Commit vs Best Case vs Pipeline.

Forecast Quantity is the unit-count value rolled up to the Collaborative Forecasts grid, parallel to Forecast Amount but counting units instead of revenue. When forecasting on Opportunity Product (line item) quantity, the platform sums the Quantity field on each line of every opportunity in the forecast period and posts the total to the rep's row in the forecast grid. The metric powers any sales organization that ships physical goods, software licenses, or subscription seats where the unit count matters more than the dollar amount. Forecast Quantity is configured per forecast type under Setup, Forecast Settings. Each forecast type chooses a source (Opportunity, Opportunity Product, or Opportunity Split) and a measure (Amount or Quantity). A single org can run several forecast types in parallel, including an Amount-based and a Quantity-based forecast on the same opportunity data. Reps then see two separate grids in the Forecasts tab and adjust them independently.

A Forecast User is a Salesforce user enabled for Collaborative Forecasts who appears in the forecast hierarchy and contributes a forecast number to their manager's roll-up. Forecast users hold opportunities, see their own forecast grid in the Forecasts tab, and (if they are a manager) see the rolled-up grids of every user reporting to them in the forecast hierarchy. The role is mandatory: only users marked as Forecast Users have their opportunities rolled into anyone's forecast number. Enabling a user as a Forecast User is a one-click toggle in Setup, Forecasts Hierarchy. The setting layers on top of the normal user profile and permission set assignments. A user can have the Sales license and a quota and still produce a zero in the forecast grid until the Forecast User flag is on. The hierarchy then determines who sees whose roll-up, with each forecast user reporting up exactly one level per forecast type configured.

Forecasts is the Salesforce product family that lets sales managers and reps project expected revenue or unit volume from the opportunity pipeline across future periods. The modern implementation is Collaborative Forecasts, a Lightning experience where each user sees a grid of forecast periods (monthly or quarterly) broken down by Forecast Category (Pipeline, Best Case, Most Likely, Commit, Closed) and rolled up through a forecast hierarchy that mirrors the role tree. The product replaced the legacy Customizable Forecasts in 2014 and the even older Classic Forecasts before that. Collaborative Forecasts supports up to four parallel forecast types per org (Amount, Quantity, Splits, Revenue Schedule, custom-field-based), inline manager adjustments, quota loading, partner forecast roll-ups, and an Einstein Forecasting prediction overlay. It is the single most important sales-management surface in Salesforce after the opportunity pipeline itself.

Forecasts Hierarchy is the Salesforce setup node that defines the manager-and-rep tree used by Collaborative Forecasts to roll up opportunity totals from each user to their manager and onward to the executive layer. It is a separate view of the org's role tree, with one extra layer of configuration: a Forecast Manager designated per role and a per-user Forecast User toggle that decides whether each person participates in forecasting at all. The hierarchy is what makes the Forecasts tab show anything beyond a single rep's own grid. When a manager opens the tab, the platform walks the forecasts hierarchy downward from their role, summing the forecast amount or quantity from every Forecast User reporting up the tree, and renders one row per direct report with an expand caret. Without a configured hierarchy, even an enabled rep produces zero in their manager's grid.

Forecasts Settings is the Setup node where Salesforce administrators turn on Collaborative Forecasts, choose the forecast types the org will run, set the period granularity, configure currency display, and decide which forecast categories show on the grid. It is the central configuration page for the entire Forecasts product; without a visit here, the Forecasts tab is unavailable and no forecast types exist. The page sits at Setup, Quick Find, Forecasts Settings. Beyond the Enable Forecasts toggle, it lets admins add up to four forecast types per org, set monthly or quarterly periods, choose Standard Fiscal Year or Custom Fiscal Year alignment, pick which Forecast Categories are visible in the grid, enable Cumulative Forecast Rollups, and turn on Adjustments. Every option here propagates to every Forecast User in the org.

A Foreign Key in Salesforce is a field on one object that stores the unique 18-character ID of a record on another object, establishing a relationship between the two. Salesforce never exposes the underlying database constraint and never lets admins define raw foreign keys; instead, the platform creates them automatically when a Lookup or Master-Detail relationship field is defined on an object. The relationship field renders as the parent's record name in the UI and stores the parent's ID under the covers. Every standard parent-child link in Salesforce uses this pattern. Opportunity.AccountId is the foreign key from Opportunity to Account. Contact.AccountId is the foreign key from Contact to Account. Custom Master-Detail and Lookup fields produce custom foreign keys (My_Object__c.Parent__c) following the same model. Foreign keys also drive SOQL relationship queries (SELECT Account.Name FROM Opportunity) and the polymorphic links on standard fields like Task.WhatId, which can store the ID of multiple parent object types.

A formula field is a read-only field in Salesforce that calculates its value from a formula expression evaluated against the record at read time. The result is recomputed each time the record is opened, queried, or displayed in a report, so the value never lives in the database and never needs to be updated by an automation or integration. It exists purely as derived data. The formula language is Salesforce's own functional dialect. It supports arithmetic, text manipulation, date math, logical branching with IF and CASE, cross-object references through relationship traversal, and several dozen built-in functions like TEXT, VLOOKUP, IMAGE, HYPERLINK, and PRIORVALUE. The output is a typed value matching the field's return type: number, currency, percent, text, date, datetime, checkbox, or picklist. Because formulas calculate on the fly, they always reflect the latest data without back-fill jobs.

A Full Sandbox is the largest of the Salesforce sandbox types, copying both the production org's metadata (every customization, every configuration) and the production data (every record across every object) into a separate, fully functional environment. Unlike smaller sandbox types that copy metadata only or include limited data samples, the Full Sandbox is a complete replica intended for production-mirror testing scenarios: integration testing with realistic data volumes, performance testing against actual record counts, user acceptance testing with familiar production-like data, and pre-production validation of major changes. The Full Sandbox is licensed at the Enterprise tier and above with one Full Sandbox typically included; additional Full Sandboxes are purchased per unit. Refresh cadence is the longest of any sandbox type: a Full Sandbox can be refreshed only once every 29 days, reflecting the resource cost of copying terabytes of production data. The setup process can take hours to days depending on org size. Most enterprises use the Full Sandbox sparingly, reserving it for the final pre-production validation window and using lighter sandboxes for day-to-day development.