Configure Microsoft Dataverse
Choose the object, not the button
Dataverse questions test whether you can match a requirement to the right object. Know the table types: standard, activity, virtual (data stays in an external system), and elastic (high-volume). Columns carry data types, and once a column holds data most type changes are blocked - so distractors that propose "change the column type later" are usually wrong.
Relationships are one-to-many and many-to-many. A many-to-many relationship cannot carry extra columns of its own; if the link needs attributes, model it as two one-to-many relationships to a manual intersect table. For one-to-many, cascade behaviour is the highest-yield topic: Parental (cascade all) deletes child records with the parent, Referential removes the link and leaves the children, and Custom lets you set each action independently. Read the wording: "child records must be removed when the account is deleted" means Parental.
Calculated columns are computed when the record is read. Rollup columns aggregate related records and are refreshed by a scheduled system job, so values can be stale - a request for a real-time total wants a calculated column, not a rollup. Global choices are reusable across tables; local choices belong to one table. Business rules run in the app form and are not enforced when a record is written by an API or integration, so they are not a data-integrity guarantee.
Security is layered: business units set ownership boundaries, security roles grant privileges at user, business unit, parent-child business unit, or organization level, teams own records, and column security profiles restrict individual fields. Column security is the answer only when the requirement is about specific fields rather than whole records.
Rule of thumb: if deleting a parent must delete the children, choose Parental; if it must only unlink them, choose Referential.