Hard Difficulty Questions

JavaScript web resource on the Invoice form

Why it fails: JavaScript runs only in the context of a model-driven app form. It would not trigger when data is modified via API, import, or other means. Also, it cannot reliably recalculate when child records change because the Invoice form may not be open. This approach fails the requirement for consistency across all modification methods.

Power Automate cloud flow triggered on InvoiceLine changes

Why it fails: A cloud flow could update the Invoice when a line item changes, but it runs asynchronously and may miss rapid changes or fail due to throttling. It also requires additional configuration and may not handle deletions reliably. Rollup columns are natively integrated and more consistent for this aggregation scenario.

Calculated column on the Invoice table

Why it fails: Calculated columns can only use values from the same record, not from related records. They cannot sum line items from a child table. While they are computed by the platform, they are limited to the current row's fields. Therefore, a calculated column cannot aggregate related InvoiceLine records to update TotalAmount.

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.

Set the app's Data row limit to 2000 in Settings so more rows are processed locally.

Why it fails: The Data row limit controls how many rows a non-delegable query may retrieve locally; raising it to 2000 increases, not removes, the ceiling and can degrade performance by transferring more data. It does not make a non-delegable query accurate beyond that limit, so it is a workaround rather than a fix for delegation.

Wrap the table in a ClearCollect on OnStart and query the collection thereafter.

Why it fails: ClearCollect loads rows into a local collection, which is itself subject to the data row limit, so it inherits the same cap and can silently miss rows. Querying the collection afterward gives fast local reads but on incomplete data, so accuracy degrades exactly when the table grows beyond the limit.

Increase the delegation limit by editing the app's JSON source directly.

Why it fails: There is no supported mechanism to edit app JSON to raise the delegation limit; that limit is enforced by the platform for non-delegable operations. Trying to hand-edit the app package is unsupported and would not change how the connector evaluates queries, so it cannot deliver accurate results past the limit.

Switch control with cases for each confidence level.

Why it fails: The Switch control is used for multiple discrete cases, not for comparing a numeric value against a threshold. While you could create cases for ranges, it is less efficient and harder to maintain than a simple condition. For a binary threshold, a Condition control is more appropriate.

Terminate action with a custom status code.

Why it fails: The Terminate action ends the flow run with a specified status. It cannot branch or route based on a condition. Using it would stop the flow entirely, which is not desired when you need to handle both high and low confidence paths. It is not a substitute for conditional logic.

Apply to each loop with a nested condition.

Why it fails: Apply to each is for iterating over a collection, not for evaluating a single confidence score. Using a loop here would be unnecessary and could cause performance issues if the collection is large. The scenario involves a single email classification, so a loop is not needed.

Use a 'Do until' loop with a condition that checks if all records have been processed, and retrieve records one at a time.

Why it fails: A 'Do until' loop that retrieves records one at a time is highly inefficient and will generate many API calls, likely hitting service limits. It also complicates error handling and state management. For batch processing, it is better to retrieve a filtered set and iterate with 'Apply to each', optionally with concurrency, rather than polling one record at a time.

Configure the flow to run with a service account that has elevated privileges to avoid throttling.

Why it fails: Using a service account with elevated privileges does not bypass Power Automate's service limits or throttling. Throttling is based on the flow's connection and the number of requests, not the user's privileges. While a service account can be useful for ownership and permissions, it does not solve performance or limit issues. The correct approach is to optimize the flow's actions and use concurrency.

Use the 'Batch' action to group records into a single API call.

Why it fails: Power Automate does not have a generic 'Batch' action for Dataverse that groups multiple operations into one API call. While some connectors support batch operations, Dataverse's standard actions do not provide this. Using an incorrect action would fail. The efficient approach is to filter records and use 'Apply to each' with concurrency, not a non-existent batch action.

Lookup

Why it fails: A Lookup column creates a many-to-one relationship to another table, which is ideal for referencing a single related record. To store multiple features per listing, you would need a many-to-many relationship, which requires a separate table and is more complex than necessary for a simple predefined list of options.

Choice

Why it fails: A Choice column stores a single value from a predefined list. It cannot hold multiple features for a single listing. If you need to store multiple features, a Choice column would require creating separate columns for each feature, which is inefficient and does not support easy filtering across multiple values.

Text

Why it fails: A Text column can store a comma-separated string of features, but it lacks built-in validation against a predefined list and does not provide a user-friendly selection interface. Filtering would require string operations and is prone to errors such as typos or inconsistent naming, making it less reliable than a structured choice.

Yes, if the user is an admin

Why it fails: Business rule mandatory-field enforcement cannot be bypassed by admin status; it applies to all users on the form. Admin privileges govern security roles, not client-side rule logic. Bypassing requires disabling the rule, editing the record via API, or changing the rule scope.

No, it is enforced at the database level

Why it fails: Business rules run client-side on the form, so they are bypassed by direct API writes, imports or edits to the underlying table; nothing enforces the requirement at the data layer. The database-level enforcement described here is what column requirements or plugins provide, which would be the right choice when the constraint must hold regardless of how records are created or updated.

No, it is enforced by the app

Why it fails: A mandatory field set by a business rule can still be bypassed through the web API, background jobs, or imports, which do not execute form scripts; only server-side or platform-level enforcement is absolute. It is tempting because the rule does appear enforced in the interactive form, and would be correct if the question asked only about the model-driven app's own form behaviour.

Write

Why it fails: Write permits editing field values on a record, so removing it stops updates but leaves deletion possible. Delete privilege specifically authorises record removal; Write is the correct removal when users must be blocked from modifying records.

Read

Why it fails: Read controls viewing a record, so removing it hides the record rather than preventing its deletion. Delete privilege is the permission that authorises removal; Read would be removed when users must not see records at all.

Append

Why it fails: Append grants permission to attach a child record to a parent, so removing it blocks relationship creation, not deletion. Delete privilege governs record removal; Append is the correct removal when users must be stopped from linking records.

Create a custom connector to the Copilot Studio agent's API.

Why it fails: A custom connector is not required because Power Automate provides a built-in Copilot Studio connector. Creating a custom connector would add unnecessary complexity and maintenance. The built-in action already handles authentication and communication, so this is not a required step.

Configure the agent to use the 'Generative answers' feature.

Why it fails: While 'Generative answers' can enhance an agent's responses, it is not a required configuration for the flow to call the agent. The scenario focuses on invoking the agent and using its response, not on the agent's internal response generation method. This option is not necessary to achieve the integration.

Enable the 'Respond to the user' setting in the agent's authoring canvas.

Why it fails: The 'Respond to the user' setting is related to how the agent interacts in a chat interface, not to being invoked from a flow. When called from Power Automate, the agent returns its response directly to the flow, and this setting does not affect that behavior. It is not required for the integration.

The environment is a trial

Why it fails: A trial environment still accepts imported managed solutions and creates their tables, so trial status does not strip a custom table. It is tempting because trial environments expire and restrict capacity, which matters when licensing limits prevent solution import entirely.

The solution is managed

Why it fails: Managed solutions do create their included tables in the target environment; the managed/unmanaged distinction governs customisability, not table creation. It is tempting because managed solutions lock components, which is correct when you want to prevent target-environment edits.

The table is a system table

Why it fails: System tables ship with Dataverse and are not the custom table you authored, so their status cannot explain a missing custom table. It is tempting because system tables cannot be deleted or renamed, which is relevant when troubleshooting why a standard table resists schema changes.

Use Collect(FilteredOrders, Filter(Orders, Status = varStatus)) in OnVisible, then sort the collection in the gallery.

Why it fails: Collecting filtered orders into a collection still relies on the initial Filter, which may be delegable, but the collection is limited by the app's row limit. For over 10,000 orders, this can be slow and may not retrieve all records. It also adds unnecessary data duplication and memory usage.

Use Filter(Orders, Status = varStatus) and set the gallery's Sort property to OrderDate descending.

Why it fails: The gallery's Sort property is not a standard property; sorting is typically done in the Items formula. Even if a sort property existed, it would not delegate and would only sort the retrieved rows. This approach does not guarantee complete data or server-side sorting.

Use Filter(Orders, Status = varStatus) and Sort(Filter(Orders, Status = varStatus), OrderDate, Descending) in the gallery's Items property.

Why it fails: Nesting Sort around Filter can cause the Sort to be non-delegable if the data source does not support the combination, potentially retrieving only a subset of rows. While Filter with '=' is delegable, the nested Sort may not delegate, leading to incorrect sorting and incomplete data. This approach risks performance and accuracy.

Apply a Filter function in every gallery and form to restrict records to the current user.

Why it fails: Filtering in the app is client-side logic that can be bypassed or forgotten in a new screen, and it does not enforce security at the data layer. A user could still retrieve other records through a different view or the API. Security must be enforced by the platform, not by app formulas, so this does not meet the requirement.

Enable the table's auditing setting so access attempts are logged and reviewed.

Why it fails: Auditing records what happened; it does not prevent unauthorized access. Enabling it would create a log of who read or wrote records, but users could still see records they should not. The requirement is to restrict visibility, not to record activity, so auditing alone is insufficient.

Set the app's data source to use a service account with limited permissions.

Why it fails: Canvas apps connect to Dataverse as the signed-in user by default, and using a shared service account would actually widen access and break per-user security. It also obscures who performed actions in the audit trail. This approach conflicts with the requirement to restrict each user to their own or shared records.

Write all extracted values to Dataverse regardless of confidence, then use a Power Apps formula to highlight low-confidence fields for the user to correct.

Why it fails: Writing low-confidence data directly to Dataverse risks polluting the table with inaccurate records. While Power Apps could highlight fields, the data is already persisted, and downstream processes might consume it before correction. This violates the requirement to handle low confidence before storing, and it shifts the burden to the app without a controlled approval step.

Configure the AI Builder model to automatically retry extraction up to three times if confidence is low, then write the best result to Dataverse.

Why it fails: AI Builder prebuilt models do not support automatic retries based on confidence scores within the flow action. Retrying the same document typically yields the same result because the model's output is deterministic for a given input. This approach would not improve accuracy and could introduce delays, and it does not address the need for human validation when confidence is genuinely low.

Use the 'Parse JSON' action to extract the confidence score from the AI Builder output and set a variable; if low, terminate the flow with a failure status.

Why it fails: Terminating the flow on low confidence would stop processing entirely, losing the opportunity for human review. The requirement is to handle the case, not abort it. While parsing the score is part of the solution, using it only to terminate does not route the document for validation or allow the canvas app to display a confirmation, so it fails the scenario's goal.

Automatic translation of all user emails.

Why it fails: Copilot Studio orchestrates topics, generative answers and Power Automate actions; it holds no mail-translation capability, and translation is not business-logic integration. It is tempting because Copilot Studio does call AI Builder and Azure AI services, but translating every user email automatically is neither a provided capability nor a business-logic integration pattern.

Direct hardware control.

Why it fails: Copilot Studio operates through connectors, topics and Power Automate flows in the cloud; it exposes no interface for controlling physical hardware. It is tempting because Copilot Studio can invoke Azure IoT connectors, but direct device actuation belongs to Azure IoT Hub or embedded device SDKs, not to the conversational AI layer.

Change the app name

Why it fails: Renaming the app changes only its display title; the Copilot control binds to data through its Data source property, which must reference a table or Dataverse source. The name field is tempting because it is the first property shown in the properties pane, but it configures identity, not data connectivity.

Write a custom API connector

Why it fails: A custom connector exposes external REST endpoints, not the app's existing tables; Copilot reads a connected data source directly. Custom connectors are the right choice when integrating a third-party or on-premises API absent from standard connectors, which is not the requirement here.

Update the environment variable

Why it fails: Environment variables hold configuration values such as endpoints or keys, and the Copilot control does not read them to resolve its data source. It is tempting because variables parameterise app behaviour, and they would be correct when you need to switch a connection string between environments.

Set the gallery's Items to Filter(Accounts, Status = "Active") and apply the date condition in the gallery's OnVisible property using a collection.

Why it fails: Filtering only by Status still delegates, but moving the date condition into a client-side collection means the app downloads all active rows and then filters them locally. With 100,000 rows, this risks hitting the data row limit and returns incomplete or slow results, so it does not meet the requirement.

Set the gallery's Items to FirstN(Accounts, 100000) and then apply Filter on the result to reduce the set.

Why it fails: FirstN retrieves a fixed number of rows regardless of the filter, so it pulls far more data than needed and still may not include the matching active recent rows if they fall outside the first N. This defeats delegation and is inefficient for a targeted query.

Use the Search function in the gallery's Items to match the status and date, since Search always delegates to Dataverse.

Why it fails: Search is designed for text matching on string columns and does not delegate for date comparisons or equality on choice columns in the same way Filter does. Using Search for Status and CreatedOn would fall back to client-side processing and likely return incorrect or limited results against a large table.

Manually recreate all flows

Why it fails: Manually recreating flows discards the tested automation and introduces configuration drift, so it is not a required production step. It is tempting when environments differ, but the correct approach is exporting and importing the solution so flows carry their definitions intact.

Delete the original AI model

Why it fails: Deleting the original AI model destroys the artefact being deployed, so it cannot be a production step. It is tempting because retiring development or staging resources feels like tidy-up, but the model itself must persist and be versioned in the production environment.

Hardcode the environment IDs

Why it fails: Hardcoding environment IDs breaks portability, since production uses different connection references and identifiers from development. It is tempting to pin values for predictability, but production deployment requires environment variables or connection references so the solution resolves the target environment dynamically.

Editable grid

Why it fails: An Editable grid allows inline editing of records in a view, but it is typically used on dashboards or as a subgrid with editing enabled. While it can display related contacts, the requirement emphasizes filtering and sorting, which are standard subgrid features. Editable grid adds editing, which is not requested and might complicate the scenario.

Quick view form

Why it fails: A Quick view form displays information about a single related record, not a list. It is used to show details of a primary contact or similar, but it cannot present multiple related contacts with filtering and sorting. It is not suitable for a list of records.

Timeline control

Why it fails: The Timeline control displays activities and notes related to a record, such as emails and appointments. It does not show a list of related contacts with filtering and sorting capabilities. It is designed for activity feeds, not for tabular data of related entities.

Add a parallel branch that runs the logging action simultaneously with the AI Builder action.

Why it fails: Parallel branches execute concurrently without dependency on the AI Builder action's outcome. The logging action would run regardless of success or failure, and the flow would still stop on an unhandled AI Builder error. This does not provide conditional error handling or continuation after failure.

Wrap the AI Builder action in a Scope action and set the Scope's concurrency control to 1, then place the logging action after the Scope.

Why it fails: A Scope groups actions for error handling, but setting concurrency to 1 only limits parallel execution; it does not automatically catch failures or route to logging. Without configuring run-after on a subsequent action, a failure inside the Scope would still terminate the flow unless handled with a run-after condition.

Enable 'Secure Inputs' and 'Secure Outputs' on the AI Builder action and add a Terminate action with status Succeeded after it.

Why it fails: Secure Inputs and Outputs hide data in run history but do not affect error handling. A Terminate action with Succeeded status would end the flow prematurely, preventing subsequent logging. This combination does not address the requirement to log extraction failures and continue processing.

Increase the number of training iterations to 100 without changing the dataset.

Why it fails: More iterations on the same limited dataset will not teach the model new table layouts; it may even overfit to the existing samples. The problem is variety, not training duration. Without additional representative examples, additional iterations cannot improve recognition of unseen line item table structures.

Switch the model to a prebuilt invoice model and remove the custom labels.

Why it fails: A prebuilt invoice model may extract common fields but often cannot match a custom table schema or vendor-specific layouts. Discarding the custom labels also wastes the work already done. The scenario calls for improving the existing custom model's table handling, not replacing it with a generic model that may not fit the required output.

Change the document type to 'Receipt' in the model configuration.

Why it fails: Receipt and invoice are different document types with different field expectations. Changing the type would misalign the model with the actual documents and likely degrade all extraction, including the fields that currently work. The table issue is a data coverage problem, not a document-type selection problem.