Salesforce terms starting with R

Read Only is a Salesforce access level that lets a user view data without being able to edit, create, or delete it. It can apply to a single field, to whole records of an object, or to a record-detail page, depending on which control sets it. Read Only is not one feature. It is the result you get from several different security tools: field-level security, page layouts, object permissions, and organization-wide sharing defaults. Each one produces a read-only outcome in its own scope, and Salesforce combines them so the most restrictive applicable setting wins.

A Real-Time Transcription is a Service Cloud Voice feature that converts the audio of a live phone call into text as the conversation happens. The text streams onto the agent's Voice Call record during the call, so the agent reads what was said without taking notes by hand. The transcript is more than a convenience for the agent. It is the data feed that lets Einstein analyze the call live, surface knowledge articles, suggest next actions, and gauge sentiment. Supervisors can watch the same transcript to triage a call in progress and step in when a rep needs help.

Real-Time Translations is a Salesforce feature that uses AI-powered machine translation to translate content (Knowledge articles, chat conversations, case messages, and similar text) into the user's preferred language at the moment of display. The feature works without a manual translation pipeline: the source content is authored once in a master language, and the platform translates it on demand when a user or customer requests it in a different language. The feature lives under Salesforce's broader internationalization stack and powers both internal-facing scenarios (a global support team reading Knowledge articles in their preferred language) and customer-facing scenarios (a chatbot replying in the customer's detected language regardless of the agent's). The underlying engine uses Salesforce's AI Translation service, which is built on neural machine translation models tuned for business and technical content. Real-Time Translations is fundamentally different from the legacy Article Translation workflow, which required human translators to produce a separate translated record per language.

Recall Actions are the automated actions that run in a Salesforce approval process when a submitter withdraws a pending approval request before it finishes. They fire only when an in-progress request is recalled, and they typically reverse the changes that the initial submission made so the record returns to its pre-submission state. You configure recall actions in the approval process itself, alongside initial submission actions, final approval actions, and final rejection actions. A recall is allowed only when the approval process has "Allow submitters to recall approval requests" turned on. Common recall actions reset a status field, send an email alert, or fire an outbound message.

Recent Activity in Salesforce is the part of a record page that surfaces the latest activities (tasks, events, logged calls, and emails) tied to that record. It gives a user quick context on the most recent interactions before they call, email, or meet with the person or company. In Lightning Experience, this view is delivered by the activity timeline; in older setups it appears through the Open Activities and Activity History related lists. It is a reading surface, not a separate object. The records behind it are standard Task and Event records (and the read-only ActivityHistory view of closed work). Recent Activity simply orders those records so the freshest ones sit at the top, which is usually what matters most when someone opens a record.

Recent Items is the Salesforce UI component that lists the records each user has most recently viewed, giving the user a one-click path back to records they opened earlier in the session or recent days. In Lightning Experience it appears as the Recent Records dropdown on each object's standard tab and as a section in the global search results dropdown. In the older Classic interface it appeared in the left sidebar on every page. Recent Items is per-user and per-object. Each user sees their own list, scoped to records they personally viewed; another user looking at the same screen sees a completely different list. Salesforce tracks the views automatically; there is no manual add or remove. The platform caps the list at the most recent 10 to 50 records depending on context, and the records age out as the user views new ones. The data lives in the RecentlyViewed virtual object and is queryable through SOQL using FOR VIEW or FOR REFERENCE clauses.

A Recipe is a Data Prep tool in CRM Analytics (formerly Tableau CRM, originally Einstein Analytics) that prepares, cleans, and combines data into a dataset for analysis. You build it on a visual canvas as a chain of connected nodes, where each node reads the rows from the node before it and passes its result onward. A recipe starts with one or more input nodes that bring in source data. Middle nodes join, filter, aggregate, and transform that data. The recipe ends with an output node that writes the result to a dataset, a CSV file, Data Cloud, or an external system like Amazon S3 or Snowflake. Running the recipe produces or refreshes the data that dashboards and lenses then query.

A Recommendation in Salesforce is a record on the standard Recommendation object that represents one suggested offer or action to show a user inside Einstein Next Best Action. Each record holds a name, a description, an acceptance label, a rejection label, and a reference to the flow that runs when the user responds. The Recommendation object has been available since API version 45.0. Recommendations are the candidate actions that a strategy evaluates and surfaces. You build a pool of them, then a strategy loads, filters, and sorts that pool against customer context. Whatever survives the strategy lands in the Next Best Action component, where the running user sees a card and chooses to accept or reject it.

A Recommendation Strategy is the decision logic in Salesforce Einstein Next Best Action that decides which recommendations to show a user. It pulls recommendation records, filters and ranks them against the current context, and returns the short list that appears on a page. A strategy is built as a flow of the Recommendation Strategy type in Flow Builder. It runs every time a page needs recommendations, evaluates your data and rules in order, and hands back the final set in the outputRecommendations collection.

A record in Salesforce is a single row of data stored inside an object. If an object such as Account or Contact is the table, then a record is one entry in that table, with values filling each field the object defines. One Account, one Case, one Opportunity: each of those is a record. Every record carries a unique Salesforce ID and the field values set by your schema. Records are the working units of the platform. People create, read, edit, share, and report on them through the user interface, the APIs, and automation like flows.

A Record Detail Page is the main body section of a Salesforce record page that shows the field values, related lists, and other components for a single record. In Lightning Experience it usually appears through the Record Detail standard component, which renders the fields and related lists defined by the record's page layout. It is the part of the screen where a user reads and edits everything about one Account, Case, Opportunity, or custom object record. The page layout decides which fields and related lists appear, while the Lightning page decides where the Record Detail component sits and what surrounds it.

A Record ID is the unique identifier Salesforce assigns to every record it stores. It is a 15-character case-sensitive string that the platform generates the moment a record is inserted, and it never changes for the life of that record. The first three characters of the ID are the object key prefix and tell you what type of record it is (001 for Account, 003 for Contact, 006 for Opportunity, 500 for Case). The remaining 12 characters are a base-62 encoded identifier inside that object's table. Record ID is what every Salesforce URL, API call, formula reference, and integration uses to point at a specific row. Salesforce also exposes an 18-character version of the same ID that adds a three-character checksum suffix; the 18-character form is case-insensitive and is what you use anywhere case sensitivity might be lost (Excel, Outlook, some external systems). The two forms point at the same record, and the platform accepts either in URLs and API calls.

Record locking is the Salesforce mechanism that prevents a record from being edited while it sits in a controlled state, most commonly while it is pending approval or being updated by Apex. A locked record cannot be changed through the user interface or through code, except by users and processes that the lock allows. The term covers two related behaviors. In approval processes and Flow, Salesforce locks a record when it is submitted for approval and releases the lock once the request is approved, rejected, or recalled. In Apex, the FOR UPDATE keyword locks the queried rows for the duration of the transaction so two operations cannot update the same data at the same time.

A Record Name is the standard identifying field that every Salesforce object carries, holding the human-readable label that appears in list views, lookups, search results, and related lists. On the Account object it is the Account Name, on Case it is the Case Number, and on a custom object it is whatever Name field you defined when the object was created. The Record Name can be one of two data types. A Text Name asks the user to type a value when they create the record, like a company or project title. An Auto Number Name generates a sequential value automatically using a display format you set, like INV-{0000}, so each record gets a unique number without anyone typing it.

Record Page Settings is a Setup page in Salesforce that controls the default view used for Lightning Experience record pages across an org. From this single screen, an administrator decides whether records open in Grouped View, the standard tabbed and sectioned layout, or in Full View, a single scrollable column that places details near the top and related lists below. The page does not build record layouts itself. Lightning App Builder still composes each page and handles activation by org default, app, profile, and record type. Record Page Settings sits one level above that work and sets the reading experience users get when they land on a record.

A record type is a Salesforce configuration that lets a single object (Account, Opportunity, Case, or any custom object) behave like multiple variants, each with its own page layout, picklist values, and business process. The same Account object can serve as a B2B customer, a partner, or a personal-account household by switching record types, and the user sees a different form and stage flow for each variant without the data living in separate tables. Record types are the layer that connects three pieces of customization: which fields show up on the page (page layout assignment), which picklist values are available (picklist value filtering), and what stage or status sequence applies (business process selection). Profiles and permission sets control which record types each user can see and create. A single object can host dozens of record types, but most production orgs settle on three to five per object before the maintenance cost overtakes the flexibility benefit.

Record Update in Salesforce is the operation of changing the field values on an existing record. The operation is the same on the database, but the platform exposes many ways to invoke it: the user editing a field on a record page, a Flow's Update Records element, a Process Builder action, an Apex DML statement, a REST API PATCH call, the Data Loader, or a mass-edit on a list view. Each invocation path produces the same database effect (the record's fields are written, the LastModifiedDate is bumped, the order-of-execution runs) but differs in the constraints and behaviour around the write. Flow updates run inside a flow interview's governor limits. Apex updates run inside the calling transaction's limits. UI updates run as the user's session. REST API updates run under the connected app's bandwidth. The right path depends on who is triggering the update, where the trigger comes from, and what side effects the update needs to produce.

Record-Level Security in Salesforce is the layer of the security model that determines which individual records a user can see, edit, or own once the user already has object access. Where object permissions answer "can this user read Opportunities at all," record-level security answers "which Opportunities can this user read." It is the second control after object-level access and the most flexible because it operates on a per-record basis through ownership, role hierarchy, sharing rules, manual sharing, teams, and other granular mechanisms. Record-Level Security is what makes Salesforce work as a multi-tenant CRM where many users with the same object permissions still see different records. A sales rep in EMEA sees their EMEA opportunities; a rep in NA sees their NA opportunities; both have identical Read access on Opportunity at the object layer, but record-level security keeps their working sets separate. The administrator configures this through Org-Wide Defaults, Role Hierarchy, Sharing Rules, Manual Sharing, Account/Opportunity Teams, Territory Management, Apex Sharing, and Implicit Sharing, layered together to express the desired access pattern.

A Recurring Donation in Salesforce represents a donor's ongoing commitment to give a specified amount on a regular schedule - monthly, quarterly, or annually - to a nonprofit organization. In the Nonprofit Success Pack (NPSP), a Recurring Donation is stored on the npe03__Recurring_Donation__c custom object; in the modern Nonprofit Cloud, it is the standard RecurringDonation object. Each Recurring Donation record holds a parent Contact or Account (the donor), an Amount per installment, an Installment Period, a Date Established, a Status (Active, Lapsed, Closed), an optional End Date, a Payment Method, and configurable behaviors for how individual installment Opportunities (or Gift Transactions in Nonprofit Cloud) are generated. The recurring-donations engine automatically creates the next installment's transaction record at the appropriate cadence, posts it through payment processing, and updates the parent Recurring Donation's status if installments lapse or fail. Recurring Donations are foundational to nonprofit revenue strategy because sustaining donors typically have 5-10x the lifetime value of one-time donors and provide predictable monthly cash flow.

A Recurring Event is a Salesforce calendar event that repeats on a defined schedule (daily, weekly, monthly, or yearly) rather than occurring once. The series is stored as one master Event record with a recurrence pattern, and each occurrence in the series is rendered on the calendar from that pattern at display time. Users create a recurring event the same way as a single event, then set the recurrence options (every Tuesday, every other Friday, the third Thursday of the month) before saving. Recurring events differ from single events in three places that matter to admins. They live as a single Event row in the database with an IsRecurrence flag set true; they generate occurrence records on demand for the calendar view but those occurrences are not separately editable until the user breaks them out; and they can be edited series-wide or single-instance, with the user choosing the scope at save time. The recurrence pattern is the same iCal-style RRULE you would see in Outlook or Google Calendar.

The Recycle Bin in Salesforce is the soft-delete staging area where deleted records go before permanent removal. When a user deletes a record (through the UI, Apex DML, or the API), the platform marks the record as deleted but keeps it queryable through SOQL with the ALL ROWS keyword and accessible through the Recycle Bin UI. From the Recycle Bin, the record can be restored to its original state (with relationships and field values intact) or hard-deleted. Records stay in the Recycle Bin for 15 days, after which they are permanently purged. Recycle Bin exists at two scopes. My Recycle Bin shows records the current user deleted. Org Recycle Bin shows every deleted record in the org, visible to users with the Modify All Data permission. The 15-day retention is a per-org guarantee, and most orgs experience the platform purging older records earlier when the Recycle Bin hits its size cap. The Recycle Bin is the last line of defense against accidental deletes; once a record is purged from the bin, recovery requires a Salesforce Support data restoration request (which is paid and slow).

Referral Management in Salesforce Industries is a feature set inside Financial Services Cloud, Health Cloud, and Public Sector Solutions that tracks the lifecycle of a referral between parties: from intake (a doctor referring a patient to a specialist, a financial advisor referring a client to a wealth manager, a caseworker referring a citizen to a partner agency), through follow-up (was the referral acted on, was the visit scheduled, was the case opened), to outcome (was the referral successful and what was the result). The feature builds on the Account, Contact, Opportunity, and Case data model, adding industry-specific Referral records that capture the referring party, the receiving party, the reason for the referral, the timing requirements, and the consent or privacy considerations that apply. Each industry cloud customizes the referral schema for its regulatory context (HIPAA for healthcare, FINRA-style suitability rules for financial services, FOIA-style transparency for public sector).

A Refund in Salesforce (Refund in the API) is a standard object in Salesforce Order Management and Salesforce Billing that represents money returned to a customer after an Order has been fulfilled or partially fulfilled. Each Refund record holds a parent Account, a related PaymentId or PaymentGroupId tracing back to the original tender, an Amount, a Status (Draft, Pending, Processed, Cancelled, Failed), a CurrencyIsoCode, an EffectiveDate, a Type (Cash, Credit, Adjustment), a GatewayRefNumber for the payment processor's confirmation, and an optional reference to the originating Return Order or Credit Memo. Refunds close the financial loop on returns, cancellations, billing disputes, or goodwill credits - every dollar moving from the merchant back to the customer is captured as a Refund record, providing a queryable financial audit trail and a basis for reconciliation against the upstream payment gateway. Refunds integrate with Salesforce Billing's revenue recognition rules to ensure that recognized revenue is appropriately reversed when a refund is processed.

Regression Testing in Salesforce is the practice of running existing tests after a change to confirm the change has not broken previously working features. The change can be a code deploy, a configuration update, a package install, or a platform-pushed release upgrade. The tests can be Apex unit tests, automated UI scripts, or manual checklists run by QA. Regression testing is enforced by the platform in one specific case: deploying Apex code to production. Salesforce requires that at least 75 percent of Apex lines across the org are covered by passing tests before any code deploy succeeds. The 75 percent rule is the floor, not the goal; mature teams target 85 to 95 percent coverage with assertions that catch real behaviour, not just lines that ran without throwing.

A Related List in Salesforce is a section on a record page that displays records linked to the parent through a Lookup or Master-Detail relationship. On an Account page, the Contacts related list shows every Contact whose AccountId matches the current Account. On a Case page, the Case Comments related list shows every CaseComment linked to the Case. Related Lists are the primary way users discover the child records associated with a parent, and they are configurable per page layout to show the right columns and the right actions for each context. Related Lists are populated automatically. When a child record's relationship field references the parent, the child appears in the parent's related list. No manual configuration links them; the relationship field is the link. What admins configure is the appearance: which columns appear, how the list is sorted, how many rows display by default, which Quick Actions appear above each row. The configuration lives in the parent object's page layout and varies per layout. Different record types or different user populations can see different related list configurations.

Related List Hover Links are clickable shortcuts that appear in a strip at the top of a record detail page in Salesforce Classic. Each link represents one related list on the page, such as Contacts, Opportunities, or Open Activities. When the feature is on, an admin does not have to scroll a long record to reach a given related list. A user can hover the mouse over a link to open the matching related list inside a small interactive overlay, then view or manage its records right there. Clicking the same link jumps the page down to the full related list instead. The feature is a Salesforce Classic setting. Lightning Experience covers the same need with the Related List Quick Links component, so hover links are now mostly a legacy and migration topic.

A Related List Item is a single record shown as one row inside a Salesforce related list. It represents one related record, such as a contact, a case, or a custom object record, that is connected to the parent record currently on screen. Each row carries a link to open the underlying record, a set of columns that display chosen fields, and an actions menu for that record. The related list is the container; the related list item is one entry within it. The connection comes from a lookup or master-detail relationship between the two objects.

A Related Object in Salesforce is any object connected to another object through a Lookup or Master-Detail relationship, where the connection is represented by a relationship field on one side and a related list on the other. Contact is a related object to Account because every Contact carries an AccountId lookup; Opportunity is a related object to Account in the same way; OpportunityLineItem is a related object to Opportunity through a Master-Detail relationship. Related Object is the conceptual term for the connected-record pattern that runs through the entire Salesforce data model. Every standard CRM workflow (a Lead converting into an Account, a Case linked to a Contact, an Opportunity linked to its product line items) is built on related objects. The related object pattern is what enables roll-up summary fields, related-list rendering on detail pages, parent-child sharing inheritance, and the cross-object reporting that defines Salesforce analytics.

A Relationship in Salesforce is the data-model connection between two objects established through a relationship field (Lookup, Master-Detail, Hierarchical, or External Lookup). The relationship lets records on one object reference records on another, enabling the platform to navigate between related records, roll up data, enforce referential integrity, and inherit sharing where applicable. Relationships are fundamental to every Salesforce data model because almost no business entity exists in isolation: Accounts have Contacts, Contacts have Cases, Opportunities have Products, Orders have Order Products. Salesforce supports several relationship types, each with its own semantics. Lookup is the loose relationship where the child references the parent but neither cascades nor enforces tight coupling. Master-Detail is the tight relationship where the child cannot exist without the parent, cascades on delete, and inherits the parent's sharing. Hierarchical is a self-referencing relationship used primarily on the User object for the manager hierarchy. External Lookup connects Salesforce objects to External Objects (typically representing data in an external system via Salesforce Connect). Choosing the right relationship type for each connection is one of the most consequential data-model decisions.

A Relationship Group in Salesforce Financial Services Cloud is a way to bundle related people and businesses, most often a family household, so an advisor sees the whole picture instead of one isolated account. Under the hood it is a business account tied to a Party Relationship Group record, with each member connected through an Account Contact Relationship. The pattern lets a bank or wealth firm think at the household level rather than per client. A married couple, their children, a family trust, and the attorney who advises them can all sit inside one group, and financial data can roll up across everyone in it.

A Relationship Group Member in Salesforce Financial Services Cloud (FSC) is an individual account or contact record associated with a Relationship Group (also called a Household), with attributes defining the member's role and contribution within that grouping. The model lets a wealth advisor, banker, or insurance agent view a single client family as a coherent unit rather than as scattered individual records. Members can be the primary client, the spouse, dependents, related business entities, or anyone else whose financial life is connected to the household. Relationship Group Members are the building blocks that turn a list of unrelated Contact records into a meaningful family or business relationship. Each Member record links a specific person or entity to a specific Group with metadata about their role (Primary Member, Spouse, Child, Parent, Business Owner) and any specific permissions or rights within the group (decision authority, beneficiary status, joint ownership). The pattern is essential for wealth management workflows where decisions are made at the household level rather than the individual level, even though the underlying compliance and reporting still happens at the individual level.

A Relationship Query in Salesforce Object Query Language (SOQL) is a query that traverses object relationships to retrieve fields from related records in a single round trip. The query uses dot notation for child-to-parent traversals (Contact.Account.Name) and subqueries for parent-to-child traversals ((SELECT Id, Name FROM Contacts) FROM Account). The pattern is foundational to working with Salesforce data because almost every meaningful query involves multiple related objects, and constructing separate queries for each level of the relationship is inefficient and harder to maintain. The Salesforce platform's relationship-aware SOQL is one of the features that distinguishes the platform from a generic SQL database. Relationships are first-class concepts in the data model, and the query language treats them as such. A single SOQL query can traverse up to five levels of child-to-parent relationships, can include any number of parent-to-child subqueries, and can mix the two patterns freely. Mastering relationship queries is essential to writing efficient Apex, building useful reports, and integrating with Salesforce through the API.

Release management is the practice of planning, coordinating, and deploying changes through a Salesforce development lifecycle, moving metadata and code from sandboxes up to production in a controlled way. It covers what gets deployed, when, by whom, and how teams recover if a deployment goes wrong. It is a process and a discipline, not a single feature. Teams put it into action with tools like change sets, Salesforce DX, the Metadata API, and DevOps Center, layered on top of source control, testing, and a defined promotion path between environments.

A Release Train is a release management pattern where a team ships changes to production on a fixed, repeating schedule instead of deploying each change whenever it happens to be ready. Multiple work items from multiple developers are bundled together, tested as one batch, and shipped on a known date. Like a train leaving a station, the departure time is set in advance, and a change either makes it onto the current train or waits for the next one. Release Train is not a Salesforce feature you switch on. It is a way of organizing deployments that admins, developers, and release managers adopt on top of Salesforce delivery tools like DevOps Center, change sets, and the Salesforce CLI. The pattern gives every stakeholder a predictable answer to one question: when will my change reach production?

A Release Update is a platform change that Salesforce plans to enforce on your org, surfaced in a dedicated Setup page so admins can review it, test it, and prepare before it becomes mandatory. Each entry carries a short description, an impact assessment, an enforcement date, and usually a Test Run action that simulates the changed behavior in your live org without committing to it. The Release Updates page replaced the older Critical Updates console and became the single place where breaking or behavior changing platform updates are tracked. Salesforce ships three major releases a year (Spring, Summer, Winter), and updates are typically introduced in one release and enforced one or two releases later, which gives teams a known window to test and react.

Remote Access is the original Salesforce framework for letting an external application authenticate through OAuth and call into an org on a user's behalf. It is the older predecessor of the Connected App, and Salesforce kept the name alive mostly as a Setup area where legacy integration records still appear so admins can inventory them. Remote Access is a legacy feature. Any record created under the old model still functions for backward compatibility, but you should not build new integrations this way. Connected Apps replaced it years ago, and External Client Apps are now the recommended option for new work as of Spring '26.

Remote Access Application is the legacy Salesforce term for what is now called a Connected App. It refers to a registered external application that authenticates with Salesforce using OAuth 2.0 and integrates with Salesforce data through the API. The Remote Access Application name was retired around the Winter 2014 release when Salesforce consolidated the related identity and integration features under the unified Connected App framework, but the original name still appears in documentation, training materials, and older customer integrations. Anyone working with a legacy Salesforce org may encounter references to Remote Access Applications in old runbooks, partner documentation, or community posts. The functional capability is preserved entirely in modern Connected Apps; the rename was a packaging change that grouped OAuth-protected integration apps alongside related features (single sign-on, mobile app integration, canvas apps). Understanding the legacy term helps when reading old documentation or troubleshooting older customer environments.

Remote Site Settings is a Salesforce Setup page where administrators register the external URLs that Apex code, Visualforce pages, and certain other platform components are allowed to call. Before Apex can make an HTTP callout to any external endpoint, the endpoint's domain must be added to Remote Site Settings as a Remote Site. The platform enforces this allowlist at runtime: a callout to an unregistered domain fails with a security error, preventing unauthorized outbound connections from the org. The allowlist model is part of Salesforce's defense-in-depth security posture. Without it, any compromised Apex class could call any external URL to exfiltrate data or trigger external actions. With it, every outbound connection requires admin approval through the Setup page, providing a centralized audit point for which external services the org talks to. Remote Site Settings has been part of the platform since the introduction of Apex callouts and remains the standard pattern for outbound HTTP, though modern best practice favors Named Credentials for callouts that need authentication.

Rename Tabs and Labels is a Salesforce Setup page where an administrator changes the display names of standard objects, their tabs, and their standard fields to match the words a company already uses. From Setup, you enter "Rename Tabs and Labels" in Quick Find and edit any object in the list. The platform keeps the original API names underneath, so reports, automation, and integrations are unaffected. The point is adoption. If your team says Customers, Deals, and Tickets instead of Accounts, Opportunities, and Cases, the renamed labels meet people where they already think. You can also enter labels in other supported languages on the same page, which makes this feature double as the place to translate standard objects.

A renewal is the process in Salesforce CPQ (and the newer Revenue Cloud) of extending an existing contract or subscription past its end date, instead of selling the same products again from a blank quote. Salesforce CPQ creates a renewal opportunity and a renewal quote that carry the existing subscription products and subscribed assets forward, so a rep edits the deal rather than rebuilding it. The renewal opportunity gives the sales team a forecastable pipeline record tied to the account, with a close date set to the contract end date. The renewal quote then prices those lines using the account's renewal pricing method. Renewals are how subscription businesses protect recurring revenue, because most expected income each period comes from customers continuing rather than from net-new deals.

A Reply is the response a service agent or community member posts to an existing question, case, or feed item in Salesforce Service Cloud and Experience Cloud. It is technically a record on the related child object (Question Reply, Case Comment, Feed Comment) that carries the agent or contributor's answer, links back to the parent, and triggers downstream notifications. Replies are the unit of conversation in every Salesforce service surface that supports threaded discussion. They drive case email threading, Experience Cloud question-and-answer flows, Knowledge feedback loops, and Chatter feed conversations. The platform tracks each reply's author, body, timestamp, and visibility, and surfaces the most helpful one as the Best Answer on a question or the Resolution Comment on a case.

A Report in Salesforce is a saved query against the platform's data, with filters, groupings, summaries, and a chosen layout. Reports answer questions like "how many open opportunities over $50,000 close this quarter?" or "which support agents have the longest average case resolution time?" They are the foundation of every dashboard component, the source for many exports and integrations, and the most-used analytical tool in any Salesforce org. Every report is built on a Report Type, which defines the objects, relationships, and fields available. Filters narrow the row set. Groupings collapse rows into summary buckets. Summary formulas compute derived metrics within groups. The four format variants (Tabular, Summary, Matrix, Joined) shape how groupings and summaries render. Report Builder in Lightning Experience is the modern construction surface, with drag-and-drop column reordering, inline filtering, and live preview. Reports save to folders, and folder access controls who can view, edit, and share each report.

Report Builder is the Salesforce tool you use to create and edit reports. It gives you a point-and-click canvas where you pick a report type, add fields as columns, set filters, choose groupings, and add formula columns, with a live preview that updates as you work. In Lightning Experience, Report Builder opens in edit mode whenever you start a new report or click Edit on an existing one. You do not pick a report format by hand. The builder decides whether the report is tabular, summary, or matrix based on the groupings you add, so the layout follows the questions you ask of the data.

A report type is a Salesforce template that defines which records and fields are available to a report, based on the relationships between a primary object and its related objects. When you start a new report, the report type you pick decides what data you can pull and which columns you can add. Salesforce ships standard report types for common pairings, like Accounts with Contacts or Opportunities with Products. Admins also build custom report types to expose object combinations and lookup fields that the standard set does not cover.

A Reporting Snapshot is a Salesforce feature that captures the results of a source report on a schedule and saves them as records on a custom object. Each run writes a fresh batch of records, so the target object slowly builds a history of point-in-time data you can report on later. The feature is sometimes still called an Analytic Snapshot, its older name. Salesforce does not track historical changes to most fields by default. A standard report always shows the current state of your data. Reporting Snapshots fill that gap by saving a copy of report results at set intervals, which lets you trend metrics like open case counts or pipeline value across days, weeks, or months.

A Reporting Snapshot Running User is the Salesforce user account whose data access and report permissions decide which records a reporting snapshot captures when it runs. The snapshot reads the source report as that user would see it, then writes the results into a custom target object on the schedule you set. The running user is a required setting on every reporting snapshot. It carries weight beyond convenience, because the captured rows bypass normal sharing once they land in the target object. Anyone who can read the target records sees the running user's view of the data, even data they could not otherwise reach.

A Reporting Snapshot Source Report is the tabular report whose rows feed a Reporting Snapshot. Each scheduled snapshot run executes this report as the configured Running User, takes the rows the report returns, and copies them into records of a target custom object. The source report is the bridge between live Salesforce data and the historical record the snapshot is building over time. Source reports have strict requirements. They must be tabular, not summary, matrix, or joined. They must be saved in a folder the Running User can access. Each column the snapshot maps must have a compatible data type with the corresponding target object field. Outside those rules, a source report is a normal tabular report; admins build them with the standard Report Builder, and the snapshot feature pulls them in by reference at run time.

A Reporting Snapshot Target Object is the custom object that stores the data a Reporting Snapshot captures each time it runs. You pick this object when you define the snapshot, and every report row from the source report becomes one new record on it. Salesforce also calls the feature an Analytic Snapshot, so you may see the older name in some setup screens. The target object is where history lives. A standard report shows data as it looks right now, but a snapshot writes a dated copy of those results into the target object on a schedule. Build reports and dashboards on the target object and you can compare last week to this week, or chart a number's movement across months.

A Requested Meeting is an appointment request in Salesforce Scheduler that captures a customer's or agent's preferred time slot before that appointment is finalized. It records the chosen topic, location, and time, but it sits in a pending state until the right service resource is assigned and the details are reviewed and booked. In practice the request becomes a Service Appointment record once it is confirmed. The intermediate state gives you room for workflow: routing the request to a qualified specialist, checking availability, or sending it through an approval before it is locked in as a committed booking.

A resource calendar in Salesforce Field Service is the timeline of a single service resource that gathers everything affecting when that person can work. It pulls together scheduled service appointments, logged absences, operating hours, and shifts into one view of availability. The calendar is not a record you create by hand. Field Service assembles it from the resource's related data, then shows it on the Gantt, on the resource detail page, and in the Field Service mobile app. The scheduling engine reads the same availability when it decides which appointments a resource can take.

REST (Representational State Transfer) is the architectural style for web APIs that organizes operations as HTTP verbs (GET, POST, PATCH, DELETE) applied to resource URLs (/Account/001..., /Opportunity/006...) and exchanges data in lightweight formats like JSON. Salesforce exposes one of the most-used enterprise REST APIs in the world, with stable endpoints versioned by URL (vXX.X) and authentication through OAuth 2.0 access tokens. REST is the modern alternative to SOAP, the SOAP-and-XML-based protocol Salesforce shipped earlier and still supports. REST is preferred for almost every integration today because the payloads are smaller, the URLs are human-readable, the authentication flow plugs cleanly into OAuth 2.0, and tools like curl, Postman, and any HTTP client library work without specialized WSDL generation. Salesforce REST endpoints cover CRUD on every standard and custom object, composite operations, bulk data, query, search, metadata, and an ever-growing list of feature-specific APIs.

The Salesforce REST API is the platform's primary HTTP-based programmatic interface for reading and modifying Salesforce data and metadata from external systems. It exposes every standard and custom sObject through resource-oriented URLs, returns JSON payloads, supports the standard HTTP verbs (GET, POST, PATCH, DELETE), and authenticates via OAuth 2.0 through a Connected App. Mobile apps, integration platforms, custom web apps, ETL tools, and AI assistants all reach into Salesforce through this API. The REST API is versioned (currently in the 60s), with each version pinned by the URL path: /services/data/v60.0/sobjects/Account. Newer versions add features and refine behavior; older versions stay available for backward compatibility. The API supports composite calls (multiple sub-requests in one HTTP roundtrip), batch operations (up to 25 sub-requests in parallel), tree creation (parent and children in one request), query (SOQL via the query endpoint), search (SOSL), bulk operations (delegated to Bulk API), and resource discovery. For most integrations, REST API is the modern default; SOAP API remains for legacy patterns that REST does not cover.

Retrieval-Augmented Generation (RAG) is an architecture pattern for generative AI in which the system retrieves relevant source documents before the model generates a response, and then conditions the generation on the retrieved content. The retrieval step uses semantic search over a vector index of source content. The generation step is the language model writing the answer. The pattern was introduced in a 2020 Facebook AI paper and has become the default approach for production GenAI applications that need answers grounded in authoritative data rather than training memory. In Salesforce, RAG is the underlying architecture behind dynamic grounding, knowledge-based answers in Service Cloud Einstein, and file-grounded responses in Agentforce. The Salesforce-flavored name is grounding, but the mechanics are identical. Chunk the source content, embed each chunk into a vector, store the vectors in an index, retrieve the top-k matches at runtime, inject the matched chunks into the prompt, let the model generate. The advantage over fine-tuning is that source data can change without retraining the model. The disadvantage is that retrieval quality directly bounds answer quality.

A Return Order is a Salesforce object that records a customer's request to send purchased products back, either for a refund, a replacement, or a credit. In Salesforce Order Management it captures which items are coming back, in what quantity, the reason for the return, and where the goods are being shipped from and to. The same object also appears in Field Service, where it tracks the return or repair of inventory and products. Each Return Order ties back to an Order Summary and an Account, and it holds one or more Return Order Line Items that point at the specific products being returned. The object has existed in the API since version 42.0, so it is a long-standing part of the platform rather than a recent addition.

A Return Order Line Item is a child record on a Salesforce Return Order that represents one product (or one delivery charge) being sent back by a customer. Each line carries its own quantity, return reason, condition, financial amounts, and processing outcome, so a single return that covers several items can treat each one differently. The object exists in both Salesforce Order Management and Field Service. In Order Management it ties back to an order summary and its order product summary, and it drives refunds, credits, and exchanges. In Field Service it tracks parts and products that move back to a warehouse for repair, restock, or scrap. The API name is ReturnOrderLineItem.

A reusable API is an application programming interface built so that more than one project, team, or application can call it, instead of being wired to a single use. In the Salesforce world, the term comes from MuleSoft's API-led connectivity model, where a System API or Process API is designed once and then consumed by many downstream consumers. The point of a reusable API is to stop rebuilding the same connection over and over. You publish the API as a discoverable asset, document its contract, and let other teams find and call it. New integrations then compose from existing building blocks rather than starting from scratch.

Revenue Forecasting in Salesforce is the type of forecast that projects sales based on the dollar amount of opportunities, rolling Opportunity Amount values up the forecast hierarchy and grouping them into the Forecast Categories (Pipeline, Best Case, Commit, Closed). It is one of the two forecast types Collaborative Forecasting supports; the other is Quantity Forecasting, which projects based on the Quantity field on Opportunity Products. Revenue Forecasting is the default for most Salesforce orgs because revenue is the metric most sales organisations report on. Quantity Forecasting becomes relevant only when the business sells in units that matter as much as price (manufacturing seat counts, oil and gas barrels, agricultural tonnage). Both forecast types can be enabled simultaneously in the same org so an organisation can roll up both revenue and units side by side. The Forecast Categories map Opportunity Stages to forecast buckets that managers adjust week to week.

A Revenue Intelligence is a Sales Cloud bundle of analytics and AI features that helps sales leaders and reps grow revenue and forecast more accurately. It pulls together opportunity data, sales activity, and historical outcomes, then surfaces pipeline risk, forecast gaps, and deal health in one place inside Salesforce. Revenue Intelligence is built on CRM Analytics (the platform formerly called Tableau CRM, and originally Einstein Analytics). It packages three main tools: Revenue Insights dashboards, Pipeline Inspection, and Salesforce Forecasting, plus several Einstein predictions that score deals and flag where attention is needed.

A Revenue Schedule in Salesforce Products and Pricing is a configuration on a Product (or Opportunity Product) that defines how the total revenue from selling that product will be recognized over time, distributing the total across multiple installments rather than recording all of it at the closing date. The schedule is used for products whose revenue is earned over time: annual subscriptions, multi-year service contracts, deferred licenses, professional services delivered over weeks or months. The Revenue Schedule sits alongside the Quantity Schedule (which describes when quantity is delivered) as one of the two scheduling concepts on the standard Product model. Revenue Schedules matter because for many products the revenue recognition does not match the close date. A twelve-month software subscription closes once but recognizes revenue monthly for twelve months. Without Revenue Schedules, the Opportunity's total amount sits in a single point on the close date, which misrepresents the actual revenue timing. With Revenue Schedules, the Opportunity Product creates a series of OpportunityLineItemSchedule records that capture the monthly recognition installments, providing more accurate revenue forecasting and reporting.

A Role in Salesforce is a record-sharing concept, not a job-title concept. The Role assigned to a User decides which records the User can see by default through the Role Hierarchy, independent of what their Profile lets them do. A Sales Rep Profile says "this user can read and edit Opportunity records." The Sales Rep's Role says "this user can see Opportunities owned by themselves and by anyone whose Role rolls up underneath theirs in the hierarchy." Together, Profile and Role decide both capability and visibility. The Salesforce permission model splits authorization (Profile + Permission Sets) from visibility (Role + Sharing Rules). The split is intentional: a sales manager who can edit any Opportunity (Profile-level capability) should only see Opportunities owned by their team (Role-level visibility), not by every team in the company. Building those two layers independently gives admins enough flexibility to model real organizations where a Service Manager and an Account Executive carry the same Profile (both can edit Cases) but see entirely different record sets (the Service Manager sees their team's Cases; the Account Executive sees their owned Accounts and the Cases that hang off them).

A Role Hierarchy in Salesforce is the tree structure of Roles that propagates record access upward through the chain of command. Each Role in the hierarchy has one parent Role (or sits at the top with no parent), and records owned by users in any subordinate Role become visible to users in any parent Role above them. The Role Hierarchy is one of the four mechanisms in the Salesforce sharing model: it sits between Organization-Wide Defaults (which set the base access) and Sharing Rules (which grant additional cross-cutting access). Role Hierarchy is what makes manager visibility work in Salesforce. Without it, every manager who needed to see their team's records would require a separate Sharing Rule per team member. With it, a Regional VP automatically sees every Opportunity owned by every Manager and every Rep in their branch of the tree, without any per-record configuration. The trade-off is that Role Hierarchy access is broad and automatic; if a manager moves up the tree, they gain access to everything underneath them immediately, including records they may have no legitimate need to see.

A roll-up summary field is a custom field on a master record that automatically aggregates values from its child detail records through a master-detail relationship. It supports four aggregate operations: COUNT, SUM, MIN, and MAX. The field recalculates whenever a related detail record is created, updated, deleted, or undeleted, so the master always shows the current totals without any automation or scheduled job to refresh it. Roll-up summaries only work on master-detail relationships, never on lookup. That single constraint shapes most data-model decisions in Salesforce. When a team needs a real-time total on the parent (count of related opportunities per Account, sum of contract values per Customer, max close date across a project's tasks), they either model the relationship as master-detail or fall back to a workaround: scheduled Apex, the Declarative Lookup Rollup Summaries package, or a Flow that recalculates on demand.

A Routing Configuration is an Omni-Channel setup record that tells Salesforce how to distribute work items to service reps. It defines the routing model, the routing priority, how much capacity each item consumes, and how long a rep has to accept a pushed item before it moves on. Each routing configuration is tied to a queue. When a case, chat, lead, or custom object record enters that queue, Omni-Channel reads the attached configuration to decide who receives the work and in what order. You build them in Setup under Routing Configurations, then attach them to queues.

The Routing Engine is the Salesforce mechanism that decides which agent receives a new case, lead, chat, message, or work item the moment it lands in the platform. In modern Service Cloud, the engine is Omni-Channel, which considers agent capacity, skills, presence status, and configurable priority to push the right work to the right agent in real time. Older orgs still use assignment rules and queue-based routing, but the Omni-Channel engine is the canonical name when Salesforce documentation talks about the routing engine. The Routing Engine sits between the inbound work item (a new case from Email-to-Case, a chat from Embedded Service, a voice call from Service Cloud Voice) and the agent. It reads the work item's attributes, evaluates the configured routing rules, picks an eligible agent, and pushes the work to that agent's Omni-Channel widget. The agent accepts or rejects within a configurable timeout. If they reject or the timeout expires, the engine re-routes to the next eligible agent. The whole loop happens in seconds and is the difference between a queue that piles up and a queue that drains.

A Routing Point is the email address or web-to-case endpoint Salesforce uses as the inbound destination for support requests, where Email-to-Case or Web-to-Case automatically creates a Case record from the incoming message. Each routing point is configured in Setup with its own queue assignment, case origin value, default priority, default record type, and auto-response rules, so different inbound channels (support@, billing@, escalations@) can each open the right case with the right downstream behavior. Routing Point is the integration boundary between inbound customer communication and the Salesforce Case object. Without a routing point, an email sent to support@ stops at the company's mail server; with one, the same email creates a Case, attaches the message body and any files, links to the matching Contact, and lands in the right queue. The configuration also drives auto-acknowledgement emails, escalation paths, and the case-thread token that keeps the customer's reply tied to the same case.

A running user is the Salesforce user whose data access determines which records a dashboard or reporting snapshot pulls in. The dashboard runs queries with that person's permissions, sharing, and role hierarchy position, so everyone who opens it sees the same numbers regardless of their own access. This setting lives on the dashboard itself, under "View Dashboard As" in the dashboard properties. You can fix the running user to a specific person, set it to the dashboard creator, or make it dynamic so each viewer sees their own data. The choice controls both what is shown and how much sensitive data leaks across teams.

Runtime Manager in MuleSoft Anypoint Platform is the cloud-based console that handles deployment, monitoring, scaling, and lifecycle management for Mule applications across every runtime target: CloudHub (MuleSoft own hosted runtime), Runtime Fabric (Kubernetes-based hybrid runtime), on-premises Mule servers, and bring-your-own-cloud setups. It is the operational nerve center for an Anypoint platform, the place where developers push deployment artifacts and where ops engineers watch what is actually running. The product is one tier inside the broader Anypoint Platform alongside Anypoint Studio (the design IDE), Anypoint Exchange (the API catalog), API Manager (the policy engine), and Anypoint Monitoring (the deep observability tier). Runtime Manager is what people mean when they say where the Mule apps live. Salesforce acquired MuleSoft in 2018, so the platform is now part of the Salesforce ecosystem, but it retains its own console at anypoint.mulesoft.com and its own user identity model alongside Salesforce identity.