Salesforce Sales Cloud Consultant common mistakes
Salesforce Sales Cloud Consultant · Understand the traps and how to avoid them.
Reads every scenario as a feature-recall question: skims past the business context (B2B vs B2C, inside vs field sales, deal complexity, volume, partner/channel motion) and picks whichever option sounds most powerful, e.g. recommending CPQ + multi-currency + territory management when the stem describes a small, single-currency telesales team.
Stems are long and every distractor is a real Salesforce capability, so recognition memory takes over and the candidate answers 'what can the product do' instead of 'what does this business need'.
What to do instead
Before reading the answer options, write one line: business model, sales motion, deal complexity, geography, transaction volume. Eliminate any option that is technically valid but mismatched to that line, then compare the survivors on configuration and administration cost.
Designs record access by setting the org-wide default to Private and then assuming the role hierarchy alone opens it up, or assumes a sharing rule can make an object more restrictive than its OWD. Often forgets to check 'Grant Access Using Hierarchies' on a custom object before promising manager visibility.
OWD, role hierarchy, sharing rules and manual/Apex sharing are usually learned as separate features, so candidates reason about them one at a time instead of as a single maximum-access calculation.
What to do instead
For each object, compute access in a fixed order: OWD is the baseline for internal access; role hierarchy and sharing rules can only widen access from that baseline, never narrow it; hierarchy-based access applies only upward and only while Grant Access Using Hierarchies is enabled. State the resulting access for a named lower-role test user before recommending the design.
Jumps to a custom build (Apex trigger, custom object, custom component) the moment a requirement sounds non-standard, and pairs it with a single big-bang go-live that switches on all automation, data migration and training at once.
Consulting instinct says 'cover every requirement precisely', and custom solutions sound more rigorous than standard configuration; the exam instead rewards the minimum viable declarative solution and a phased rollout.
What to do instead
Walk a declarative-first ladder out loud (standard object and field → record type and page layout → validation rule → Flow → AppExchange app → code) and state the rollout sequence: pilot group, data clean-up/migration, UAT, then release. The best answer usually has the fewest moving parts.
Treats opportunity stage, sales process, record type and forecast category as interchangeable - designing a different stage picklist per team, assuming forecast category is a free-form label set anywhere in Setup, or building a sales process that is never assigned to a record type.
The stage picklist is the visible, editable artifact on the opportunity, while the sales process object and the stage's forecast category are configured in less obvious places and are easy to conflate.
What to do instead
Memorize the chain: one stage picklist org-wide → sales processes select a subset of those stages → a sales process is assigned through a record type → each stage carries a forecast category that can be overridden per record type. If stages must differ by team, the answer is record types plus sales processes, not a second picklist; Sales Path guides but only validation rules enforce.
Recommends Person Accounts or Contacts to Multiple Accounts as a harmless 'flexible' option without flagging consequences: that Person Accounts cannot be switched off from Setup once enabled, that they change record types, layouts, duplicate and reporting behaviour, and that with Contacts to Multiple Accounts the direct account still governs the contact's ownership and sharing.
Both features look like a simple checkbox that adds capability; their irreversible and structural side effects are only learned through hands-on implementation experience.
What to do instead
Treat both as architecture decisions: confirm B2C vs B2B from the stem, then list the implications (person account record types and layouts, which account controls contact sharing, reporting over the account-contact relationship object). Recommend them only when the scenario is clearly B2C or genuinely needs a contact linked to multiple accounts.
Assumes lead conversion is reversible and lossless: recommending 'convert the leads' as a data clean-up tactic, expecting every custom lead field and the lead's campaign membership to appear on the new records, or telling the client that a converted lead can be re-opened and edited like a normal lead.
In the UI, conversion looks like a rename operation on a single record, so the one-way nature, the field-mapping dependency and the account/contact matching behaviour are easy to overlook.
What to do instead
State the conversion contract explicitly: conversion creates or merges one Account and one Contact plus an optional Opportunity, only mapped fields (standard mapping plus custom field mapping) carry over, converted leads become read-only with no re-open path, and duplicates are matched against existing accounts and contacts. If the data might need to be worked as a lead again, do not convert it.
Answers an activity-visibility requirement by recommending an automatic email/calendar sync and then promises a standard report or dashboard over those synced emails and events; separately, assumes adoption will happen once features are enabled, with no named owner, training plan or adoption metrics.
Automatic capture looks like 'free activity logging', and shipping configuration feels like project completion, so data residency and enablement are never examined.
What to do instead
Check where the activity data actually lives before promising reporting: automatically synced email/calendar data is stored outside core Salesforce records and is not available to standard reports and dashboards, so if the client needs reportable activity history, choose an approach that writes to the activity records. Pair every rollout with an enablement plan and a small adoption dashboard (logins, activities created, records updated) with an owner.
Assumes a report type already exists for any object pair, builds a dashboard without naming the running user, and ignores limits and edge cases - rows returned, 'view dashboard as', dashboard filters versus report filters, and the fact that trend/historical reporting needs to be enabled and configured.
In a developer org with little data and one admin, almost any report can be built, so limits and sharing-through-dashboards only surface in production with real volumes and role hierarchies.
What to do instead
For each reporting requirement, name three things: the report type (and whether a custom report type is needed because no standard relationship exists), the running user whose sharing determines what the dashboard shows, and the row/refresh limits. If the client wants trend over time, verify historical trending or reporting snapshots are enabled rather than assuming a standard report delivers it.
Expects duplicate rules to clean up records already in the org, forgets matching rules entirely or assumes the standard matching rules can be edited, and promises field history tracking on more fields or for longer than the org allows.
'Duplicate management' sounds like a de-duplication tool, and matching rules versus duplicate rules are configured in two separate places, so the prevention-versus-remediation distinction is missed.
What to do instead
Separate the two problems in the answer: duplicate rules prevent new or edited duplicates at save time (alert or block), while existing data needs a deliberate clean-up run with a data-loading tool on a matching rule you control - standard matching rules are not editable, so clone them. Before promising audit history, state the per-object tracked-field limit and the standard retention window.
Chooses an integration mechanism by name recognition rather than by requirement: proposing an external-object/real-time-connect approach for a high-volume nightly write, using record-level synchronous calls for a million-record load, or using outbound messages when the client needs a response, guaranteed ordering or error handling.
Every mechanism is described in similar 'connect Salesforce to another system' language, and the real differentiators - volume, direction, synchronicity and whether data is persisted - are not stated in the option text.
What to do instead
Classify the requirement first: volume and frequency, direction, synchronous versus asynchronous, whether a response is needed, and whether the external data must be stored in Salesforce. Then map to bulk loading for large data volumes, record-level synchronous APIs for real-time single-record calls, platform events for event-driven async patterns, outbound messages for fire-and-forget with retry but no response, and external objects for real-time reads of data you do not want to copy in.