Consulting Practices practice questions

Rely solely on user training and internal policy agreements to ensure reps do not access unauthorized regional data.

Why it fails: Policy and training create no technical enforcement, so out-of-region reps retain record access through sharing settings. It is tempting because it is cheap and fast, and it suits low-risk internal governance. The correct approach combines a data-protection consulting assessment with Salesforce Shield Platform Encryption and restriction rules.

Deploy custom Apex triggers to delete prospect records immediately upon creation if created by out-of-region users.

Why it fails: Deleting prospect records on creation destroys legitimate North American pipeline data and breaches audit and retention obligations; it also fails to restrict viewing. It is tempting as a blunt enforcement mechanism. The correct combination is a privacy consulting assessment plus field-level security, restriction rules or Shield Platform Encryption.

Create a single global profile and assign all users to the same public group to simplify role maintenance.

Why it fails: A single profile with one public group grants every user identical record visibility, directly violating the regional restriction the European council demands. It is tempting because it minimises role maintenance overhead. The correct approach uses role hierarchy, sharing rules and profiles scoped by region alongside a data-protection consulting assessment.

Hiding the Convert button using page layout assignments for all profiles.

Why it fails: Hiding the Convert button via page layouts is cosmetic; profiles can still convert through other entry points, and mandatory Budget and Authority fields remain unenforced. It tempts because it is declarative and quick, but validation rules or required-field configuration on the Lead object enforce the actual data requirement.

A custom Apex trigger that deletes unverified Leads.

Why it fails: A trigger cannot enforce a pre-conversion gate declaratively; it deletes records after the fact rather than blocking conversion, and Apex is not declarative. Validation rules on Lead fields are the declarative mechanism that prevents conversion until Budget and Authority are populated. Triggers suit complex programmatic logic, not field-level entry gating.

Salesforce Surveys sent automatically when a Lead is created.

Why it fails: Surveys collect feedback and cannot block the Convert button; they run asynchronously after creation and never gate the conversion action. Validation rules on the Lead object are the declarative feature that stops conversion until Budget and Authority are populated. Surveys would be the right choice for gathering customer satisfaction data post-interaction.

Enable Just-in-Time (JIT) provisioning for the SAML SSO configuration so that user records are created and updated on first login from the IdP.

Why it fails: JIT provisioning creates or updates Salesforce user records at login based on SAML assertions, but it cannot deactivate users when they leave the company. The client explicitly requires automated deactivation driven from the HR system, which JIT does not provide. Recommending JIT alone would fail the deprovisioning requirement and leave terminated employees with active Salesforce access, violating the security policy.

Enable Delegated Authentication by pointing Salesforce to the corporate IdP's SOAP endpoint so that password validation occurs outside Salesforce.

Why it fails: Delegated Authentication is a legacy mechanism that validates passwords against an external service but does not provide modern SAML 2.0 federation, and it is not suitable for a new enterprise deployment. It also does not handle user provisioning or deactivation from the HR system. The client's requirement for SAML 2.0 SSO makes this option technically misaligned with the stated security policy.

Create a scheduled Apex job that reads a CSV export from the HR system and performs DML on User records nightly to deactivate terminated employees.

Why it fails: A custom Apex job is a bespoke integration that adds maintenance cost and risk, and it does not address authentication via the corporate IdP. The client's policy requires SSO through the existing identity provider, which this option ignores. While it could technically deactivate users, it is not the recommended or supported enterprise pattern when a SCIM-based identity integration is available.

Escalate the conflict immediately to the executive steering committee for a top-down mandate.

Why it fails: Escalating straight to the steering committee bypasses the analysis needed to reconcile stage definitions and probability mappings, and forces a mandate before options are understood. It tempts because executives can arbitrate deadlocks, but that is warranted only after the consultant has documented impacts and proposed a standardised model.

Configure separate custom Opportunity processes and record types for each region without questioning the differences.

Why it fails: Creating regional record types and processes without probing the conflicting definitions leaves the underlying business disagreement unresolved, so probability reporting stays inconsistent across regions. It is tempting because record types and sales processes genuinely segment divergent regional sales motions — the right choice once stakeholders have agreed the stage model.

Default all probability percentages to zero until a quantitative analysis of historical win rates can be performed.

Why it fails: Zeroing every probability percentage discards forecast accuracy and breaks Opportunity Stage-to-probability mapping, which the stem's conflict actually concerns. It appeals because historical win-rate analysis can calibrate probabilities, but that analysis informs agreed values rather than justifying blanking them during requirements gathering.

Disable offline access and block all local computer file storage across the company network.

Why it fails: Blocking offline access and local storage removes the workarounds without giving reps a workable alternative, driving resistance rather than adoption. Such controls suit security or compliance enforcement, not change management. Adoption needs training, visible sponsorship and incentives showing Salesforce meets reps' needs.

Revert all custom page layouts back to the standard Salesforce out-of-the-box defaults.

Why it fails: Reverting to standard layouts discards the customisations built to match sales processes, so reps lose functionality and revert to spreadsheets. Standard defaults suit fresh, unconfigured orgs. Low adoption here stems from behaviour and enablement, addressed through training, communication and sponsor engagement.

Send out a mandatory email warning reps that spreadsheet usage will result in disciplinary action.

Why it fails: Threatening discipline punishes the symptom without removing the reason reps keep spreadsheets, breeding distrust of the rollout. Disciplinary escalation suits deliberate policy breaches, not adoption gaps. Effective change management uses training, sponsor advocacy and demonstrating Salesforce's value in reps' daily workflow.

Reject the request outright since the Design phase has been officially signed off by the steering committee.

Why it fails: Rejecting outright ignores the change control process, which requires assessing impact on scope, timeline and cost before a decision. It tempts as a defence of signed-off baselines, but a formal change request with impact analysis is the correct route, not refusal.

Immediately configure the changes in the sandbox to delight the stakeholder and keep testing on schedule.

Why it fails: Configuring immediately bypasses change control, so the added validation rules and altered Lead Conversion mapping go untested against agreed scope, budget and timeline. It tempts because responsiveness pleases stakeholders, but changes must first be logged, impact-assessed and approved before configuration.

Instruct the stakeholder to submit the change as a post-go-live enhancement request after the initial deployment.

Why it fails: Deferring to post-go-live leaves UAT validating a process the business no longer wants, and the two validation rules and mapping change may invalidate test scripts. It tempts to protect the schedule, but the change control process should assess it now, not automatically postpone it.

Set up five separate linear Approval Processes linked together through sequential entry criteria.

Why it fails: Five chained Approval Processes cannot implement dynamic routing on margin thresholds; entry criteria only gate sequential submission, so tier and margin logic would be fragmented and unmaintainable. Chaining is tempting because linear approvals suit simple sequential sign-off, but not a five-tier matrix with conditional routing.

Advise the client to purchase a third-party CPQ application from AppExchange to handle all approval workflows.

Why it fails: A third-party CPQ application replaces quoting and approval functionality wholesale, imposing licensing, migration and integration cost that this approval-matrix requirement alone does not justify. It is tempting because AppExchange CPQ handles complex approval hierarchies natively, and would be correct if the client also needed advanced product configuration, pricing and guided selling.

Design a custom Apex trigger and custom metadata framework to manage the approval routing dynamically.

Why it fails: A custom Apex trigger with custom metadata bypasses the declarative approval engine, so the client's administrators cannot maintain the matrix without developer involvement — exactly the concern raised. It is tempting because Apex handles arbitrary routing logic, and would be correct where no declarative mechanism can express the required conditions.

Export the entire schema into an unformatted CSV file without field descriptions.

Why it fails: An unformatted CSV of the schema strips field descriptions and relationships, so it cannot evidence configuration intent or support review before promotion. It is tempting because schema exports are quick and machine-readable, and would suit a technical backup or migration audit, not documentation for stakeholders validating sandbox configuration.

Record a video walkthrough of the sandbox setup and email it to the client admin.

Why it fails: A video walkthrough is unstructured, unsearchable and unversioned, so it cannot serve as the authoritative configuration record reviewers compare against staging and production. It is tempting because walkthroughs convey context quickly, and would suit onboarding or handover training, not formal pre-promotion documentation.

Rely entirely on the automatically generated Salesforce release notes.

Why it fails: Salesforce release notes describe platform-wide changes, not the client's specific sandbox configuration, so they provide no traceability of what was built and why. They are tempting because they are automatically generated and free, and would be the right reference for assessing the impact of a seasonal release, not for documenting bespoke configuration.

Technical Specification and Deployment Plan

Why it fails: The technical specification and deployment plan documents target architecture, environments and release mechanics, not the client's existing processes or their shortfalls. It is tempting because it legitimately captures how the solution will be built and shipped, but as-is process analysis and gap identification sit in the current-state section.

System Architecture Diagram

Why it fails: A system architecture diagram depicts components, integrations and data flows, not narrative descriptions of existing business processes or the gaps they contain. It is tempting because it genuinely communicates technical landscape, but the as-is state and operational gaps are documented in the current-state business process section.

Data Dictionary and Object Model

Why it fails: The data dictionary and object model catalogues fields, entities and their relationships, not current-state processes or their gaps. It is tempting because it genuinely underpins integration and data-migration design, but the as-is analysis and gap identification belong in the current-state business process section of the FRD.

Review the existing legacy system code and database schema to determine object relationships.

Why it fails: Legacy code and schema reveal how the old system was built, not why the business needs change, so they cannot surface underlying requirements. It is tempting because data models genuinely inform migration and integration scoping later. During Discovery, open questioning about business outcomes and pain points is what exposes the true requirement.

Demonstrate standard Salesforce features immediately to validate their initial ideas.

Why it fails: Showing standard features steers stakeholders towards confirming existing preferences rather than articulating underlying needs, anchoring the discussion on the product. It is tempting because demos are a legitimate technique for validating a proposed design once requirements are known. Discovery interviews should first elicit business outcomes through open questions.

Ask stakeholders which exact page layouts and fields they want configured.

Why it fails: Asking for page layouts and fields captures stated configuration preferences, not the business problem driving them. It is tempting because such detail feels productive and speeds later build work. Discovery interviews should probe processes, goals and pain points first; layout decisions belong to design once requirements are understood.

Conduct a single 8-hour lecture covering every feature in Sales Cloud for all employees simultaneously.

Why it fails: A single eight-hour lecture ignores adult-learning principles and Sales Cloud role differences, producing poor retention and no practise. It is tempting because it delivers all content quickly to everyone at once, but instructor-led modular sessions with hands-on sandbox exercises and role-based paths suit enterprise software rollouts.

Rely entirely on Trailhead modules assigned as optional homework after go-live.

Why it fails: Optional Trailhead homework after go-live leaves adoption to chance, with no instructor-led practise, role-based scenarios or reinforcement during rollout. Trailhead suits self-paced enablement and certification prep, where learners already have access and motivation, not structured enterprise onboarding.

Provide a 500-page PDF user manual for self-study without any interactive sessions.

Why it fails: A 500-page PDF with no interactive sessions gives no hands-on practise, feedback or role relevance, so learners cannot rehearse their actual Sales Cloud tasks. Reference manuals suit lookup after training, not initial skill transfer during a rollout.

Create a free-text field on the Opportunity object for reps to type competitor names freely.

Why it fails: Free text cannot reconcile the differing team terminology, so the same competitor is recorded under multiple spellings and reporting breaks. A controlled picklist or custom Competitor object enforces one canonical value. Free text is right only when values are genuinely unique per record and never aggregated.

Require sales reps to send an email summary of competitors to the sales manager after every lost deal.

Why it fails: Emails sit outside the Opportunity record, so win/loss reasons cannot be reported or rolled up, and nothing normalises the teams' differing terminology. A structured field or custom object on the Opportunity captures that data. Email suits narrative context, not reportable structured data.

Create 50 individual checkbox fields on the Opportunity object representing every known competitor in the industry.

Why it fails: Fifty checkbox fields breach Salesforce's field-count limits and cannot be maintained as competitors change, and they still fail to normalise the differing team terminology. A custom Competitor object with picklist-driven win/loss reasons handles that vocabulary mapping; checkboxes suit a small, fixed, stable set of flags.

Allow all system administrators to make direct configuration changes in production as long as they document them in a spreadsheet.

Why it fails: Direct production edits bypass version control and deployment validation, so no auditable record links each metadata change to an approved source. It is tempting because spreadsheet logging feels like governance, and would suffice for a small team without DX, but it cannot enforce who may modify metadata.

Use change sets exclusively for all deployments, managed by a rotating roster of junior administrators.

Why it fails: Change sets cannot retrieve or deploy all metadata types and leave no branch history, so traceability across environments is incomplete; a rotating junior roster further weakens control. Change sets are tempting as the native no-tooling route, and would suit simple org-to-org promotions, not an enterprise DX governance requirement.

Lock down the production environment completely and perform all updates via direct developer console script execution.

Why it fails: Executing scripts directly in production leaves no versioned source, review or rollback path, so unauthorised metadata changes cannot be traced or prevented. It is tempting because Developer Console is always available for urgent fixes, and would suit a one-off hotfix, not a governed deployment strategy.

Rely on Einstein Forecasting to automatically override rep entries using machine learning without changing rep behavior.

Why it fails: Einstein Forecasting projects from existing opportunity data, so unpredictable close-date and amount edits still corrupt the forecast; it cannot override rep entries without behaviour change. It suits stable pipelines with disciplined data entry. The gap needs forecast categories, stage exit criteria and manager inspection.

Disable the ability for sales reps to edit Opportunity close dates and amounts under any circumstances.

Why it fails: Blocking edits entirely removes the reps' ability to reflect genuine deal changes, so forecasts become stale rather than accurate. It is tempting because forecast accuracy depends on data discipline, and locking fields would be the right response only where reps have no legitimate reason to revise close dates or amounts.

Set all Opportunity amounts to a fixed company average to eliminate variance.

Why it fails: Overwriting amounts with a company average destroys the pipeline value data that forecasting depends on, so revenue projections become meaningless. It is tempting because variance reduction sounds like stabilisation, and fixed values would suit only non-financial tracking where individual deal value is irrelevant.

Write an Apex batch job to automatically merge any accounts that share a similar name string upon insertion.

Why it fails: Matching on similar name strings merges distinct legal entities and cannot resolve conflicting addresses or reconstruct missing parent-child hierarchies, corrupting the account model. It tempts because Apex batch deduplication suits high-volume cleanup — correct once a survivorship ruleset and matching criteria have been defined with the business.

Delete all historical records older than 12 months to minimize migration complexity and storage consumption.

Why it fails: Deleting records older than 12 months destroys historical opportunity, contract and reporting data that Sales Cloud must retain, and does nothing about duplicates within the retained set. It appeals as a storage and complexity reduction tactic, which is valid only for genuinely obsolete data approved for archival by data owners.

Load all legacy records into production as-is, and let the sales reps manually clean up duplicates post-go-live.

Why it fails: Loading duplicates as-is pushes conflicting addresses and absent parent-child links into production, where reps cannot reliably reconcile them and forecasts, rollups and sharing break. It tempts because phased cleanup spreads effort, but that works only after deduplication and hierarchy mapping are completed in the migration.

Write a custom scheduled Apex batch that runs every midnight to re-assign all unassigned leads.

Why it fails: A nightly batch re-assigns leads hours after import, leaving them unassigned during peak processing and adding load rather than reducing it. It is tempting because batch Apex handles volume. The correct practice is to consolidate assignment rules and deduplicate before import, reducing cascading rule evaluations.

Upgrade the Salesforce edition to Unlimited to automatically bypass all CPU time and data processing limits.

Why it fails: Edition upgrades raise storage and API allocations, but governor limits on CPU time and synchronous processing remain fixed per transaction, so cascading rules still degrade imports. It tempts because Unlimited genuinely removes some platform caps, yet those caps are not the constraint here.

Disable all duplicate rules and assignment rules globally to maximize import speed.

Why it fails: Disabling duplicate and assignment rules removes the very routing and data-quality controls the business requires, and import throughput is governed by transaction CPU limits, not rule existence. It tempts as a quick throughput fix, but rules should be consolidated or reordered instead.

Tell the client that Salesforce has a strict hard limit of 50 custom fields per object.

Why it fails: Salesforce permits far more than 50 custom fields per object, so this invents a limit that does not exist and misleads the client. Citing a hard cap is tempting because it ends the debate quickly, but the accurate response is to challenge the requirement and prioritise genuinely needed fields rather than fabricate a platform constraint.

Immediately configure all 200 custom fields to satisfy the client's initial request fully.

Why it fails: Configuring all 200 fields immediately creates an unusable layout and entrenches unvalidated requirements before the client understands CRM data modelling. It tempts because rapid delivery appears responsive, and building fields is genuinely correct once requirements are confirmed and prioritised — but a first-time CRM user needs discovery and phased design first.

Ignore the request and build a generic page layout with zero custom fields.

Why it fails: A zero-field generic layout discards the client's stated business requirements entirely, leaving no data capture for their actual processes. It tempts as a reaction against over-customisation, and a standard layout is genuinely right as a starting baseline — but the correct approach is to prioritise and configure the fields that map to real, validated needs.

Force both teams to use the exact same 10-step sales process to maintain reporting consistency.

Why it fails: Forcing one 10-step process onto SMB reps imposes legal and security review stages they do not need, so their fast transactional deals stall. It is tempting because a single process simplifies reporting, but Sales Cloud supports multiple sales processes assigned by record type, letting each segment follow its own path.

Use custom validation rules that conditionally hide stages based on the logged-in user's shoe size.

Why it fails: Conditioning stage visibility on a user's shoe size references a field with no relationship to the sales methodology, so stages cannot be hidden meaningfully. It is tempting because conditional validation rules do control field and stage behaviour, but the correct approach assigns separate sales processes via record type per segment.

Build two completely separate custom objects for Enterprise Opportunities and SMB Opportunities.

Why it fails: Two separate custom objects fragment Opportunity reporting, forecasting and pipeline analytics, which the stem's segmentation does not require. It is tempting because distinct objects appear to isolate processes cleanly, yet Sales Cloud already supports multiple sales processes on one Opportunity object, selected by record type.

Purchase an expensive third-party enterprise resource planning analytics suite.

Why it fails: An ERP analytics suite reports financial and operational data, not Sales Cloud adoption or ROI. Salesforce-native tools such as CRM Analytics dashboards, reports and Adoption Dashboards track login rates, feature usage and pipeline metrics directly. It is tempting because ERP suites consolidate enterprise reporting, but they lack Sales Cloud usage telemetry.

Count the number of physical sticky notes stuck to computer monitors in the office.

Why it fails: Sticky notes capture no structured usage data, cannot be aggregated per user or per record, and leave no audit trail, so they cannot evidence adoption or ROI. They are tempting as a zero-cost, tangible proxy for activity, but the correct choice is Salesforce's native Adoption Dashboards and Reports, which quantify logins, record creation and feature usage directly.

Manually interview every sales rep every Friday afternoon about their CRM usage.

Why it fails: Friday interviews produce subjective, self-reported recollections that cannot be trended, scheduled or compared across the org, and they consume selling time weekly. They appeal because qualitative feedback feels rich, yet the requirement is measurable ROI and adoption tracking, which Salesforce Adoption Dashboards and standard Reports deliver automatically from actual usage data.

Public Groups with manual sharing sharing rules for every single record created.

Why it fails: Manual sharing rules apply per record, so they cannot scale to automatically restrict regional managers by branch while granting executives global visibility. It is tempting because manual sharing does grant record access, and it would be correct for one-off exceptions rather than a role-based, organisation-wide model.

Assigning the 'View All' permission on the Account object to all sales reps.

Why it fails: 'View All' on Account grants every sales rep access to all records, including other branches, directly contradicting the branch-level restriction. It is tempting because View All does satisfy the executives' global visibility requirement, and it would be correct if only leadership needed unrestricted access.

Custom Apex sharing code executed on every record insert without role structures.

Why it fails: Apex sharing code without role structures cannot enforce branch-based visibility, since sharing depends on a role hierarchy or territory model to determine which reps belong to which branch. It is tempting because Apex sharing does grant record access programmatically, and it would be correct for complex, non-hierarchical sharing beyond declarative rules.