MB-210 common mistakes
MB-210 · Understand the traps and how to avoid them.
Treating the default price list assignment as a per-record manual choice, so quotes and orders pick up the wrong price list and calculate unexpected prices.
Candidates memorise that quotes and orders reference a price list but miss that the price list is inherited from the opportunity/customer or the system default, not freely selected on the quote. They assume a dropdown they can override at quote time.
What to do instead
Trace the chain: customer or opportunity points to a price list, the quote inherits it, and the order inherits from the quote. Practise creating two price lists with overlapping products and observe which one a new quote uses. Remember the system default price list is what applies when no customer-level price list exists.
Configuring product families, bundles, and kits as if they behave identically, then predicting wrong line-item behaviour on quotes.
The names sound interchangeable and the UI is similar, but bundles expand into required and optional components at quote time while kits stay as a single line and families only group products for selection and pricing hierarchy.
What to do instead
Build one of each in a trial environment and add each to a quote. Note that bundle components can be edited or removed per the bundle's required flags, kit lines remain one unit, and family membership drives the product lookup hierarchy. Answer questions by asking which behaviour the scenario describes, not by the label alone.
Assuming unit groups and units are optional decoration, then failing questions about quantity-based pricing or unit conversion.
Candidates skip the unit group because it appears in a separate area from the product form, yet every product needs a unit group and the default unit affects quantity and pricing calculations.
What to do instead
Create a unit group with a primary unit and at least one related unit with a conversion factor, assign it to a product, and add a quantity in the related unit on a quote line. Confirm how the quantity converts. Treat unit group as a mandatory field on every product.
Writing a price list item for a product and expecting it to apply to every unit, then being surprised when the price does not match the quoted unit.
Price list items are keyed to a specific unit, and candidates configure one row and assume it covers the product globally. The pricing engine looks up the matching product-plus-unit combination.
What to do instead
Add price list items for each unit you sell in, and verify the unit on the quote line drives which row is used. When a scenario mentions selling in cases versus units, check that a matching price list item exists for that unit.
Treating the sales process flow as a fixed pipeline and being unable to say how to add, remove, or reorder stages, or how the flow relates to the opportunity's actual status.
The business process flow looks like a wizard and candidates assume stages are hard-coded to the entity. They also conflate the BPF stage with the opportunity's status reason.
What to do instead
Edit a business process flow in the customisation area: add a stage, add a condition, and set required fields per stage. Then move an opportunity through the flow and watch the status and status reason fields separately. Remember multiple BPFs can exist and are selected per record.
Confusing the opportunity close behaviour with the quote-to-order path, so questions about closing an opportunity as won or lost are answered with quote activation steps.
Both involve 'closing' something and both appear near the opportunity form. Candidates blur the opportunity close action, which records actual revenue and close date, with the quote win/lose and order creation flow.
What to do instead
Separate the two paths explicitly. Closing an opportunity captures actual revenue and description. Winning a quote creates an order and can close the opportunity. Practise both in a trial org and note which record is created at each step and which fields are prompted for.
Ignoring the difference between the out-of-the-box sales entities and the sales accelerator or sequence features, then answering sequence questions with generic BPF logic.
Sequences, up-next items, and the sales accelerator workspace are newer additions and candidates study only classic opportunity and lead management. They apply pipeline-stage reasoning to a feature driven by sequence steps and time-bound actions.
What to do instead
Learn sequences as ordered steps with conditions and time limits that assign activities to records, distinct from BPFs which track stage progression. Know that sequences attach to entities like leads and opportunities and that the sales accelerator surfaces the resulting up-next records. Match each scenario to sequences, BPF, or workflow rather than defaulting to one.
Configuring lead qualification and expecting the original lead to remain editable, or expecting all lead fields to copy to the created opportunity and contact.
Candidates assume qualification is a status change on the lead. In fact qualification creates new account, contact, and opportunity records and the lead becomes read-only, and only mapped fields carry over.
What to do instead
Run qualification on a test lead and inspect the resulting records. Note the lead's status and that it can no longer be edited, then check which fields mapped. For field-mapping questions, confirm by looking at the created opportunity rather than assuming a full copy.
Building a workflow or Power Automate flow to send a quote or update a record and forgetting that the record must be activated or that the flow runs under a specific owner's context.
Candidates focus on the trigger and action and overlook state requirements, such as quotes needing to be active before they can be revised or won, and overlook that flows run as the owner and can fail on permissions.
What to do instead
Before testing, confirm the record state required by the action. For flows, check the connection owner and run a test with a user who lacks elevated privileges to see permission failures. Read the action's documentation for state preconditions rather than assuming any record works.
Assuming dashboards, charts, and reports refresh automatically and reflect all records, then misjudging questions about data visibility and sharing.
Candidates treat dashboards as live views of the whole org. In reality dashboards and views respect security roles, sharing, and hierarchy settings, and some tiles cache or refresh on a schedule.
What to do instead
Test a dashboard as a user with a restricted role and observe which records disappear. Learn how hierarchy security and record sharing change visibility, and check whether a tile is a chart, a view, or an iframe-based tile with its own refresh behaviour. Answer visibility questions by asking who is viewing, not just what the data is.