SF-Data-Arch Data Modeling and Database Design Practice Question
Universal Containers requires a many-to-many relationship between Projects and Consultants. They need to track specific attributes like 'Hourly Rate' and 'Assigned Role' on the relationship itself. Which approach should a Data Architect recommend?
⚠ Common exam trap
Candidates often suggest using a simple lookup or trying to force a standard relationship, missing the requirement to store extra metadata fields on the intersection of the two objects.
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
✓
Implement a custom object that serves as a junction object between Projects and Consultants.
A Junction Object is the standard Salesforce solution for many-to-many relationships. By creating a custom object between Projects and Consultants, the architect can include extra fields to store metadata about the assignment. This design ensures referential integrity, enables robust reporting across both parent objects, and allows for security modeling via Master-Detail or Lookup relationships, which is essential for complex consulting resource management.
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 multi-select picklist on the Project object containing all available Consultants.
Why it's wrong here
Multi-select picklists are difficult to report on and cannot store additional relationship attributes like 'Hourly Rate'. They also fail to enforce data integrity since the list must be manually maintained, leading to significant synchronization issues as the number of consultants grows over time within the organizational database.
- ✓
Implement a custom object that serves as a junction object between Projects and Consultants.
Why this is correct
The junction object pattern effectively resolves the many-to-many relationship while allowing custom fields such as 'Hourly Rate' and 'Role'. This approach leverages platform-native features for reporting and security, ensuring that each assignment record is uniquely identifiable and manageable through standard Salesforce list views and page layouts.
- ✗
Add a lookup field on the Project object pointing to the Consultant object.
Why it's wrong here
A standard lookup field only supports a one-to-many relationship. This prevents a single project from being assigned to multiple consultants simultaneously without creating duplicate project records, which violates normalization principles and complicates data management for resource allocation tracking across the entire firm's active project portfolio.
- ✗
Use a custom metadata type to map consultants to projects.
Why it's wrong here
Custom metadata types are intended for configuration data, not for transactional records like project assignments. Since assignments change frequently, using metadata would require deployment-level changes for every new project assignment, which is inefficient, violates governance best practices, and hits strict limits on record counts and deployment complexity.
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.