Contact Salesforce to enable Defer Sharing Rules

Explanation:

This question is about handling performance in large data volumes when complex sharing rules exist. With millions of Shipment records and many sharing rules, moving users between business areas means recalculating sharing for a huge number of records, which can take excessive time. Salesforce provides a feature called “Defer Sharing Calculations” to address this issue.

🟢 Correct Option

D. Contact Salesforce to enable Defer Sharing Rules
Defer Sharing Rules lets administrators delay the recalculation of sharing after user or group membership changes. Instead of recalculating after every adjustment, changes can be made in bulk and then processed once, on demand. This avoids repeated expensive recalculations across millions of records and ensures performance stays manageable during high turnover of sales reps.

🔴 Incorrect Options

A. Implement data archiving for old Shipment records
Archiving can reduce overall record volume, but it does not address the core problem here, which is the cost of recalculating sharing rules whenever users move between groups. Even with fewer records, recalculation is still required, so this is not a reliable solution for the described challenge.

B. Contact Salesforce to create Skinny tables on Shipment
Skinny tables improve query performance by denormalizing frequently accessed fields, but they do not impact how sharing rules are calculated. Since the problem is about performance during reassignment and sharing recalculations, skinny tables have no effect here.

C. Configure shipment OWD to Public Read/Write
Changing OWD to Public Read/Write would remove the need for sharing rules, but it would also remove data security, exposing sensitive shipment data to all users. This violates the business requirement of maintaining restricted access and is not an acceptable solution.

Reference:
Salesforce Help: Deferred Sharing Rule Calculation

Build a batch join to move two-year-old records off platform, and delete records from Salesforce.

Explanation:

Why archive data?
Archiving is crucial for managing data growth, maintaining platform performance, and reducing storage costs. By moving inactive or old data out of the live Salesforce org, you can free up valuable storage space and keep your Salesforce instance running efficiently.

What data should be archived?
A data archiving strategy should define what data is considered "old" or "inactive." This is often based on business rules, such as a time frame (e.g., data older than two years) or a status (e.g., closed cases, completed projects).

Where should archived data be stored?
Archived data is typically moved to an external database or a data warehouse. This can be an on-premise solution or a cloud-based service, like Amazon S3, Google Cloud Storage, or Microsoft Azure. The chosen solution should be secure, cost-effective, and provide easy access for future reporting or analysis needs.

How should data be moved?
The process of moving data from Salesforce to an external system requires a robust data integration strategy. This can be accomplished using:

➡️ ETL (Extract, Transform, Load) tools: These tools (e.g., Informatica, MuleSoft, or custom scripts) are designed to extract data from a source (Salesforce), transform it if needed, and load it into a destination (the archiving solution).
➡️ Salesforce APIs: The Bulk API is particularly useful for handling large volumes of data for both extraction and deletion.
➡️ AppExchange solutions: Many third-party solutions are available on the Salesforce AppExchange that specialize in data archiving and provide pre-built functionality for this purpose.
➡️ A well-designed archiving solution involves a clear, automated process: identify the data to be archived, extract it from Salesforce, store it securely in the external system, and then delete it from Salesforce to free up storage. The deletion step is critical and often overlooked, but without it, the primary goal of freeing up storage is not met.

🔧 For more information, you can explore the following topics in Trailhead and Salesforce documentation:
→ Large Data Volumes (LDV)
→ Data Archiving Strategies
→ Salesforce Bulk API
→ Data Migration and Integration
→ Salesforce Platform Data Architect Certification Guide

Utilize the Authorization Form Consent object to capture the consent.

Explanation:

✅ C. Utilize the Authorization Form Consent object:
This is correct. Salesforce provides a standard, ready-to-use object called AuthorizationFormConsent specifically designed to track customer consents for purposes like marketing. Using this native object ensures best practices and compliance without custom development.

❌ A. Use custom fields...:
This is incorrect. While adding a single checkbox field is simple, it lacks the robustness to properly track consent details like the consent date, expiration, version of the form, or the channel it was collected through.

❌ B. Create a custom object...:
This is incorrect. Although a custom object could be built to replicate the functionality, it is unnecessary. Salesforce already offers a standard object for this exact purpose, which saves development time and aligns with platform best practices.

❌ D. Use AppExchange solution...:
This is incorrect. While AppExchange solutions exist, it is not the first recommendation. Before seeking a third-party paid tool, a data architect should always evaluate if Salesforce's native functionality can meet the requirement, which it can in this case.

Summary:
The requirement is to build a solution for capturing and managing customer marketing consent, which is a common regulatory need (like GDPR). The solution must natively handle consent details like status, date, and channel.

Reference:
Salesforce Help: About the Consent Data Model

Put the business purpose in the Description of each field.

Maintain a data dictionary with the justification for each field.

Explanation:

This question addresses the principles of data governance, documentation, and maintaining clarity between business requirements and technical implementation over time.

Why B is Correct: Using the Description field on every object and field is a fundamental and easily accessible form of documentation. It is stored directly in the metadata, making it visible to any admin or developer working in the org's setup. This provides immediate context for what a field is for and why it exists, directly linking it to its business requirement.

Why C is Correct: A Data Dictionary is the comprehensive, single source of truth for an organization's data assets. It provides a detailed view that goes beyond the field description, including information like data owners, data sensitivity, approved values, and the specific business requirement that justified the field's creation. This is essential for tracing changes back to original requirements, especially during a long, phased project.

Why A is Incorrect (Setup Audit Trail): The Setup Audit Trail is a fantastic tool for tracking who made a change when and what the change was. However, it does not track the why. It will show that a field was created, but it cannot trace that action back to the detailed business requirement that justified it.

Why D is Incorrect (Save metadata in source control): Using source control (e.g., Git) is a development best practice for tracking changes to metadata over time and managing deployments. However, like the Setup Audit Trail, it tracks the what and the how of a change, not the business reason why the change was made. The requirement justification must be documented within the metadata itself (Description) or in a companion document (Data Dictionary).

Reference: A core responsibility of a Data Architect is to ensure data is well-documented and traceable. This is achieved by embedding documentation in the org (Descriptions) and maintaining external governance artifacts (Data Dictionary).

Ask support to create a skinny table for Application with the necessary reporting fields.

Add custom indexes to the Date fields used for filtering the report.

Explanation:

✅ Option A: Ask support to create a skinny table for Application with the necessary reporting fields.

Why it’s correct: A skinny table is a Salesforce feature designed to improve performance for large data volumes, especially for reporting and querying. It’s a custom table maintained by Salesforce that includes a subset of fields from the original object (in this case, the Application custom object) to reduce the need for costly joins and improve query speed. For an object with tens of millions of records, like UC’s Application object, skinny tables are particularly effective when reports or queries frequently filter on specific fields (e.g., date fields). By contacting Salesforce Support to create a skinny table with the necessary reporting fields, UC can significantly enhance performance for date-range-based reports.

Example: Imagine a library with millions of books. Instead of searching the entire library for books published in the last 5 years, a skinny table is like a pre-organized shelf with only the relevant books and their key details, making searches faster.

Context: Skinny tables are particularly useful for objects with high data volumes and frequent reporting needs, as they bypass standard indexing limitations and optimize query execution.

✅ Option D: Add custom indexes to the Date fields used for filtering the report.

Why it’s correct: Custom indexes improve query performance by allowing Salesforce to quickly locate records based on specific field values, such as dates used in report filters. Date fields are commonly used in filters for reports (e.g., “show records from the last 5 years”), and indexing these fields ensures that queries run more efficiently, especially on large datasets like UC’s Application object with tens of millions of records. UC can request Salesforce Support to create custom indexes on the Date fields used in their reports, reducing query execution time.

Example: Think of an index like a book’s table of contents. Without it, you’d need to scan every page to find a topic. With an index, you can jump directly to the relevant pages, saving time.

Context: Salesforce automatically indexes certain fields (e.g., Id, Name), but for non-standard fields like custom Date fields, a custom index must be requested through Salesforce Support.

Incorrect Answers

❌ Option B: Add custom indexes to all fields on Application without a standard index.

Why it’s incorrect: Adding custom indexes to all fields without a standard index is not a practical or recommended approach. Indexes are resource-intensive, and Salesforce limits the number of custom indexes per object. Indexing every field without a standard index would likely exceed these limits and may not address the specific performance issue, which is tied to date-range filtering. Additionally, indexes are most effective when applied to fields frequently used in filters, sorts, or lookups, not indiscriminately to all fields.

Common Misconception: Some might think indexing all fields maximizes performance, but this overlooks the fact that unnecessary indexes consume resources and may not improve query performance for fields rarely used in reports.

❌ Option C: Run multiple reports to get different pieces of the data and combine them.

Why it’s incorrect: Running multiple reports and combining them manually is not an efficient or scalable solution for improving report performance. This approach increases complexity, requires additional user effort, and doesn’t address the root cause of the performance issue (inefficient querying on a large dataset). It’s a workaround rather than a technical solution, and it may lead to errors or inconsistencies when combining data.

Common Misconception: Users might assume breaking reports into smaller pieces inherently improves performance, but this doesn’t optimize the underlying query execution and can create additional overhead.

Reference
Salesforce Documentation:
→ Working with Very Large SOQL Queries – Discusses skinny tables and custom indexes for optimizing performance with large data volumes.
→ Custom Indexes – Explains how to request custom indexes through Salesforce Support.
→ Skinny Tables – Describes how skinny tables can improve performance for large datasets.

Trailhead Module: Data Modeling for Large Data Volumes – Covers best practices for handling large datasets in Salesforce.