Create a report combining data from the Account standard object and the Invoices external object.

Create a Visualforce page combining Salesforce Account data and Invoice external object data.

Explanation:

✅ Correct Answers:

B. Report across Account and Invoices external object.
External objects can participate in Salesforce reports when they are related through either an External Lookup or Indirect Lookup relationship. If the Invoice external object is linked to Account, users can build a single Salesforce report that shows both Account data and related Invoice data side by side. This provides a unified reporting experience directly in Salesforce without needing extra tools.

C. Visualforce page combining data.
Sometimes reporting limits apply—for example, if the external object relationship isn’t configured correctly or reporting performance is poor. A Visualforce page (or Lightning component) can be built to query both Account records and Invoice external objects, then display the results together. This gives developers flexibility to control layout, data joins, and performance beyond what standard reporting can do.

❌ Incorrect Answers:

A. Report in an external system.
While technically possible, this takes users out of Salesforce and requires integration into an ERP or BI tool. The requirement clearly says the data should appear in one place in Salesforce, so this option doesn’t satisfy the business ask.

D. Dashboard combining two separate reports.
Dashboards in Salesforce can put multiple charts or tables next to each other, but they don’t merge the datasets. The user would see one panel for Accounts and another for Invoices, which is visually together but not functionally a single report. This falls short of the “one report” requirement.

Reference:
Salesforce Documentation: External Objects and Reporting

Import Account records first followed by order records after sorting orders by AccountID.

Explanation:

When loading data into Salesforce, record locking happens at the parent level in master-detail relationships. Every time a child record is inserted or updated, Salesforce locks the parent record to maintain data consistency. If you load millions of order records randomly, multiple threads may try to lock the same Account at the same time, causing lock errors.

By sorting order records by AccountID, you group all the child records belonging to one Account together. That means when Salesforce processes the data, it locks one Account, inserts all related child orders, then releases the lock before moving on to the next Account. This approach keeps the process orderly and prevents multiple threads from fighting over the same parent record.

Incorrect Answers:

A. Sorting by OrderID.
This doesn’t solve the problem because OrderID is unique to each order and has no connection to the parent Account. You could still end up with child records for the same Account scattered across the load, leading to multiple simultaneous lock attempts.

C. Switching to Lookup temporarily.
While technically possible, this creates unnecessary risks. Converting relationships back and forth could affect roll-up summary fields, sharing rules, and data integrity. It’s an extreme workaround compared to simply sorting the data properly.

D. Separate imports with Apex to populate AccountID.
This is inefficient and overly complex. You’d first import orders without linking them to Accounts, then run Apex to associate them later. It introduces extra processing and still doesn’t inherently solve lock contention—it just moves the issue into Apex logic.

Reference:
Salesforce Help: Avoiding Record Locking Issues During Data Loads

Person Accounts

Explanation:

A data architect at a large B2C retailer needs to model the consumer account structure in Salesforce. B2C businesses primarily interact with individual consumers, not companies. The standard Salesforce data model separates Accounts (companies) and Contacts (people), which is ideal for B2B. For B2C, a different approach is needed to represent a single person as both the customer and the contact.

Correct Option

✅ D. Person Accounts
Person Accounts are a special type of account designed specifically for the B2C (Business-to-Consumer) model. A Person Account combines the attributes of a standard Account and a Contact into a single record, making it the perfect solution for modeling individual consumers. This unified record simplifies data management, streamlines reporting, and provides a clear, single view of the customer, which is essential for a B2C business where the "Account" is the "Person."

Incorrect Options

❌ A. Individual Accounts
Individual Accounts are not a standard Salesforce feature; they are a custom naming convention or record type often used in conjunction with a B2B model, where each "Account" represents a person rather than a company. This approach can lead to data integrity issues and is not the native, supported way to handle B2C relationships. Person Accounts are the standard Salesforce feature for this use case.

❌ B. Account Contact
"Account Contact" is not a standard feature or a data object in Salesforce. This likely refers to the standard Account-Contact relationship, where a Contact is a person associated with a business Account. This model is designed for B2B scenarios and is not suitable for a B2C retailer, where the individual consumer is the core of the business relationship.

❌ C. Contacts
While Contacts represent people, they cannot exist in Salesforce without being related to an Account. A B2C retailer could not simply use the Contact object on its own, as it would violate the core data model. Every Contact must have an associated Account, which would force the B2C company to create a dummy account for every single person, leading to a messy and inefficient data structure.

Reference
Salesforce Help Article: When to Use Person Accounts

Leverage picklist and lookup fields where possible

Leverage validation rules and workflows.

Explanation:

Universal Containers (UC) is moving to Salesforce and wants to prevent bad data from entering the system from both users and external integrations. Data quality is critical for accurate reporting, sales forecasting, and business processes. A data architect needs to implement a layered approach to data validation and governance using Salesforce's native capabilities to ensure the integrity and reliability of the data from the point of entry.

Correct Options

✅ A. Leverage picklist and lookup fields where possible.
Using picklist and lookup fields is a fundamental strategy for improving data quality. Picklists restrict user input to a predefined list of values, preventing typos and inconsistent data entry. Lookup fields link records to a parent record, enforcing a relationship and ensuring that a user can only select an existing, valid record (e.g., a contact, account, or custom object). This standardizes data and reduces manual errors.

✅ C. Leverage validation rules and workflows.
Validation rules are essential for enforcing business logic and ensuring data quality at the record level. They prevent users from saving a record that doesn't meet specific criteria, such as a required field being empty or a date being in the past. Workflows, while being phased out in favor of Flow, have historically been used to automate data-related actions like updating fields to standardize data after a record is saved. Together, these tools enforce data standards and catch common errors.

Incorrect Options

❌ B. Leverage Apex to validate the format of data being entered via a mobile device.
While Apex is a powerful tool for complex validation, it's generally not the first or only solution a data architect should recommend for a common problem like data quality. Built-in Salesforce features like validation rules and picklists are a declarative, low-code approach that should be used first. Using Apex for a simple validation is often overkill and requires more development and maintenance.

❌ D. Leverage third-party- AppExchange tools.
AppExchange tools can be very effective for advanced data quality issues, such as de-duplication, address verification, and data enrichment. However, they are a supplemental solution, not the primary, and often come with additional costs. A data architect should first recommend leveraging Salesforce's native, out-of-the-box features like picklists and validation rules, which are foundational for any data quality strategy and are included with the platform.

Reference
Salesforce Help Article: Data Quality Best Practices

Utilize a Validation Rule with a REGEX operator on Postal Code.

Utilize a Validation Rule with a CONTAINS operator on address fields.

Explanation:

Cloud Kicks faces data quality issues with Invoice records, as missing States and incorrectly formatted Postal Codes affect Accounting. To improve, they need solutions that enforce consistent data entry without overcomplicating processes. Validation rules are ideal for ensuring accurate State and Postal Code formats, maintaining data integrity efficiently while aligning with Salesforce’s best practices for custom objects.

Correct Option: 🅲 Utilize a Validation Rule with a REGEX operator on Postal Code
A validation rule with a REGEX operator ensures Postal Codes follow a specific format (e.g., five digits for U.S. codes). This prevents incorrect entries before saving, improving data quality for Accounting. It’s lightweight, user-friendly, and avoids custom coding, aligning with Salesforce’s declarative tools. By enforcing format consistency, it directly addresses the issue of incorrectly formatted Postal Codes.

Correct Option: 🅳 Utilize a Validation Rule with a CONTAINS operator on address fields
A validation rule with a CONTAINS operator checks that State fields include valid values (e.g., a picklist or specific text). This ensures States are populated correctly, preventing missing data. It’s a simple, declarative solution that enhances data quality without complex logic, making it ideal for Cloud Kicks’ needs and maintaining usability for end users submitting invoices.

Incorrect Option: 🅰️ Change each address field to required on the Page Layout
Making address fields required on the Page Layout only enforces entry at the UI level, not during data imports or API updates. This doesn’t validate Postal Code formats or ensure valid States, potentially allowing incorrect data. It’s less robust than validation rules, which enforce data quality across all entry methods, making it inadequate.

Incorrect Option: 🅱️ Write an Apex Trigger to require all fields to be populated
An Apex Trigger to require all fields is overkill, as it requires custom coding and maintenance. It’s less flexible than validation rules and could reject valid records if non-essential fields are blank. This approach is complex, prone to errors, and not aligned with Salesforce’s preference for declarative solutions, making it unsuitable for Cloud Kicks’ data quality needs.

Reference
Salesforce Help: Validation Rules
Salesforce Trailhead: Data Quality