SF-Data-Arch Salesforce Data Management Practice Question
A Data Architect needs to implement a field-level security strategy where PII is visible only to the 'HR' profile. However, other profiles need to run reports on the account data without seeing the PII. What is the correct way to handle this?
⚠ Common exam trap
Candidates often propose complex sharing rules or record-type splitting, failing to realize that Field-Level Security is the most direct and secure way to handle visibility for sensitive fields.
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
✓
Apply field-level security to the PII field for all profiles except HR.
Field-level security (FLS) is the primary method for controlling access to specific fields. By defining FLS for the HR profile and restricting access for others, the architect ensures data privacy. When users without access run reports, Salesforce automatically hides the field, preventing unauthorized viewing while allowing them to report on other non-sensitive data. This approach is the native, secure way to manage field visibility without complex custom components or data splitting strategies.
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 two separate objects and use a lookup relationship to link them.
Why it's wrong here
Splitting data into two objects creates unnecessary complexity and performance overhead. It requires managing two sets of records for every customer, complicating integration, reporting, and data quality. Field-level security is designed to handle this exact scenario, making object splitting an over-engineered and inefficient approach to this requirement.
- ✓
Apply field-level security to the PII field for all profiles except HR.
Why this is correct
Field-level security allows for granular control over who can see specific data fields. By restricting the visibility for all profiles except HR, the system ensures that sensitive information is properly protected in the UI, API, and all report types, meeting the data privacy requirement simply and effectively.
- ✗
Implement a custom Lightning component to mask the field data.
Why it's wrong here
Custom masking components only work in the UI and leave data exposed in reports, list views, and API calls. This fails the security requirement because sensitive data would still be accessible via non-UI methods. FLS is the correct platform-level control that protects data across all access layers in Salesforce.
- ✗
Use an Apex trigger to clear the field value if the user is not in the HR profile.
Why it's wrong here
Clearing data with a trigger results in permanent data loss, which is unacceptable for HR information that must be preserved. The trigger would overwrite the field value whenever a user without HR access views or edits the record, making the data unusable for the HR team as well.
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.