A large solution is being split into a core solution containing shared tables and security roles, and three feature solutions whose forms, views and flows use those tables. All solutions are deployed as managed. Which deployment rule must the team follow?
Select an answer to reveal the explanation.
Short Explanation
Think of the core solution as the foundation and the feature solutions as the floors on top. You can't pour the second floor before the foundation's there. The trap is copying the shared tables into every feature, which turns into a layering mess when they all fight over the same table.
Full Explanation
Segmented solutions split a large application into smaller units that can be developed and released more independently. Feature solutions depend on components in the core solution, such as tables and security roles, so the core must be present in the target environment before any feature can import; otherwise dependency validation fails. The rule is to import the core first in every environment and then the features in an order that respects any dependencies between them. Each component should belong to one solution that owns it, so features reference core components rather than carrying them. Importing features first fails because their forms, views and flows reference tables that do not yet exist. Copying the shared tables into each feature means several managed solutions contain the same tables, creating overlapping layers and making it unclear which solution owns a change, and removing one feature could affect the others. Merging everything back into one solution for each deployment defeats the purpose of segmentation and slows releases. Exam caveat: when features include a table only to add a form or column, include only the needed subcomponents rather than the whole table with all its assets. Operational check: in a clean test environment, import the core solution, then each feature, and confirm every import succeeds without missing dependency errors.