SF-Data-Arch Salesforce Data Management Practice Question
Universal Containers wants to ensure that when a user updates a field on an Account record, the change is captured and stored for auditing purposes. The solution must be configurable without writing code and must retain field history for up to 18 months. What should a data architect implement?
⚠ Common exam trap
A common mix-up: candidates confuse event monitoring or triggers with field history tracking, but only Field History Tracking provides declarative, long-term field-level auditing.
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
✓
Enable Field History Tracking on the Account object for the required fields.
Field History Tracking is the standard declarative feature for auditing field changes. It automatically records changes, retains them for up to 18 months, and requires no code. Other options either involve code, track the wrong type of activity, or do not store historical data, making them unsuitable for this requirement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure a workflow rule to send an email notification on field change.
Why it's wrong here
A workflow rule can send notifications but does not store historical data. It is not an auditing solution because it does not retain a record of changes over time. Email notifications are transient and cannot be queried for compliance reporting. This approach fails to meet the requirement of retaining field history for 18 months.
- ✗
Create a trigger on the Account object to write changes to a custom object.
Why it's wrong here
A trigger requires code and maintenance, which contradicts the requirement for a configurable solution. While it can capture changes, it adds complexity and potential governor limit issues. It also does not provide the built-in retention and UI for viewing history that Field History Tracking offers, making it less efficient for standard auditing needs.
- ✓
Enable Field History Tracking on the Account object for the required fields.
Why this is correct
Field History Tracking is a declarative feature that automatically tracks changes to specified fields and retains history for up to 18 months (or 24 months in some editions). It requires no code and is ideal for auditing field changes. It stores old and new values, the user who made the change, and the timestamp, meeting the requirement for configurable auditing.
- ✗
Use Salesforce Shield Event Monitoring to track field changes.
Why it's wrong here
Event Monitoring tracks user activity and API usage, not field-level changes. It is designed for security and performance monitoring, not data auditing. It does not store old and new field values or provide a history related list. Additionally, Event Monitoring requires an add-on license and is not a declarative field history solution.
About these practice questions
This SF-Data-Arch question is part of Courseiva's 222-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.