Recommendation
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.
Definition
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.
How a Recommendation fits the Next Best Action engine
The record, field by field
A Recommendation record is mostly plain text fields plus one important pointer. The Name field is the internal label you use to find the record. The Description is the sentence the user actually reads on the card, so it should say plainly what you want them to do. The Acceptance Label is the text on the accept button, such as Apply Discount or Book Appointment, and the Rejection Label is the text on the dismiss button, often a short No Thanks. The Action field references the flow that runs when the user accepts, and you can wire a separate flow to a rejection too. You can also attach an Image so the card carries a logo or product shot. Because Recommendation is a standard object, records support normal list views, validation rules, field history, and reporting. That matters because a Recommendation is data, not config buried inside a tool. A non-technical owner can edit the wording of a live card without touching the strategy or the page, which keeps copy changes fast and low risk.
Strategies pick, recommendations supply
A Recommendation on its own does nothing. It needs a strategy to decide when and to whom it appears. Originally you built strategies in a dedicated Strategy Builder canvas with Load, Filter, Sort, Branch, and Map elements. Salesforce later added the ability to build the same logic inside Flow Builder, so a recommendation strategy can run as a flow that ends with an output collection. Either way the pattern is the same. The strategy reads recommendations into a working set, drops the ones that do not apply, ranks what remains, and returns a short list. In a Flow Builder strategy you place qualifying records into the outputRecommendations collection, and Next Best Action displays only what lands there. Filters can test recommendation fields, fields on the running user, and fields on the record currently in view. This split keeps responsibilities clean. The recommendation says what could be offered. The strategy says whether the moment is right. You can reuse one recommendation across several strategies, and one strategy can return many recommendations.
The accept and reject flows
The point of a Recommendation is to turn a suggestion into a completed action. When a user clicks the accept button, the flow named in the Action field launches. You can assign a screen flow that collects input, such as a form to log a service appointment, or an autolaunched flow that runs silently to update records in the background. Screen flows are the common choice when the action needs the agent to confirm details with the customer. You can also launch a flow when a user rejects a recommendation, which is useful for capturing a reason or offering an alternative. Only screen flows and autolaunched flows can be attached, so a recommendation cannot directly fire a record-triggered or scheduled flow. Design these flows to finish the job end to end. A weak setup shows a nice card, then dumps the agent into a manual process. A strong setup completes the booking, the discount, or the case update inside the same flow, so the suggested action and the work to do it stay together.
Where recommendations appear
Recommendations show up through the Einstein Next Best Action component, which an admin drops onto a Lightning record page, a Lightning app page, or a community page using the Lightning App Builder. The component is bound to a single strategy, and at runtime it renders the cards that strategy returns for the current context. On a Contact record, for example, the component might surface a renewal offer and a survey request side by side, each as its own card with its own buttons. The component also works in the Service Console and in guided actions for support agents, so the same recommendation can serve a sales rep and a service agent depending on where it is placed. Because placement is config, you can pilot a strategy on one page layout or one profile before rolling it wider. You decide how many cards to show and whether users can expand a list of more options. The visual card is the only part of this system the end user ever sees, so the wording and the image carry the entire impression.
Measuring acceptance with RecommendationResponse
Every time a user accepts or rejects a card, Salesforce can record the outcome on the RecommendationResponse object. That gives you an acceptance rate per recommendation, which is the number that tells you whether the wording and the targeting are working. A recommendation that is shown often but rarely accepted is either pointed at the wrong audience or phrased badly. A recommendation with a high acceptance rate is worth surfacing more aggressively. Mature programs treat this as a feedback loop. They read the response data, rewrite descriptions and labels, adjust strategy filters, and watch the rate move. Because recommendation copy lives on editable records, that loop is quick. You are not republishing a flow or a page to change a sentence. Reporting on RecommendationResponse alongside the action records the flows create lets you connect a click on a card to real downstream outcomes, such as a booked visit or a closed case. That is how a Next Best Action program proves it drove value rather than just displayed suggestions.
Creating recommendations beyond stored records
Stored records on the Recommendation object are the most common source, but they are not the only one. A strategy can also build recommendations on the fly from other data when you do not want to maintain a static library. In a Flow Builder strategy you assemble recommendation values in memory and place them into the output collection. For more advanced cases, an Apex invocable action can generate or score recommendations, which is how industry solutions like Consumer Goods Cloud produce visit and task suggestions. The Connect REST API and a Recommendations Apex class also expose recommendations programmatically for custom interfaces. Choosing between stored and generated comes down to scale and volatility. A fixed set of offers that business users tweak is a good fit for stored records. A large or rapidly changing set, or one driven by an external model, is a better fit for generation in code. Many real deployments mix both, keeping a curated library for core offers and generating long-tail suggestions when context demands it.
How to create a Recommendation record
Recommendations are created as records on the standard Recommendation object, usually from the Recommendations app or tab in Setup. Build the record first, then point a strategy at it and place the component on a page so users can see it.
- Open the Recommendations app
Use the App Launcher to open the Recommendations app or tab. This is the standard object that backs Einstein Next Best Action. Click New to start a record.
- Write the card text
Fill in the Name for internal use and the Description that the user reads. Keep the description short and action oriented so the suggestion is obvious at a glance.
- Set the accept and reject labels
Enter an Acceptance Label for the accept button and a Rejection Label for the dismiss button. Use verbs the user understands, such as Book Now and Not Now.
- Attach the action flow
In the Action field, reference the screen flow or autolaunched flow that should run when the user accepts. Optionally add an image and save the record.
- Wire it into a strategy and page
Add the recommendation to a strategy so it can be filtered and ranked, then place the Einstein Next Best Action component on a record or app page bound to that strategy.
Internal label used to find and reference the recommendation; not shown on the card.
The sentence the user reads on the card; this is the actual offer or ask.
Text on the accept button, for example Apply Discount or Schedule Visit.
Text on the dismiss button, for example No Thanks or Not Now.
Reference to the screen flow or autolaunched flow that runs when the user accepts.
- Only screen flows and autolaunched flows can be assigned to a recommendation; record-triggered and scheduled flows cannot.
- A recommendation never appears on its own. It must be returned by a strategy that the placed component is bound to.
- The Description is the only persuasion the user sees, so vague wording quietly tanks your acceptance rate.
- The object exists from API version 45.0, so older orgs or integrations on earlier API versions will not see it.
Prefer this walkthrough as its own page? How to Recommendation in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Recommendation.
Hands-on resources to go deeper on Recommendation.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Recommendation in Salesforce Einstein Next Best Action?
Q2. What information does an Einstein Next Best Action Recommendation record carry?
Q3. Where do Einstein Next Best Action Recommendations typically surface for users?
Discussion
Loading discussion…