SF-Data-Arch Data Modeling and Database Design Practice Question
Exhibit
{ "object": "Order__c", "field": "Status__c", "type": "Picklist", "values": ["Draft", "Submitted", "Closed"], "history_tracking": true }Refer to the exhibit. An architect needs to track changes to the 'Status__c' field for auditing purposes. Based on the configuration provided, what is the best way to report on the duration a record spent in each status?
⚠ Common exam trap
Candidates often suggest using standard Field History Tracking, which is not reportable for calculating duration between states, as it is designed for auditing, not analytical time-tracking.
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 custom object to store status change logs with entry and exit timestamps.
Standard Field History Tracking records changes but does not store the duration between states effectively for analytics. Creating a secondary 'Audit' object that captures snapshots of status changes via a record-triggered flow is the best approach. This allows the architect to calculate intervals between timestamps using reporting tools or custom formulas, providing the necessary visibility into business process bottlenecks that native history tables cannot easily compute.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the built-in Field History report type.
Why it's wrong here
Field History reports are limited in their ability to perform cross-record calculations. They show when a change occurred but do not provide an easy way to subtract the 'CreatedDate' of one history record from the next to determine the total time spent in a specific status.
- ✓
Create a custom object to store status change logs with entry and exit timestamps.
Why this is correct
Building a custom audit log object allows for capturing the precise time of entry and exit for every status change. This data structure supports complex reporting and aggregation, enabling users to generate metrics like 'Average Time in Status' which are otherwise impossible with standard Salesforce Field History.
- ✗
Enable 'Custom History Tracking' in the Setup menu.
Why it's wrong here
There is no 'Custom History Tracking' feature in Salesforce. History tracking is limited to specific fields on standard or custom objects, and the resulting data is stored in specialized, non-queryable tables that are not designed for the complex analytical processing required to calculate duration between specific status changes.
- ✗
Use a formula field to calculate the duration.
Why it's wrong here
Formula fields are calculated at runtime and cannot reference historical data or previous record values. They require static data residing on the current record, making them useless for measuring duration across multiple state transitions that occur at different points in the object's lifecycle in the database.
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.