SF-Data-Arch Data Modeling and Database Design Practice Question
A financial services firm stores portfolio holdings in a custom object with 4 million records. Analysts frequently filter holdings by Account and by a calculated risk score derived from multiple fields on the holding record. The architect wants to minimize query time when users filter by risk score in list views and reports. Which approach should the architect take?
⚠ Common exam trap
The trap here is believing formula fields are indexed for filtering, when in fact only stored fields with a custom index can accelerate queries at scale.
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
✓
Create a numeric custom field to store the risk score, populate it via a before-save record-triggered flow, and request a custom index on that field.
To filter efficiently on a computed value at scale, the value must be stored in a field that can carry a custom index. A before-save record-triggered flow updates the stored field without extra DML, and a custom index lets list views and reports filter on it quickly. Formula fields, roll-up summaries, and Big Objects cannot provide indexed filtering on a per-record calculated score.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a formula field for the risk score and rely on Salesforce to index it automatically for filtering.
Why it's wrong here
Formula fields are not indexed and cannot be used as a filter that benefits from an index. While they can appear in list views, filtering on a formula field forces a full scan, so query performance degrades as the 4 million records grow, failing the performance goal.
- ✓
Create a numeric custom field to store the risk score, populate it via a before-save record-triggered flow, and request a custom index on that field.
Why this is correct
A stored numeric field can be indexed, and Salesforce supports custom indexes on external IDs or fields requested through Support. Populating it with a before-save flow keeps it current without consuming additional DML, so filtering by risk score in list views and reports uses the index and performs well at scale.
- ✗
Create a roll-up summary field on a parent object to calculate the risk score and filter on the parent.
Why it's wrong here
Roll-up summary fields aggregate child records onto a parent and cannot compute a risk score from multiple fields on the holding record itself. Filtering on the parent would also not isolate individual holdings by their own risk score, so this does not meet the requirement.
- ✗
Enable Big Object storage for the holdings and query it with SOQL to improve filter performance.
Why it's wrong here
Big Objects are designed for massive archival data and have restricted SOQL and indexing capabilities. They cannot be used in standard list views or reports the way analysts expect, and their indexes must be defined at creation, so this approach adds complexity without solving the filtering requirement.
About these practice questions
One of 222 original SF-Data-Arch practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.