Dataverse Foundations practice questions

Configurable Cascading

Why it fails: This is a configuration type, not the relationship definition.

Many-to-Many

Why it fails: M:N relationships do not support direct parent-child cascading deletion in this way.

Referential

Why it fails: Referential does not cascade deletions by default.

Environment Member

Why it fails: This is a generic term, not a specific role name.

Owner

Why it fails: Owner is not a predefined role name.

Data Analyst

Why it fails: This is not a default role.

Business Process Flow

Why it fails: BPFs guide users through stages, not for data display.

Subgrid

Why it fails: Subgrids are for lists of records, while Quick View is for specific fields of one record.

Canvas component

Why it fails: This is an advanced custom UI element, not the standard way to show related data.

Create custom fields for CreatedBy and CreatedOn

Why it fails: These fields are provided by the platform and don't need to be created manually.

Add the fields to the form

Why it fails: Adding to the form just makes them visible, but does not configure the tracking.

Write a workflow

Why it fails: System fields are native, no workflow required.

Power Automate

Why it fails: Power Automate orchestrates actions on triggers or schedules; it does not perform set-based upserts against an external SQL source. It is tempting because it connects to SQL and Dataverse, and would be correct for event-driven row-by-row integration rather than bulk synchronisation.

API access

Why it fails: API access exposes Dataverse endpoints for custom code to call; it provides no scheduled synchronisation engine or change tracking against SQL. It is tempting because developers can build integration, and would be correct when bespoke logic must read or write Dataverse records on demand.

Dataflows

Why it fails: Dataflows load and transform data into Dataverse tables, but they are not the native synchronisation feature for keeping an external SQL database continuously aligned. They are tempting because they connect to SQL and schedule refreshes, and would be correct for periodic analytical ingestion rather than ongoing sync.

An Azure SQL database

Why it fails: Model-driven apps store data in Microsoft Dataverse tables, not Azure SQL. An Azure SQL database is tempting because Power Platform can connect to it through virtual tables or connectors, but that is for integrating external data, not for the required app foundation.

A canvas component

Why it fails: Canvas components belong to canvas apps, where makers drag controls onto a blank canvas. Model-driven apps instead require a Dataverse table, a site map, and an app designer entry. A canvas component would be correct when building reusable controls for a canvas app.

Perform external API calls

Why it fails: Business rules evaluate client-side conditions and set or recommend field values, show messages, and lock columns; they cannot make outbound network calls. External API calls are tempting because rules appear to automate logic, but such integration belongs to plug-ins or Power Automate flows.

Delete records

Why it fails: Business rules cannot delete records; they only set or clear field values, show error messages, set field requirements, and enable or disable columns. Deletion is tempting because rules control record behaviour, but destructive operations require a plug-in, flow, or classic workflow.

Direct SQL injection

Why it fails: This is not a supported method.

Power BI dashboard

Why it fails: Power BI is for reporting, not data ingestion.

Manual form entry only

Why it fails: This is not the only way.

External API exposure

Why it fails: External API exposure is not a default table behaviour; it depends on enabling and configuring the table for integration, such as through the Web API and its settings. It is tempting because every Dataverse table is reachable through the OData Web API once access and privileges permit, but that is configuration, not inherent default behaviour.

Form-based workflows

Why it fails: Form-based workflows are not a default table behaviour; they are optional automation you build and attach to a table's events. It is tempting because many tables do have business rules or workflows configured, but these are added components, whereas default behaviours such as auditing, ownership and activity logging exist without extra configuration.

Edit all user personal records

Why it fails: Personal records are not directly managed by admins.

Create custom JavaScript web resources

Why it fails: This is a maker task.

The business rule is deactivated.

Why it fails: A deactivated rule would not run at all, so the field would never populate on load either; the stem states the load-time value does appear. Deactivation is tempting when diagnosing rules that never fire. The reported symptom points to the rule's scope being restricted to the form rather than the entity.

The field is read-only.

Why it fails: A read-only field blocks user edits, not rule-driven updates; business rules can still set values on read-only fields. Read-only settings are tempting when users cannot change data. The symptom — load value set but no update on trigger change — indicates the rule scope is form-only rather than entity-level.

The business rule scope is set to Global.

Why it fails: Global scope applies the rule across all forms and server-side, so it would not prevent recalculation on the trigger field. Global scope is tempting when a rule must apply everywhere consistently. The failure instead indicates the rule is scoped to a single form, so changes outside that form context are not evaluated.

Parent: Child Business Units

Why it fails: Parent: Child Business Units grants a user access to records in their business unit and all child business units, which is broader than the requirement. It is tempting because it scopes by business unit hierarchy, and would be correct when users must also see subordinate units' records.

User

Why it fails: The User setting is a security role assignment, not a record-scope control; it determines which roles a user holds, not which business unit's records they read. It is tempting because it appears to configure access, but record visibility comes from the role's business unit access level.

Organization

Why it fails: Organization access provides visibility to all records in the entire environment.

System Administrator

Why it fails: System Administrator is a security role assigned to users, not a solution component such as tables, apps, flows or connection references. It is tempting because roles govern who can import and manage solutions, and would be the right answer if the question asked about permissions rather than solution contents.

User Security Profile

Why it fails: A solution contains components such as tables, columns, forms, views, charts, and processes; security roles are configured in the environment, not packaged as solution components. It is tempting because security roles govern record-level access, and defining them is the correct choice when configuring who may read or write Dataverse data.

Power Apps CLI data command.

Why it fails: CLI commands typically run with full logic execution unless specifically scripted otherwise.

Power Platform Admin Center data export.

Why it fails: This is for exporting, not importing data.

Set the user to 'Offline'.

Why it fails: Offline mode is not a valid setting for controlling workflow execution during imports.

Delete the workflows before import.

Why it fails: Deleting production workflows is not a best practice for data migration.

Auditing records are stored in a separate database.

Why it fails: Dataverse stores audit records within the same organisation database as the table data, not in a separate database, so this statement is false. It is tempting because many platforms isolate audit logs for security and retention reasons, which is a legitimate architecture elsewhere but not how Dataverse auditing works.

Auditing is enabled by default for all new tables.

Why it fails: Auditing is disabled by default for new tables; you must explicitly enable it at table and column level. It is tempting because some compliance-focused platforms turn logging on automatically, which would suit regulated environments, but Dataverse requires deliberate configuration before any audit records are captured.

Auditing tracks the IP address of the user.

Why it fails: Dataverse auditing tracks the user and the change, but not IP addresses directly.

Create a 1:N relationship from Account to Case and add a subgrid on the Case form.

Why it fails: A 1:N relationship from Account to Case allows an account to have many cases, but a subgrid on the Case form would show a list of related cases, not account details. This does not provide the desired information about the account's primary contact or phone number. Therefore, it does not meet the requirement.

Create a calculated column on the Case table that pulls the account's phone number.

Why it fails: Calculated columns can derive values from columns in the same table or from related tables through lookups, but they cannot directly pull values from a related table without a lookup. Even with a lookup, calculated columns are evaluated on save and do not automatically update when the related record changes. They also cannot display the primary contact. Thus, this approach is not suitable.

Create a lookup column on the Case table that references the Account table.

Why it fails: A lookup column creates a many-to-one relationship, allowing a case to reference one account. However, it only stores the reference and does not automatically display related fields such as the primary contact or phone number on the case form. Additional configuration, like quick view forms, is needed to show those fields. Thus, this alone does not meet the requirement.

Calculated

Why it fails: A Calculated column computes values from other columns in the same table, but it cannot reference columns in a related table without a relationship. Since there is no existing relationship, you cannot use a Calculated column to pull the Account name; you need a Lookup to establish the relationship first.

Text

Why it fails: A Text column can store the Account name as a string, but it does not create a relationship and requires manual data entry. It would not automatically display the related Account's name or enforce referential integrity, making it unsuitable for displaying related data dynamically.

Choice

Why it fails: A Choice column stores a predefined list of options, not a reference to another table. It cannot dynamically retrieve the Account name from the Account table. Using a Choice would require manually maintaining the list of account names, which is impractical and error-prone.

Floating Point

Why it fails: Floating Point is used for approximate numeric values and is not suitable for monetary data because it can introduce rounding errors. It does not support currency-specific formatting or precision control to four decimal places as a currency type does. Therefore, it would not meet the requirement for a monetary column.

Decimal

Why it fails: Decimal can store numbers with decimal places, but it is not designed for monetary values. It does not provide currency formatting, currency symbols, or conversion to a base currency. While it can be configured with up to four decimal places, it lacks the monetary context required for a currency field in Dataverse.

Money

Why it fails: Money is not a valid Dataverse column data type. The correct data type for monetary values is Currency. While some platforms use 'Money' as a type name, in Microsoft Dataverse the appropriate choice is Currency, which provides the required precision and currency handling.

Currency column

Why it fails: A Currency column stores monetary values and supports currency formatting and exchange rates. It does not perform calculations or reference other columns. While Annual Revenue is a currency column, the discount percentage is a numeric value, so a currency column would not automatically derive it.

Rollup column

Why it fails: Rollup columns aggregate data from related records in a child table, such as summing opportunities. They do not compute values from columns in the same record, so they cannot derive a discount percentage from Annual Revenue. They also run on a scheduled or on-demand basis, not immediately on change.

Formula column

Why it fails: Formula columns are read-only and compute values using Power Fx, but they are limited to the Power Apps environment and cannot use all Dataverse data types. They are not the standard choice for a simple arithmetic calculation referencing another column; calculated columns are the intended feature for that scenario.

Two Calculated columns

Why it fails: Calculated columns cannot reference related tables; they only work with columns in the same table. Therefore, they cannot count tasks from a related table. Using Calculated columns for this purpose is not possible without duplicating data into the Project table, which is not a best practice.

Calculated

Why it fails: A Calculated column operates on columns within the same table and cannot aggregate related records. It cannot count child records from a related table. Therefore, it cannot provide the required counts of tasks associated with a project.

Rollup

Why it fails: A Rollup column can aggregate related records, but it supports only one aggregation per column. To display both total tasks and completed tasks, you would need two Rollup columns. However, Rollup columns are calculated asynchronously and may not reflect real-time changes, which might be a limitation for frequently updated counts.