Salesforce terms starting with F

A facet in Salesforce is a named region of a parent component that accepts custom content supplied by a developer. The most common form is the Visualforce tag apex:facet, which places markup into reserved slots such as the header, footer, or caption of data components like apex:dataTable, apex:pageBlockTable, and apex:column. A parent component declares these extension points, and the developer fills them without the parent needing to know what the content will be. The same word also describes a filter control in search experiences. In Einstein Search, Experience Cloud, Salesforce CMS, and CRM Analytics, a facet lets a user narrow a result set by category, record type, field value, or date. The two senses are related in spirit (a facet focuses content into a defined area) but operationally distinct. Visualforce facets are markup; search facets are interactive filters. Context tells you which one 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 record that links a file, image, or external link to a Chatter post. The object is named FeedAttachment, and it sits between a FeedItem (the post) and the thing being attached. When you drag a file into the feed composer or share a link in a post, the platform writes a FeedAttachment row that tells the feed what to render and where the underlying content lives. FeedAttachment is a junction-style object. It does not store the file itself. For a file, it points to a ContentVersion record through the RecordId field. For a link, it stores the URL in the Value field. The Type field marks each attachment as Content, Link, or InlineImage, and the feed UI uses that to decide how to display it. The object has existed since API version 36.0, and one post can carry several attachments at once.

A Chatter feed filter is a per-user control that narrows which posts and comments show in a Chatter feed view. Standard filters in Lightning Experience include All Updates and Fewer Updates, plus category filters such as People, Groups, and Files on the What I Follow feed. Group, profile, and record feeds carry their own filter sets, and admins can build custom filters for the Case feed. A feed filter changes the display, not the data. It hides posts that would otherwise render, but it never grants or removes access to the underlying records or to the FeedItem rows behind the feed. A user can switch filters at any time to view the same feed differently. Most feeds remember the last filter you picked, so the choice sticks until you change it.

A Feed Item is a single post in a Salesforce feed, stored as one record on the FeedItem object. Each FeedItem holds one entry: a text status update, a file share, a link, a poll, a question, or an automatic post about a record-field change. The object stores the post body, the author (CreatedById), the parent record the post belongs to (ParentId), the post type (the Type field, with values like TextPost, ContentPost, LinkPost, PollPost, and TrackedChange), and counts such as LikeCount and CommentCount. FeedItem has been available in the API since version 21.0. FeedItem is the core record behind Chatter and the feeds that appear on record pages, group pages, user profiles, and Experience Cloud sites. Comments on a post live on a separate FeedComment object, so one FeedItem can have many FeedComments. Because feeds are heavily used in active orgs, the FeedItem table often grows into millions of rows, which makes it both a rich source of engagement reporting and something admins watch for storage and retention.

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, holding one piece of data per record. Account.Name, Contact.Email, and Opportunity.Amount are all fields. Every field has a data type (Text, Number, Date, Picklist, Lookup, Formula, and so on) that controls the values it accepts and how it behaves in queries, formulas, page layouts, and the API. Each field also carries an API name used in code and a label shown to users, along with metadata for length, help text, default value, and the required flag. Fields are the smallest unit of customization on the platform. Salesforce ships standard fields for every standard object, such as Industry on Account or StageName on Opportunity. Admins add custom fields to capture org-specific data, and those fields carry the __c suffix on the API name. The platform supports roughly two dozen field types, and the type you pick decides what the field can do. A Picklist renders a dropdown, a Lookup creates a reference to another record, and a Formula is computed when the record is read.

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 the value currently selected in another field on the same record. The first field is the controlling field, and the second is the dependent field. When a user picks a value in the controlling field, the dependent picklist filters down to only the values an admin marked as valid for that selection. Field Dependencies are the declarative way to put if-then logic into picklist behavior. Without one, every value in the dependent picklist appears no matter what the controlling field says, and users can save combinations that make no sense. With one, the platform narrows the choices as the controlling value changes. The relationship is stored as field metadata and ships with the picklist fields, not as a separate validation rule.

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 tool that lets Salesforce admins customize what mobile workers see inside the Field Service mobile app on iOS and Android. You build configurations that control tabs, screens, fields, actions, and Lightning components without writing code. The work happens in a drag-and-drop canvas, and changes reach the app once you publish the configuration. It is the technician-facing counterpart to dispatcher tools like Field Service Settings. Because the mobile app runs offline-first, the builder also shapes which records prime to the device and which actions queue when there is no signal. You can tailor the layout by user profile, so a plumber and an HVAC technician each get a screen suited to their day.

Field Service Mobile Settings is the Salesforce Setup page that controls how the Field Service mobile app behaves for your mobile workers on iOS and Android. It is where an admin decides which appointment notifications get pushed, which flows appear as app extensions, how the app brands itself, and how it collects geolocation. Settings are tied to user profiles, so two groups of technicians can get two different mobile experiences from the same org. You reach it from Setup by entering "field service mobile" in Quick Find, then clicking Field Service Mobile Settings. The page lists a Default configuration plus any per-profile configurations you add. Click Show Details on a row to expand and edit it. The Default applies to anyone whose profile does not have its own row, so most orgs tune the Default first and add profile-specific rows only when a team needs something different.

Field Service Settings is the Setup page in Salesforce where admins enable Field Service and configure the dispatcher-side behavior of the product. It is the single place to turn the feature on, set scheduling and optimization defaults, define how work orders and service appointments move through their statuses, and control notifications, service reports, and the Dispatch Console. You reach it from Setup by typing Field Service Settings into the Quick Find box. The top of the page holds the Enable Field Service toggle, which activates the core objects (Work Order, Service Appointment, Service Territory, Service Resource) and makes the Field Service managed package available to install. Everything below that toggle is the policy layer that dispatchers, schedulers, and back-office teams rely on every day.

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 and tracked through the ContentDocument and ContentVersion objects. Files are the modern way to store content, and they replaced the older Attachment model as the default starting around 2014. Every File carries metadata (title, description, type, size, owner), supports versioning, and can be shared with people, groups, records, and libraries. A File is how Salesforce keeps documents next to the records they belong to. A signed contract on an Opportunity, a resolution PDF on a Case, a training video, a campaign creative, all live as Files. The platform renders previews for common formats, indexes supported files for full-text search, and controls who sees each File through link-level permissions rather than plain record sharing.

A File Collaborator in Salesforce is a user or group that has been granted view-and-edit access to a Salesforce File. A Collaborator can open the file, download it, post comments, and upload new versions. What a Collaborator cannot do is delete the file or hand out access to other people. Those rights stay with the file owner. Collaborator is one of the named sharing levels for Salesforce Files, sitting above Viewer (which is read-only) and below the owner. Under the covers, the access is stored on a ContentDocumentLink record whose ShareType field holds the value C. That link ties the file to a user, a group, a record, or a library, and the ShareType on each link decides how much access that audience gets.

A File Owner in Salesforce is the user who has full control over a Salesforce File, including the rights to edit it, delete it, change who it is shared with, and transfer the file to someone else. By default the File Owner is the person who uploaded the file, and the platform records that user in the OwnerId field on the ContentDocument record. No collaborator or viewer can override what the owner is allowed to do. File ownership sits at the top of the Salesforce Files sharing model, above Collaborator (view and edit) and Viewer (view only). Most files have exactly one owner for their entire life. Ownership can be moved to another user from the file detail page or programmatically by updating OwnerId, and a System Administrator with the right permission can act on any file regardless of who owns it.

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 person or group granted read-only access to a Salesforce File. A Viewer can view, download, and share the file, but cannot edit it, upload a new version, change its permissions, or delete it. Viewer is the most restrictive of the three file access levels, sitting below Collaborator (read and edit) and Owner (full control). On the ContentDocumentLink record that links a file to a user, group, or record, the ShareType field holds the value V to mark Viewer access.

A Private file in Salesforce is a file that has not been shared with anyone except its owner. The owner can see, download, edit, and delete it, but no other user finds it in their Files home, in global search, in feeds, or in any record related list. Private is the most restrictive of the file sharing states Salesforce reports for every file (Private, Privately Shared, and Your Company), and it is the state a file lands in when you upload it straight to Files home with no record or feed context. Private is not a hard wall around the bytes. The owner can access a private file, and so can any user who holds the Modify All Data or View All Data permission, except for files inside a private library where only the owner has access. The state is a description of the current sharing, not an encryption boundary. Share the file with one person, one group, one record, or one library, and it stops being Private and becomes Privately Shared.

A Privately Shared File in Salesforce is a Salesforce Files document that is visible only to its owner plus a specific set of people, groups, or records that the owner has explicitly granted access to. It is one of three sharing states a file can hold. The other two are Private, where only the owner (and users with Modify All Data) can see it, and Your Company, where every internal user can find and view it. A file lands in the Privately Shared state the moment someone shares it with a named person, posts it to a Chatter group, or attaches it to a record. Salesforce does not store this state as a single flag. It computes the state from the file's sharing records, called ContentDocumentLink rows. As long as those rows point at specific users, groups, or records and not at the whole company, the file reads as Privately Shared. This is the working state for nearly every business file, because most files end up attached to a record or shared with a teammate.

A Your Company file in Salesforce is a file shared with everyone who has an internal license in the org. Once a file reaches this state, it carries a "your company" icon, and any internal user can find it, open it, and download it. It sits one step below a public link, which drops the login requirement entirely. Your Company keeps the file behind authentication while making it visible org-wide. The state is not a switch you flip. Salesforce derives it from the sharing rows (ContentDocumentLink records) attached to the file. When a file is shared so that all internal users gain access, through an all-employees public group, a library open to everyone, or a Visibility value that covers all users, the platform reports the file as Your Company. Pull that org-wide grant and the file drops back to Privately Shared.

The Files Tab in Salesforce, labeled Files in the Lightning Experience navigation bar, is the central place where a user sees, uploads, and manages every Salesforce file they own or can access. It opens a screen called Files home that lists files independent of any record. From here a user can upload new files, browse and filter existing ones, search by name or content, preview without downloading, and run actions like share, download, get a public link, rename, follow, and delete. Files home is the modern home for documents in Lightning Experience, since the older Documents tab does not exist there. Each file shown is a ContentDocument, and the views are filtered by the current user's access through ContentDocumentLink records. The tab also exposes Libraries, the shared workspaces teams use to organize content, and external sources when Files Connect is set up. It is the right starting point for personal storage, drafts, and files that will be shared later rather than attached to one record first.

A Filter Condition (also called Filter Criteria) in Salesforce is a logical rule that narrows a set of records down to only those that match. Each condition points at a field, applies an operator such as equals, greater than, or contains, and compares the field to a value or to another field. The rule returns true or false for every record, and only the records that return true are kept. The same idea shows up almost everywhere on the platform. List view filters, report filters, Flow Decision and Get Records elements, validation rules, and SOQL WHERE clauses all rely on it. The syntax shifts a little between a point-and-click list view and a line of SOQL, but the mechanics stay the same. You name a field, choose an operator, supply a value, and optionally combine several conditions with AND, OR, and NOT logic.

Filter Email Tracking is the Salesforce Setup page where an administrator enters IP address ranges that should be excluded when the platform records email opens and clicks. When email tracking is turned on, Salesforce embeds a tiny invisible image (a tracking pixel) in HTML emails sent through Sales Cloud channels. If a request for that pixel comes from one of the filtered IP ranges, the open is not counted. The same idea covers tracked links. The setting exists because raw open data is noisy. Internal staff, corporate mail gateways, and security scanners all load images and fetch links, which inflates engagement numbers against the wrong people. By listing the IP ranges those requests come from, an admin keeps the tracking data closer to real customer behavior. The page is small, but it has an outsized effect on how trustworthy your email metrics are.

A Final Approval Action is an automated action in a Salesforce Approval Process that fires when a record is approved and there are no further approval steps left to complete. In other words, it runs at the moment all required approvals have been obtained. You configure these actions on the Approval Process detail page in Setup, in a section called Final Approval Actions. Final Approval Actions are how an approval tells the rest of Salesforce that the decision is final and positive. They typically set a status field to Approved, decide whether the locked record stays locked or unlocks for editing, and send notifications. They are separate from per-step actions (which fire at each step) and from Final Rejection Actions (which fire when the request is rejected).

A Final Rejection Action is an automated action that runs when a record is rejected in a Salesforce approval process and there is no path forward. Once any required approver rejects the request, the process ends with a rejection outcome and the Final Rejection Actions fire at that moment. The configuration sits inside the approval process itself, so an admin defines exactly what happens the instant a request is turned down. These actions are the rejection-side counterpart to Final Approval Actions. An admin can use them to set an approval status field to Rejected, send an email alert to the submitter, create a follow-up task, send an outbound message to an external system, or change whether the record stays locked. They give a rejected request a clear ending and, in most orgs, set up the next revise-and-resubmit cycle.

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 marker that surfaces a piece of content or a record for human review without taking any action on it. The most formal version lives in Experience Cloud, where a community member can flag a post, comment, file, or message as inappropriate. Each member flag is stored as a NetworkModeration record, and a site moderator decides what happens next. A flag is a request for attention, not an enforcement step. The word also covers lighter patterns. Salesforce Knowledge lets readers flag an article for review when it looks wrong or out of date. Admins often build a custom checkbox field, such as Flag_for_Manager_Review__c, to drive list views, reports, and Flow logic. The shared idea across all of these is the same: a flag says "someone should look at this," and a person or a rule has to follow up.

A FlexCard is an OmniStudio component that displays formatted, read-only data from one or more sources inside a configurable card layout. It pulls fields from Salesforce objects, external systems, and computed values, then shows them in a single visual surface. A common example is an account summary card with the customer tier, current balance, a list of recent cases, and a few action buttons. FlexCards live on Lightning record pages, inside OmniScripts, on Experience Cloud sites, and in external containers. FlexCards are part of OmniStudio, the toolset Salesforce gained from the Vlocity acquisition and now ships across its Industries products. You build one in the FlexCard Designer, a drag-and-drop canvas where you place fields, blocks, charts, and buttons without writing a Lightning Web Component by hand. The card reads its data from a Data Mapper (formerly DataRaptor), an Integration Procedure, a custom Apex method, or another FlexCard, then maps the returned JSON to each display element.

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 Salesforce flow and sets the rules the flow runs under. Salesforce supports several trigger types: record-triggered (a create, update, or delete on a chosen object), screen (a user launching an interactive flow), schedule-triggered (a time-based recurrence), platform event-triggered (a published platform event message), and autolaunched (a call from Apex, the REST API, or a parent flow). You pick the trigger when you create the flow, and that choice shapes which elements appear, when the flow runs, and which limits apply. The trigger also decides whether the flow runs inside the original transaction, after it, or on a separate async context. A record-triggered flow set to before-save runs during the save itself. The same flow set to after-save runs in a later phase, after validation. Choosing the wrong trigger combination is one of the most common reasons a 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 a person, a record, a Chatter group, a topic, or a file. Once a user follows something, the posts, comments, and feed-tracked field changes connected to it show up in that user's What I Follow feed. Salesforce stores each follow relationship as an EntitySubscription record, available through the API since version 34.0. Following is one-directional and permission-aware. Following a person does not need that person's approval, and followers never see anything they lack permission to see. A user can follow a combined total of 500 people, topics, and records at once. Following a record is most useful when an admin has turned on feed tracking, because tracking is what turns field changes into feed posts.

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 who has been enabled for Collaborative Forecasts, appears in the forecast hierarchy, and whose owned opportunities roll up into a forecast number. Forecast users see their own forecast grid on the Forecasts tab. If a user is also designated a forecast manager, they see the rolled-up grids of everyone reporting to their role in the hierarchy. Only enabled forecast users contribute to anyone's roll-up. Enabling a forecast user takes two things. First, the user needs the "Allow Forecasting" permission, set per user so you keep granular control even when several teams share one profile. Second, an admin adds the user to the forecast hierarchy. A rep can hold a Sales license, a role, and a quota and still show zero in the grid until both of these are in place.

Forecasts is the Salesforce sales-management feature that projects expected revenue or unit volume from the opportunity pipeline across future periods. The current implementation is Collaborative Forecasts, a Lightning experience where each user sees a grid of forecast periods (monthly or quarterly) broken down by forecast category and rolled up through a forecast hierarchy that mirrors the role tree. Collaborative Forecasts replaced the legacy Customizable Forecasting product, which Salesforce retired in the Summer '20 release (around July 2020). An org can run up to four active pipeline forecast types at once, mixing revenue and quantity measures off the same opportunity data. Reps and managers can adjust totals inline, load quotas, and overlay an Einstein prediction. It is one of the most-used surfaces in Sales Cloud after the opportunity pipeline itself.

A Forecasts Hierarchy is the Salesforce setup structure that defines who rolls up to whom inside Collaborative Forecasts. It mirrors the org's role tree (or its territory tree, if the org runs territory-based forecasts) and adds two pieces of configuration on top: a forecast manager designated at each level, and a per-user switch that decides whether someone takes part in forecasting. The platform uses this tree to sum opportunity amounts or quantities from each rep up to their manager, and onward to the top of the company. The hierarchy is what lets the Forecasts tab show more than a single rep's own numbers. When a manager opens the tab, Salesforce walks the hierarchy downward from their position, totals the forecast figures from every enabled user reporting up to them, and renders one row per direct report. Without a configured hierarchy and an assigned manager, an enabled rep still produces zero in anyone else's grid.

Forecasts Settings is the Setup page where a Salesforce administrator turns on Salesforce Forecasting (Collaborative Forecasts), defines the forecast types the org will run, and decides how forecast numbers are grouped and displayed. It is the control panel for the whole forecasting feature. Until an admin enables it here and activates at least one forecast type, the Forecasts tab stays empty and reps see nothing to roll up. You reach the page at Setup, Quick Find, Forecasts Settings. From there you flip on forecasting, choose monthly or quarterly periods, align periods to the fiscal year, set the rollup method, pick which forecast categories appear, and turn on options like adjustments and quotas. In multi-currency orgs you also choose the forecast currency. Every choice made here applies to every forecast user, so the page is usually configured once and revisited only when the sales model changes.

A foreign key in Salesforce is a field on one object that stores the 18-character record ID of a row on another object, creating a link between the two. Salesforce never exposes the raw database constraint and never lets you define a bare foreign key by hand. The platform builds one for you when you add a Lookup or Master-Detail relationship field to an object. The field shows the parent record's name in the user interface and quietly stores the parent's ID underneath. Every standard parent-child link in Salesforce uses this pattern. Opportunity.AccountId is the foreign key from Opportunity to Account, and Contact.AccountId is the foreign key from Contact to Account. Custom Lookup and Master-Detail fields produce the same thing on custom objects, such as Invoice_Line__c.Invoice__c. These keys also power SOQL relationship queries and the polymorphic fields on standard objects like Task.WhatId, which can hold the ID of more than one object type.

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.