SMB common mistakes
SMB · Understand the traps and how to avoid them.
Assuming every Salesforce edition includes the same core features, and answering questions as if Sales Cloud, Service Cloud, and automation tools are available in every edition.
Candidates study feature names without mapping them to edition tiers, so they default to 'yes, Salesforce does that' rather than checking whether the described edition actually includes it.
What to do instead
Before answering, identify the edition stated in the question and recall the rough capability ladder: essentials-level products bundle a fixed set of objects and tools, while higher editions add customizable apps and more automation. When an edition is unspecified, choose the answer that reflects the product named in the question rather than the most advanced capability.
Confusing standard objects with custom objects, and treating standard fields as deletable or custom fields as undeletable.
The fundamentals material emphasizes 'you can customize anything,' which leads candidates to overstate what can be changed on standard objects and fields.
What to do instead
Memorize the rule set: standard objects come with the org and cannot be deleted; custom objects are created by admins and can be deleted; standard fields on standard objects generally cannot be deleted but can often be relabeled or made read-only via page layout and field-level security; custom fields can be deleted. Use this checklist on any object/field question.
Choosing a forecast or pipeline answer that ignores the difference between opportunity stage, probability, and forecast category, and treating them as interchangeable.
The terms appear together in Sales Cloud material, so candidates assume editing one automatically changes the others.
What to do instead
Learn the chain: stage drives default probability and default forecast category, but probability and forecast category can be overridden independently, and forecast category can be excluded from forecasts. When a question asks what changes when a rep moves a stage, answer with the defaults that follow, not a guaranteed overwrite.
Treating leads and contacts as the same record type, and answering conversion questions as if a lead record persists after conversion.
Candidates conflate the lead lifecycle with contact management and forget that conversion creates or links account, contact, and optionally opportunity records while the lead is marked converted.
What to do instead
Draw the conversion map once: lead converts into an account (new or matched), a contact (new or matched), and optionally an opportunity; the original lead remains as a converted record tied to the resulting contact. On any lead question, ask 'before or after conversion?' before selecting.
Assuming cases can only be created manually by agents, and missing channels like web forms, email-to-case, and self-service portals.
Case management is studied from the agent's console perspective, so channel intake and routing are underweighted.
What to do instead
For every case question, list the intake channels first (manual, email, web, chat, community/portal), then the routing mechanism (assignment rules, queues, escalation rules, omni-channel). Answers about case origin or routing usually hinge on which channel and which rule set is named.
Confusing queues with public groups and with roles when answering case or lead ownership questions.
All three control access or assignment, so candidates treat them as synonyms.
What to do instead
Anchor each: queues hold unassigned work records and are assigned from; public groups are collections of users used for sharing and list visibility; roles define the record-access hierarchy. If the question is about who receives a new case, the answer is a queue plus assignment or escalation rules, not a role.
Mixing up campaigns, campaign members, and leads/contacts, and assuming adding a member creates a new lead or contact.
Campaigns sit next to lead management in the study material, so candidates assume campaign membership generates records.
What to do instead
Remember that campaign members are associations to existing or new leads/contacts, and that a campaign member status tracks response. On campaign questions, separate 'who is in the campaign' from 'what record exists' and from 'what response was recorded.'
Treating reports and dashboards as the same tool, and expecting a dashboard to show data that its source report does not return.
Both are grouped under analytics, so candidates assume dashboards query data independently.
What to do instead
State the dependency explicitly: a dashboard component is built on a source report (or a filtered report), so its numbers are limited by that report's filters, fields, and running-user access. If a question asks why a dashboard shows zero or wrong values, check the source report filters and the running user first.
Assuming record access is granted by profile permissions alone, ignoring organization-wide defaults, role hierarchy, sharing rules, and field-level security.
Profiles are the most visible permission concept, so candidates stop there and forget the layered model.
What to do instead
Use the layered order on every access question: object permissions and field-level security from profile/permission sets, then organization-wide defaults, then role hierarchy and sharing rules, then manual sharing. Ask 'object, field, or record?' and 'which layer grants it?' before answering.
Confusing workflow rules, process builder-style automation, and flows, and assuming older automation types run in a predictable order with newer ones.
Automation tools overlap in purpose, so candidates pick whichever name sounds most current instead of matching the tool to the requirement.
What to do instead
Match requirement to tool: field updates, email alerts, and outbound messages on a single object fit older rule-based automation; multi-step logic, screen input, and cross-object actions fit flows. When a question describes order-of-execution conflicts, the safe answer is to consolidate into one automation tool rather than rely on mixed-tool ordering.
Treating Agentforce/AI features as fully autonomous and assuming they act without a defined topic, action, or human escalation path.
AI marketing language suggests open-ended assistants, so candidates overstate what an agent can do without configuration.
What to do instead
Frame agents as configured with topics, instructions, and actions grounded in org data, with escalation to a human when confidence or scope fails. On AI questions, prefer answers that mention defined scope, grounding in trusted data, and human handoff over answers implying unrestricted autonomy.