Overview
Because Power Automate Approvals data is stored in CDS, it is possible to leverage CDS APIs and Connectors to build additional Flows, PowerApps, and dashboards using the data.
However, given that the data’s primary purpose is to power the Power Automate official experiences (the Approvals Center on flow.microsoft.com, the Power Automate mobile application, and Office 365 Actionable messages), there are some important caveats to using this for your own flows and applications.
Manipulation of Power Automate Approvals data in CDS is NOT supported.
Writing or modifying approvals data is not supported. Doing so can result in the following invalid configurations or unexpected/undocumented behavior.
-
Data changed outside of the Power Automate Approvals center, mobile app, and Office 365 actionable approvals may NOT be processed by the state machine that handles responses. So marking a request as approved may have no effect on the overall approval state, continue workflows, etc.
-
Flows waiting on approvals, either by using the Start and Wait for an Approval or Wait for an Approval actions, may NOT continue after approval responses are recorded.
-
The approvals clients (mobile, Power Automate Portal, Outlook actionable approvals) may be unable to properly list or otherwise handle approvals that have been modified by customizations party solutions.
-
Validation logic implemented by the supported clients and Power Automate backend is bypassed when using 3rd party solutions; therefore, any approval modified may have incomplete, incorrect, or un-trustworthy state.
The schema is complex, not publicly documented and is subject to change
The creation of an approval, with requests and responses, is complex and involves the writing of multiple records to the CDS database. These records are used for the presentation of the data within the Power Automate supported clients and are not optimized for consumption or use by custom flows and applications. Additionally, the data represents the point-in-time state of the approvals, not a historical record of all changes to the data, so it can not be used as the historical trail of all changes made to approval data.
High Level Schema Description
Every approval created will have one representative row in msdyn_flow_approvals. The owner of this record will be the creator (the user account corresponding to the connection used in the flow, or the on-behalf-of-owner if that field is specified when creating the approval).
Every recipient of the approval will own an msdyn_flow_approvalrequest record. When those users respond there will a an msdyn_flow_approvalresponse record.
When the termination criteria of the approval is met based on the responses received, the approval record will be marked as complete (inactive, in CDS terms).
Note that all owner records are linked to the SystemUsers entity that represent the AAD users.
Supported scenarios (not exhaustive)
Use the CDS connector to:
-
Trigger on creation or completion of approvals using the "When an entity is created, modified, or deleted" trigger.
-
Monitor approvals that have not been completed (requests for which no corresponding response exists) using the "List records" action.
-
Build a PowerApp that shows approvals assigned to specific users or the app user using the "List records" action.
