SF-Data-Arch Large Data Volume Considerations Practice Question
A data architect is reviewing a custom object that has grown to 8 million records. Users report that list views and reports are slow because they sort on a text field, Priority__c, which has only three possible values. What should the architect recommend to improve performance?
⚠ Common exam trap
The trap here is assuming that any field used in sorting or filtering should be indexed, even when it has very low cardinality.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Remove sorting on Priority__c from list views and reports, and instead sort on an indexed field or filter on a more selective field.
For large data volumes, query performance is heavily influenced by field selectivity. A field with only three distinct values is not selective, so sorting or filtering on it forces the platform to scan many records. The best approach is to avoid sorting on such fields and instead use an indexed, high-cardinality field for sorting or filtering. This reduces the data set the query must process.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable Divisions on the object and assign records to divisions based on Priority__c.
Why it's wrong here
Divisions are used for data partitioning by business unit, not for improving query performance on a low-cardinality field. Assigning records to divisions based on priority would not create an index on Priority__c and would not address the slow sorting. It could also complicate security and reporting.
- ✗
Request a custom index on Priority__c to speed up sorting.
Why it's wrong here
Custom indexes are most effective on fields with high cardinality, where the index can quickly narrow down results. Priority__c has only three distinct values, so an index would not be selective and would not improve performance. In fact, Salesforce may not even grant an index on such a low-cardinality field because it would not be useful.
- ✗
Convert Priority__c to a picklist field with a restricted set of values to improve selectivity.
Why it's wrong here
Priority__c already has only three possible values, so converting it to a picklist would not increase selectivity. The problem is the low number of distinct values, not the field type. A picklist with three values would still be non-selective and would not improve sort performance.
- ✓
Remove sorting on Priority__c from list views and reports, and instead sort on an indexed field or filter on a more selective field.
Why this is correct
Sorting on a low-cardinality field like Priority__c forces the query optimizer to scan many records because the field is not selective. Removing the sort or replacing it with a sort on an indexed, high-cardinality field can dramatically improve performance. Filtering on a more selective field also reduces the number of records that need to be sorted.
About these practice questions
Courseiva writes every SF-Data-Arch question from scratch — 222 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Salesforce exam blueprint
This SF-Data-Arch practice question is part of Courseiva's free Salesforce certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SF-Data-Arch exam.