Component Reference

This page is the full inventory of what a PowerApps request can reach. Each section states whether the agent applies the change or specifies it for you to apply, because in PowerApps that varies by area.

​

Dataverse Schema

Applied directly.

​

Tables

Tables are created as Org-owned or User-owned, and that choice is permanent in practice: it determines whether row-level ownership and sharing exist at all, which the security model then depends on. Per table you can enable or disable notes, activities, change tracking, auditing, and search, and set the description and behaviour.

​

Columns

Each column carries a required level of Business Required, Recommended, or Optional, plus minimum and maximum values and format where the type supports them.

​

Relationships

One-to-many and many-to-one through lookups, and many-to-many directly. Each relationship carries a referential behaviour governing what happens to related rows: Cascade, Restrict, or Remove Link among them. Relationship schema names and navigation property names are set explicitly rather than left to generation, because integrations and flows reference them by name.

​

Publishing

Schema changes are published so that tables, columns, and relationships become available to the app, its views, and any flows. Unpublished metadata is the usual explanation for a column that exists but does not appear.

​

Model-Driven App UI

Applied directly.

​

Forms

Four form types are in scope: Main, Quick Create, Quick View, and Card. The agent can list and inspect existing forms, including their tabs, sections, and field order, their subgrids and the views those subgrids use, and any registered JavaScript libraries and event handlers. Registered scripts are read and described, not rewritten. Configurable on a form:

• Tab and section organisation
• Adding, removing, and reordering fields
• Subgrids, including related-entity subgrids bound to a specific view
• Key fields placed in the header or footer
• A System Information section, which is where owner and status fields belong so they stay out of an operator’s way

​

Views

System views are created and modified: selected columns with their order and widths, and sort and filter definitions. Personal and system views are distinguished where the environment supports the difference. Views are where the security model becomes visible to users. Aligning them to roles and workflow states is what makes an app usable: “My active records”, “Completed with errors”, “Needs review”.

​

Navigation and Sitemap

The sitemap is structured in three levels:

​

Solutions and Apps

Applied directly. Solutions are created with a specified publisher and version. Components are then associated into them: tables, forms, views, charts, dashboards, security roles, flows, web resources, and apps. Model-driven apps are defined by which sitemap, tables, and artifacts belong to them.

​

Security Model

Specified, not applied. Direct role creation and privilege updates have limited write surface through the tooling. The agent therefore produces the design and the exact settings, and you apply them. What it produces:

• Business rules translated into Dataverse privileges: Create, Read, Write, Delete, Append, Append To, Assign, and Share
• A scope for each privilege: User, Business Unit, Parent-Child Business Unit, or Organization
• A privilege matrix per role, table by table
• Instructions for adding the roles to the solution so they travel with it

The matrix is checked for consistency against the data model, so a privilege on a table that does not exist, or a scope that ownership type cannot support, gets caught at design time.

​

Business Logic

​

Business Rules

Applied directly. Table-level business rules show and hide fields, set default values, calculate field values, and set required or locked states based on conditions. A rule that derives a banding field from a score, or that requires one lookup to be populated before a record can be used, belongs here.

​

Power Automate Cloud Flows

Specified, not applied. The agent defines the trigger, for example on create or update of a record or on a status change, outlines the steps including calls to an external service and the status and log writes that follow, and provides full JSON and body mappings for HTTP actions. You build the flow from that definition.

​

Form JavaScript

Specified, not applied. Client-side logic is specified and the code pattern generated, along with how to register it on the form and which event to bind it to. Disabling edit on fields written by a background service, or surfacing a warning banner on an error state, are the common cases.

​

Data Operations and Reporting

Applied directly, subject to the operations exposed. Queries. Filtered queries against your custom tables to inspect what is stored, and sample rows pulled back to confirm that schema and process match. Seeding. Configuration records and realistic test records created so a process can be exercised end to end before real data arrives. Charts and dashboards. Charts designed against your tables, for example counts by status or distribution across a banded field, and dashboards combining list views with charts for a given audience.

​

Consistency and Integration Guard Rails

Advisory, and worth asking for explicitly.

​

Your Next Step