Integration And Data Management practice questions

Role hierarchy bypass rules

Why it fails: Incorrect. Role hierarchy bypass rules do not exist as a standard Salesforce configuration option.

Public Group territory assignment

Why it fails: Incorrect. Territory management is designed for sales alignment, not basic queue-based case visibility.

Manual sharing by agents

Why it fails: Incorrect. Manual sharing relies on individual agents and does not automatically secure queue records reliably.

Sharing Settings -> Account Sharing Rules -> Default Access

Why it fails: Account Sharing Rules grant access to defined groups of users; they do not make children inherit parent sharing. They are tempting because they are the usual tool for extending account access, but automatic inheritance is a hierarchy behaviour enabled in Organisation-Wide Defaults, not in sharing rules.

Organization-Wide Defaults -> Account Hierarchies settings

Why it fails: Incorrect. Account hierarchy access can be configured via 'Contact Access' linked to Account, but automatic inheritance uses sharing rules or parent access toggles.

Enterprise Territory Management Setup

Why it fails: Enterprise Territory Management assigns accounts to territories for reporting and forecasting; it does not propagate sharing from parent to child accounts. The tempting fit is its hierarchy handling, but the actual mechanism for inheritance is the Account Role Hierarchy or a sharing rule with portal/role-based hierarchy, not territory setup.

Salesforce-to-Salesforce connection

Why it fails: Incorrect. S2S is for peer-to-peer Salesforce org communication, not custom third-party billing integrations.

Outbound Message with Workflow Rule

Why it fails: Incorrect. Outbound messages are asynchronous and fire XML payloads; they cannot synchronously populate UI fields.

Bulk API 2.0 job export

Why it fails: Incorrect. Bulk API is designed for asynchronous batch processing of large data volumes, not real-time UI calls.

Roll-up Summary field

Why it fails: Roll-up summary fields aggregate child record values onto a parent, so they cannot surface related Contact details in a console subtab. It is tempting because roll-ups link parent and child objects, and would be correct for totalling child records, but console subtabs require a lookup or master-detail relationship for navigation.

Cross-object formula field

Why it fails: A cross-object formula field only displays values pulled from a parent record; it cannot create the child relationship or subtab navigation the console needs. It is tempting because formulas surface related data, but the correct choice is a lookup or master-detail relationship, which actually establishes parent-child structure.

External ID text mapping

Why it fails: An external ID is a text field holding a unique identifier from another system for upserts and integrations; it establishes no parent-child relationship, so no related-list subtab can appear. It tempts consultants working with integrated data, but a lookup or master-detail relationship is what drives console subtab navigation.

Formula (Text) and Unique

Why it fails: A Formula (Text) field cannot be marked as an External ID; Salesforce restricts that attribute to custom text, number and email fields, and formula fields are recalculated rather than stored for matching. External IDs suit upsert keys, which is why a plain Text field with External ID and Unique is required here.

Master-Detail relationship

Why it fails: Master-Detail relationship is a field type defining parent-child sharing and cascade behaviour, not an attribute applicable to an external ID field. External IDs are configured on custom text, number or email fields to enable upsert matching; relationship type is irrelevant to matching legacy ticket IDs during batch loads.

Auto-Number and External ID

Why it fails: Auto-Number fields are system-generated and read-only, so Salesforce cannot accept the incoming legacy ticket ID value for matching; Auto-Number also cannot carry the External ID attribute. A writable Text field marked External ID and Unique is what enables upsert matching on external keys.

Public Group membership rules

Why it fails: Incorrect. Public groups group users together but do not filter record access without sharing rules.

Organization-Wide Default modification to Public Read/Write

Why it fails: Incorrect. Making OWD public read/write would open access to all users, violating the restriction requirement.

Manual sharing via user profile assignment

Why it fails: Incorrect. Manual sharing is performed on individual record detail pages, not automatically via profiles.

A standard Auto-Number field

Why it fails: Incorrect. Auto-number fields are generated by Salesforce and cannot be populated with external system keys.

A cross-object formula field

Why it fails: Incorrect. Formula fields are read-only and cannot be used as target keys for data upserts.

A master-detail relationship field

Why it fails: Incorrect. Master-detail fields establish parent-child object ownership, not external integration key matching.

Territory Management assignment rules

Why it fails: Incorrect. Territory management organizes accounts and users, not live chat routing transcripts.

Standard Email-to-Case routing addresses

Why it fails: Incorrect. Email-to-Case processes inbound emails, not live chat transcripts.

Bulk API data import wizard

Why it fails: Incorrect. Bulk API is for asynchronous batch data loads, not live chat session mapping.

Sharing rules automatically bypass all profile-level Field-Level Security restrictions.

Why it fails: Incorrect. Sharing rules govern record access, whereas Field-Level Security governs field visibility.

Sharing rules execute synchronously in real-time before record creation triggers.

Why it fails: Incorrect. Sharing rule recalculation is processed asynchronously by the sharing rule evaluation engine.

Standard outbound email handlers for REST query responses.

Why it fails: Outbound email handlers send notifications outward; they cannot serve query responses to external systems requesting Case data. It tempts because email can carry payloads, but real-time querying requires callable APIs such as REST, SOAP, or Bulk API, which return structured records on demand.

Chatter REST API for updating standard object page layouts.

Why it fails: Chatter REST API exposes feeds, users, and groups; it does not update page layouts, which are metadata configured in Setup, and it cannot query Case records for external systems. It tempts as a REST-family API, but real-time Case querying needs REST, SOAP, or Bulk API against the data.

Schedule a nightly batch job to fetch scores and update a custom field on the Case.

Why it fails: A nightly batch job stores the scores in Salesforce, which violates the requirement not to store them. It also does not provide real-time data; scores would be up to 24 hours old. This approach is unsuitable for frequently changing data that must be displayed in real time.

Salesforce Connect with an OData adapter to create an external object for the scores.

Why it fails: Salesforce Connect external objects are read-only and can display external data, but they require the external system to support OData or a similar protocol. The external system here exposes a REST API, not OData. While you could build a custom adapter, that is complex. Also, external objects appear as related lists or tabs, not directly as fields on the Case detail page without additional configuration.

Create a custom Lightning component that makes a client-side callout to the REST API and displays the score on the Case page.

Why it fails: Client-side callouts from Lightning components are subject to CORS and CSP restrictions and require the external endpoint to be added to CSP Trusted Sites. They also expose the API to the browser, which may have security implications. While possible, it is not the most robust or recommended approach for real-time data on a detail page, especially if the API requires authentication secrets.

A Data Loader command-line process using the insert operation with the 'Use Bulk API' option unchecked

Why it fails: Data Loader without Bulk API uses the SOAP-based batch interface, which is slower and less scalable for hundreds of thousands of records. It also does not expose the specific job-level options to suppress assignment, auto-response, and workflow rules in the same way Bulk API 2.0 does. This choice risks the maintenance window and does not guarantee the required rule suppression.

REST API composite requests sent in parallel from the middleware with all rules left active

Why it fails: The REST composite API is suited for smaller, transactional volumes and has stricter request size and record count limits. Sending 250,000 records through composite calls would be slow and could hit API request limits. Leaving rules active would also fire assignment and auto-response logic, which the scenario explicitly forbids, so this option fails on both volume and side-effect requirements.

SOAP API with the AllOrNone header set to true and rules suppressed through a custom setting

Why it fails: SOAP API can process records but is not optimized for very large asynchronous loads and lacks the Bulk API job-level rule suppression options. A custom setting cannot disable assignment, auto-response, or workflow rules during a load; those are controlled by API options. This combination would be slow at this volume and would not reliably prevent the unwanted rule executions.

Raise the API request limit for the integration user's profile so all 500,000 records submit in a single request.

Why it fails: API request limits govern the number of calls per 24-hour period, not the size of an individual payload, and Bulk API 2.0 already handles large volumes within standard entitlements. Adjusting limits does not resolve duplicate Case Numbers or malformed dates and would not prevent record-level failures. This distractor confuses call-count governance with data-quality controls.

Enable the 'Assignment Rule' on the job so records are routed to the correct queue during ingestion.

Why it fails: Assignment rules are not a Bulk API ingestion setting and are not applied to records loaded through the API unless explicitly triggered by workflow logic; they also do nothing to address duplicate Case Numbers or malformed dates. Relying on routing here misdirects the design away from data quality, and routing a closed historical case to a queue would be operationally wrong anyway.

Split the file into batches under 10,000 records and submit each as a separate Bulk API 2.0 job to avoid governor limits.

Why it fails: Bulk API 2.0 automatically chunks a job into batches and is designed for very large volumes, so manual splitting is unnecessary and adds operational overhead. The real failure risk in this scenario is duplicate matching and invalid dates, not job size. Splitting the file does not improve data quality and complicates monitoring and retry logic.

Schedule a nightly Data Loader export of subscription tiers into a custom field on the Account.

Why it fails: This approach stores the data in Salesforce, directly violating the requirement that the value never be persisted. It also introduces staleness, since agents would see yesterday's tier rather than the current value. Data Loader is a batch tool, not a real-time rendering mechanism, so it fails both the storage and the freshness constraints of the scenario.

Create an External Object and relate it to Case, then add a related list to the Case Lightning page.

Why it fails: External Objects use Salesforce Connect to surface external data without storing it, but they require an OData or custom adapter, an external data source definition, and often an indirect lookup relationship. That is significantly more setup and ongoing maintenance than a simple callout for one field. It also exposes a related list rather than a single inline value, which does not match the stated rendering requirement.

Configure a Salesforce-to-Salesforce connection and subscribe to the subscription platform's published tier field.

Why it fails: Salesforce-to-Salesforce is designed to share records between two Salesforce orgs, not to consume a REST endpoint from an arbitrary external platform. It also replicates records into the subscriber org, which contradicts the no-storage requirement. This option misapplies an org-to-org feature to an external system integration and would not render a live value on the Case page.

Configure an Outbound Message on Case update and point it at the analytics platform's REST endpoint.

Why it fails: Outbound Messages send SOAP messages to an endpoint but offer no retry-on-throttle behavior and no ordering guarantee for rapid successive updates. They are also fire-and-forget, so a throttled 429 simply drops the notification with no recovery path. This option does not provide the retry mechanism the scenario explicitly requires.

Invoke the callout synchronously in an after-update Apex trigger and retry in a loop until a 200 response is received.

Why it fails: Synchronous callouts in triggers are prohibited by the platform and would block the agent's save regardless. Retrying in a tight loop would also consume the callout limit and potentially hit the 120-second transaction ceiling. This design guarantees a poor agent experience and still loses updates when the external system stays throttled, so it does not meet the requirements.

Enable Change Data Capture on Case and let the analytics platform subscribe to the event stream directly.

Why it fails: Change Data Capture publishes field-level change events that external subscribers can consume, but the scenario requires the integration to push updates and handle the external platform's throttling. If the analytics platform is the throttling party and does not retry, updates are still lost. CDC also does not provide a Salesforce-side retry ledger, so failures cannot be tracked or replayed from within Service Cloud.

Data Loader with the 'Insert' operation, using the Account Number to look up the Account ID via a SOQL query.

Why it fails: Using Data Loader with Insert and a separate SOQL query for each record would require many API calls and is inefficient for 100,000 records. Data Loader can perform lookups, but doing a query per record is not scalable. This approach would likely hit API limits and is not the best practice for bulk data loads.

REST API with parallel requests, each containing 200 records, and using the Account Number to set the lookup relationship.

Why it fails: While REST API can handle parallel requests, it still requires many calls and does not natively support relating records via an external ID without additional queries. Bulk API 2.0 is specifically optimized for this scenario and reduces API call consumption. REST is not the most efficient choice for this volume.

SOAP API with a single call containing all 100,000 records in one request.

Why it fails: The SOAP API has limits on request size and is not intended for such large volumes in a single call. It would likely time out or exceed governor limits. SOAP API is better suited for smaller, real-time transactions, not nightly bulk loads of 100,000 records.

Schedule a daily batch job to copy all external articles to custom objects

Why it fails: Batch copying external articles into custom objects duplicates content and cannot surface CMS results live in the global search bar; federated search queries the external repository at query time via a connector. Batch synchronisation suits offline reporting or data warehousing, not real-time unified search.

Build a custom Visualforce page overriding Global Search

Why it fails: A custom Visualforce page replaces the standard global search UI, so native Knowledge articles and external CMS results would not appear together in the standard search bar agents use. Visualforce overrides suit bespoke interfaces, not extending federated search, which uses a search connector.

Deploy a Salesforce-to-Salesforce connection

Why it fails: Salesforce-to-Salesforce shares records between two Salesforce orgs, not an external CMS, so it cannot index or return CMS articles in global search. It is the right choice for cross-org record and Chatter collaboration, not federated search integration.

Encrypted Custom Objects with restricted page layouts

Why it fails: Encrypted custom objects store new data; they cannot relocate existing Case records, so storage and report performance stay unchanged. It is tempting because encryption and restricted layouts suggest controlled read-only auditing, but archiving requires moving records, which only the native archiving capability performs.

External Objects via Salesforce Connect

Why it fails: Salesforce Connect external objects query data held in an external system, so Cases would remain in Salesforce storage and continue affecting reports. It is tempting because external objects give read-only access, but the stem requires removing records from primary storage, which only native archiving achieves.

Standard Case Archiving Batch Job

Why it fails: No standard Case archiving batch job exists in Salesforce; archiving is a licensed add-on with its own setup, not a built-in scheduled batch. It is tempting because a batch job sounds like native automation, but the stem's requirement is met by the dedicated archiving feature, not a standard job.

Batch Data Integration via Data Loader

Why it fails: Data Loader writes records into Salesforce objects, which contradicts the requirement to avoid storing external order history. It is tempting because batch loading is the standard route for migrating or syncing large record volumes when persistence in Salesforce is actually wanted.

Bulk API REST queries

Why it fails: Bulk API REST queries extract Salesforce records in batches; they cannot surface external order data and require the records to exist in Salesforce. It is tempting because Bulk API is the correct tool for high-volume data retrieval from Salesforce itself, not for live external display.

Standard outbound messages

Why it fails: Outbound messages push Salesforce record data out to an external endpoint on a trigger; they cannot retrieve and render external order history in the console. Displaying external data without storing it requires an external data source with Salesforce Connect. Outbound messages suit one-way notifications to external systems.

Salesforce Connect external object lookup

Why it fails: Salesforce Connect external objects query the remote system on demand through OData or cross-org adapters, adding callout latency and requiring the telephony system to expose a queryable endpoint; screen pops need an inbound push within milliseconds. It would be correct for surfacing external records read-only inside Salesforce.

Batch data upload via Bulk API

Why it fails: Bulk API processes records asynchronously in large batches, so screen-pop data would arrive minutes after the call ends rather than during ringing. It is tempting because it moves high volumes of telephony records into Salesforce efficiently, and would be correct for nightly reconciliation or historical call-log loading.

Scheduled email notification service

Why it fails: Scheduled email notifications deliver on a time trigger, not on an inbound call event, so no screen pop can occur while the customer is waiting. It is tempting because it needs no integration code and would be correct for periodic agent summaries or shift reports rather than real-time CTI events.