How to make sure every seller only ever sees the products they are actually allowed to sell.
By : Ajay Pratap Singh
Once a product catalog in Revenue Cloud grows past a handful of SKUs, a familiar problem starts to surface. Sales reps begin adding items to quotes that were never meant for their customer’s situation — a manufacturing-only maintenance package ends up on a healthcare deal, or a public-sector-only bundle gets quoted for a retail account. None of this happens out of carelessness. It happens because the catalog itself does not know any better. Every product is visible to every buyer, all the time, unless someone tells the platform otherwise.
This is precisely the gap that qualification and disqualification logic is designed to close. Instead of relying on reps to remember dozens of unwritten rules, or on sales operations to manually scrub every quote before it goes out, the catalog itself becomes intelligent enough to filter what shows up based on the context of the deal. The result is a browsing experience where a seller opens the product catalog and simply sees a clean, relevant list — nothing that would need to be corrected, escalated, or apologized for later.
In this walkthrough, we will build a complete qualification setup from the ground up. Rather than filtering by geography, which is the example most commonly used in training material, we will filter product visibility by industry vertical — a scenario just as common in the field, where certain SKUs are restricted to Healthcare, Manufacturing, or Public Sector accounts only. The mechanics translate directly to any other qualifying attribute you might need: contract length, customer tier, compliance certification, or anything else stored on the transaction.
The Moving Parts Behind Qualification Logic
Before touching any setup screens, it helps to understand the handful of components that work together behind the scenes.
Context Definitions
A context definition is essentially a blueprint that tells Revenue Cloud which pieces of data are relevant during a given process, and where that data lives. For product discovery, Salesforce ships a predefined context definition out of the box, but it rarely contains every attribute your business needs to evaluate — which is why extending it is almost always the first real step.
Decision Tables
A decision table is a rules engine object that evaluates a set of conditions against incoming data and returns an outcome. In our scenario, the table will look at the industry value on a quote, compare it against a list of excluded products, and return whether a given item is qualified or disqualified — along with a human- readable reason.
Qualification Rule Procedures
A qualification rule procedure is the orchestrator. It accepts a list of products and categories, runs them through one or more decision tables, and returns each item tagged with its qualification status. This procedure is what actually gets wired into the product discovery experience that sellers interact with.
Product Disqualification Records
These are simple data rows that describe which product is excluded under which condition, and for how long. They give business users — not just administrators — a way to maintain the exclusion list over time without touching flows or decision tables directly.
What You Need Before You Start
A few prerequisites will save you time once you get into the configuration itself. You will need a Revenue Cloud org with Product Catalog Management and Product Discovery already enabled, since qualification procedures depend on both. On the permissions side, three distinct capabilities are required across the process: Manage Product Catalog to build and edit the qualification procedure itself, Rules Engine Runtime to work with decision tables, and Context Service Admin to extend and activate context definitions. It is also worth having a working familiarity with Expression Set Builder, since that is the canvas where qualification procedures are actually assembled, though it is not strictly necessary going in — this guide covers it as we go.
Step One: Add the Fields That Will Carry Your Qualifying Data
Every qualification rule needs a piece of data to evaluate, so the first task is creating a field that captures the industry a quote belongs to. Create a picklist field named Industry on the Quote object, with values such as Healthcare, Manufacturing, Public Sector, and Retail Distribution. Then create the identical picklist — same API behavior, same value set — on the Product Disqualification object, since that is where you will later record which industries a given product is off-limits to.
Keeping the value sets identical on both objects is not a cosmetic choice. The decision table you build later will compare these two fields directly, so any mismatch in spelling or casing will silently break the qualification logic without throwing an obvious error.
Step Two: Extend the Product Discovery Context Definition
With the fields in place, open Setup and navigate to the Context Definitions area. Locate the context definition currently assigned to Product Discovery — clone it if you would rather not modify the original, or edit it directly if you are comfortable doing so. Inside the definition, add a new node at the root level and name it Quote. Within that node, add an attribute called Industry, set its data type to Picklist, and configure
its direction as both Input and Output so the value can flow in and, if needed, be referenced elsewhere. Finally, tag both the node and the attribute with recognizable labels — Quote and Quote.Industry work well — since these tags are what you will reference later when wiring up the decision table.
Step Three: Connect Quote Data to the Context Definition
An extended context definition is only useful once it knows where to pull its data from. Inside the same context definition, open the data mapping section and add the Quote object as a mapped S Object. Drag the Quote node you just created onto the Quote object, then map the Industry attribute to the Industry field you built in step one. Save the mapping and activate the context definition — an easy step to forget, and one that will otherwise leave your new attribute permanently empty at runtime.
Step Four: Populate the Product Disqualification List
This is where the actual business rule takes shape, and it is deliberately kept as data rather than code so that revenue operations teams can maintain it without developer involvement. Open the Product Disqualification tab and add a record for each product-and-industry combination that should be blocked. For example, you might disqualify a product called Enterprise Compliance Suite for the Retail Distribution industry, and disqualify a product called Rapid Deployment Starter Kit for the Public Sector industry, each with an effective start date and a far-future end date so the restriction remains active indefinitely until someone deliberately changes it.
Because these are just records, extending the model later — say, adding a second qualifying dimension like contract term — mostly means adding another field and another batch of rows, not rebuilding the logic from scratch.
Step Five: Build the Decision Table
Decision tables live under Setup in the Lookup Tables area. Create a new one, choose Decision Table as the type, and continue. Set the table type to Standard and the usage to Product Qualification, since that is the usage type expected by qualification procedures. Rather than starting from a blank table, select the built-in Product Disqualification Decision Table template, which already understands the shape of the Product Disqualification object. Once the table is created, reopen it and add a condition column bound to the Industry field, using the Not
Equal operator. This condition is what flips the logic from a blocklist into a usable filter — a product is treated as qualified whenever the quote’s industry does not match a disqualification record tied to that product. Save the table, activate it, and remember to refresh it any time you add new disqualification rows, since the table caches its underlying data.
Step Six: Assemble the Qualification Rule Procedure
From the App Launcher, open Qualification Rule Procedures and create a new one. Give it a descriptive name, set the usage type to Product Qualification — this is required if the procedure will be used inside Product Discovery, since category-only procedures are not selectable there — and point it at the extended context definition you activated earlier. Open the new procedure’s first version in Expression Set Builder and add an Evaluate Decision Table element. Select the decision table you just built, then map each of its columns to the matching context variables: Product ID to Product.ID, Parent Product ID to ParentProduct.ID, Root Product ID to RootProduct.ID, Industry to Quote.Industry, and the two output columns — Is Qualified and Reason — back to their respective context variables. Mark the element to be included in output, give it a rank so Revenue Cloud knows the order in which elements should run if you add more later, and set a start date no earlier than the effective date of your context definition. Save your changes, simulate the procedure to confirm the mappings behave as expected, and activate it once you are satisfied.
Step Seven: Enrich the Context with a Small Apex Helper
Out of the box, the product discovery screen does not automatically know which record it is quoting against, so a small Apex class is typically needed to package that information as JSON the component can consume.
Step Eight: Extend the Discover Products Flow
Rather than editing Salesforce’s standard Discover Products flow, clone it so you retain a safe fallback. Inside the cloned version, insert an Apex Action just before the screen that displays the product list, and point it at the build Context Payload method from the class above, passing in the current record’s object API name and record ID. On the product list screen itself, bind its context data input to the array returned by that action. Save the cloned flow under a distinct name — Industry-Aware Product Browse works well — and activate it.
Step Nine: Bring It All Together in Product Discovery Settings
With every piece built, the last configuration task is telling Product Discovery which components to actually use. Open the Product Discovery settings page and set the context definition to the extended version you activated in step three, the qualification procedure to the one you built in step six, and the browse flow to the cloned flow from step eight. Turn on the option to enable qualification procedures, then save. From this point forward, every time a seller opens the catalog from a quote, the platform will silently run each candidate product through your decision table before anything renders on screen.
Step Ten: Confirm the Behavior End to End
Testing this kind of setup only takes a few minutes, but skipping it is how misconfigurations make it into production. Create a test quote, set its Industry field to Retail Distribution, and open the catalog — the Enterprise Compliance Suite should be absent from the results. Toggle on the option to display disqualified
items if your discovery layout supports it, and that same product should now appear but marked as unavailable, along with the reason text you configured. Switch the quote’s industry to Public Sector and confirm the results invert as expected, with the Rapid Deployment Starter Kit now excluded instead.
Common Issues and What Usually Causes Them
A handful of problems tend to repeat across implementations, and most trace back to one of a few root causes.
● Every product still shows up regardless of industry — almost always because the settings page is still
pointing at the original, unmodified Discover Products flow instead of your cloned version.
● No products appear at all — usually means the qualification procedure is active, but the Industry
attribute on the quote was never populated, or the context mapping from step three was never
activated.
● Results seem inverted or inconsistent — check the operator on your decision table’s condition
column; a stray Equals where Not Equal belongs will flip the entire outcome.
● The Apex context step throws an error — double-check the object API name and record ID being
passed from the flow; a typo here fails silently in some flow versions and loudly in others.
Practices Worth Adopting Beyond This Example
A single qualifying attribute is a reasonable starting point, but most organizations eventually need to filter on more than one dimension at once. Rather than bolting on additional picklists indefinitely, consider modeling multi-dimensional eligibility with custom metadata once you are combining more than two or three attributes, since it keeps the decision table from becoming unwieldy.
It is also worth treating qualification procedures as governed configuration rather than clickable settings. Exporting procedure definitions and storing them alongside your other deployment artifacts makes it far easier to audit who changed what, and to roll back a bad rule quickly if it ships with an error.
Finally, do not underestimate the value of the Reason field. Sellers trust a tool more when it explains itself — a product tile that says unavailable for this account’s industry builds confidence, while one that simply vanishes without explanation tends to generate support tickets instead.
Bringing It Together
Qualification and disqualification rules turn a static product catalog into something closer to a knowledgeable colleague — one that already knows which products fit a given deal and quietly keeps the rest out of view. The pattern demonstrated here, filtering by industry vertical, extends cleanly to almost any other business constraint worth enforcing: contract duration, customer segment, regulatory certification, or anything else already captured on the transaction. Once the context definition, decision table, and qualification procedure are in place, adding a new rule becomes a matter of inserting a data row rather than rebuilding the mechanism itself, which is exactly the kind of durability a growing revenue organization needs from its catalog.