Salesforce terms starting with R

A Salesforce field or record access level that allows users to view data but not modify, create, or delete it, enforced through profiles, permission sets, field-level security, or sharing settings.

In Salesforce Service Cloud Voice, a feature that converts live phone conversations to text in real-time during customer calls, providing agents with a running transcript and enabling AI-powered suggestions.

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.

In Salesforce approval processes, the automated actions that execute when an approval request is recalled (withdrawn) by the submitter, such as field updates to revert the status or email notifications.

In Salesforce, a related list or section on a record page that displays the most recent activities (tasks and events) associated with that record, giving users a quick view of latest interactions.

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.

In CRM Analytics (formerly Tableau CRM, originally Einstein Analytics), a Recipe is a set of data transformation steps that prepares and combines datasets for analysis. Joins, filters, computed columns, and aggregations are defined in a visual editor, each step connected to the next to form a declarative data-prep pipeline - the output is a dataset that dashboards and lenses read from.

In Salesforce Einstein Next Best Action, a record that represents a specific offer or action to suggest to a user, containing a name, description, acceptance label, and rejection label displayed through the recommendation component.

In Salesforce Einstein Next Best Action, a strategy built in Strategy Builder that defines the decision logic for which recommendations to surface, combining data sources, filters, AI models, and business rules.

A Record in Salesforce is a single row of data stored in an object. Each record has a unique 15- or 18-character Salesforce ID and contains field values defined by the object's schema. Records are the fundamental units of data in Salesforce and can be created, read, updated, and deleted through the UI, APIs, or automation.

The main body section of a Salesforce record page that displays all the field values, related lists, and components configured in the page layout, representing the detailed view of a single record.

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.

In Salesforce approval processes and Apex, the mechanism that locks a record to prevent edits while it is pending approval or being processed, ensuring data integrity during the approval workflow.

The primary identifying field on a Salesforce record (like Account Name, Case Number, or a custom auto-number field) that serves as the human-readable label for the record in lists, lookups, and search results.

Record Page Settings is a Setup page where administrators configure default behaviors for Lightning record pages, including whether to use the standard record page or a custom Lightning page, how related lists are displayed, and whether to enable dynamic forms and dynamic related lists.

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.

In Salesforce Classic, the clickable links that appear at the top of a related list allowing quick access to actions like New, View All, and other operations without scrolling down to the full related list.

A single record displayed as a row within a Salesforce related list, representing one related record (like one contact or one case) associated with the parent record being viewed.

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.

In Salesforce Financial Services Cloud, a grouping mechanism that associates multiple accounts and contacts into a household or business group, providing a unified view of related financial relationships.

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.

In Salesforce development lifecycle, the practice of planning, coordinating, and executing the deployment of changes across environments (sandboxes to production), using tools like change sets, DevOps Center, or Salesforce DX.

In Salesforce release management, a Release Train is a scheduled cadence of deployments that bundles multiple changes from multiple teams into a coordinated release to production. Each Release Train has fixed dates - code-freeze, UAT window, release day - and predictable sandbox refresh points leading up to them. The goal is to eliminate ad-hoc "one-off" production deploys, align testing and go-live across teams, and give stakeholders a consistent "when will my change ship?" answer.

Release Updates is a Setup page that lists upcoming and recently enforced Salesforce platform changes that may affect the org. Each update includes a description, impact assessment, enforcement date, and the option to test the update before it is automatically enforced, giving administrators time to prepare.

Remote Access is a Setup page for managing legacy Connected App configurations that allow external applications to authenticate and access Salesforce data. While newer Connected Apps are managed through the App Manager, Remote Access provides backward compatibility for older OAuth integrations.

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 Setup page where administrators change the display names of standard objects and tabs to match their organization's terminology. This allows companies to customize Salesforce vocabulary without creating custom objects, making the platform feel natural to users.

In Salesforce CPQ and Subscription Management, the process of extending or renewing an existing contract or subscription, generating a renewal opportunity and quote with the existing product terms carried forward.

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.

The Salesforce report creation and editing tool that provides a drag-and-drop interface for selecting report type, adding fields (columns), defining filters, choosing groupings, and configuring summary formulas.

A Salesforce configuration that defines which objects and their relationships are available as data sources for a report, determining which fields can be included and how records from related objects are joined.

A Salesforce feature (also called Analytic Snapshot) that captures report results on a scheduled basis and stores them as records in a custom object, creating historical data snapshots for trend analysis over time.

The Salesforce user whose permissions and data access determine which records are included when a Reporting Snapshot runs, similar to how a dashboard running user controls the data scope.

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 specific custom object that an administrator designates to store the data captured by a Reporting Snapshot (also called Analytic Snapshot). When a Reporting Snapshot runs on its defined schedule, it takes a point-in-time snapshot of a source report's data and maps each report column to a corresponding field on the target custom object, creating one new record per report row. Over time, the target object accumulates historical records, enabling trend analysis and historical comparisons through reports and dashboards built on the target object's data.

In Salesforce Scheduler, an appointment request created when a customer or agent selects a desired time slot, which may require confirmation or assignment before becoming a confirmed appointment record.

In Salesforce Field Service, a calendar associated with a service resource that displays their availability, scheduled appointments, work orders, and absences, used by the scheduling optimizer to assign work.

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 Salesforce object (part of Order Management) that represents a customer's request to return purchased products, containing details about which items are being returned, the reason, and the expected refund or exchange.

A line item on a Salesforce Return Order that specifies a particular product being returned, its quantity, condition, return reason, and any associated refund amount or exchange details.

In MuleSoft's API-led connectivity approach (part of the Salesforce ecosystem), a system API or process API designed to be reused across multiple integration projects, reducing duplication and promoting consistent data access.

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.

Revenue Intelligence is a Sales Cloud product that gives sales leaders AI-powered insight into pipeline health, deal trends, and forecast accuracy. Built on CRM Analytics (the platform formerly known as Tableau CRM and originally Einstein Analytics), it analyzes opportunity, activity, and outcome data to surface patterns a human reviewer would struggle to spot - stalling deals, at-risk pipeline, historical forecast bias, and rep-level performance signals - directly inside the Sales Cloud experience.

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.

In Salesforce Omni-Channel, a configuration that defines how work items are distributed to agents, specifying routing model (most available or least active), priority, capacity weight, and overflow behavior.

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.

In Salesforce dashboards and reporting snapshots, the user whose data access permissions determine what records are included in the results, allowing a dashboard to show data from a single perspective regardless of who views it.

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.