Desktop flow action logs configuration (preview)

Article
05/10/2024

[This topic is prerelease documentation and is subject to change.]

This page provides configuration guidance for desktop flow logs, located under the environment's feature section in the Power Platform admin center.

Important

This is a preview feature.
Preview features aren’t meant for production use and might have restricted functionality.
This feature isn't available yet for local attended runs from Power Automate desktop.
These features are available before an official release so that customers can get early access and provide feedback.
Some of the features listed on this page are still gradually rolling out and may not be available in your region yet.

The Activation status of run action logs setting defines when desktop flow run action logs should be captured and even allows you to turn them off completely.

Activation status	Details
Enabled (default)	This option is the default for both existing and new environments where logs are captured as usual.
On run failure	This option only captures desktop flow actions logs when there's a runtime error. This means that logs aren't available for every single run, but only when an error occurs. However, if an error does occur, all logs for that particular run are available, including both successful and failed actions.
Disabled	This option effectively disables desktop flow run action logs completely.

Caution

Changing any of these settings can have a significant impact on features such as run failure troubleshooting and auditing. Consider the implications of changing these settings before proceeding.

Configure desktop flow action log version (preview)

The Action logs version allows you to choose V1, V2, or both.

Logs version	Explanation
V1 - Stored in the AdditionalContext field of the FlowSession entity	This option is the default. Logs are stored in the AdditionalContext field of the Flow Session table, which is a file attribute stored as a blob in Microsoft Dataverse. Logs V1 consumes Dataverse file capacity.
V2 - Stored in the FlowLogs entity (Preview)	This new option allows you to store logs in the Flow Logs table, which is stored in Elastic Tables. Logs V2 consumes Dataverse database capacity.
Both (Preview)	This setting allows logs to be stored in both the traditional AdditionalContext field of the Flow Session table and the Flow Logs table. This feature is in preview and consumes both Dataverse file and database capacity. This is intended for debugging or testing purposes as it consumes both Dataverse database and file capacity.

The FlowLogs entity time to live in minutes (Preview) value determines how long action logs should be retained in the Flow Logs elastic table. Dataverse automatically deletes records that are older than the specified time-frame. Here are some example values for your convenience.

Days	Minutes
One day	1,440 minutes
Three days	4,320 minutes
Seven days	10,080 minutes
14 days	20,160 minutes
28 days	40,320 minutes
60 days	86,400 minutes
90 days	129,600 minutes
180 days	259,200 minutes
365 days	525,600 minutes
Forever	Less than or equal to 0 (zero) minutes

Note

Before enabling logs V2, make sure you have sufficient Dataverse database capacity that would support the data retention settings and aligns with your capacity planning, entitlement and adjust as necessary. See the Sample Dataverse capacity demand calculations for logs V2 following section for some sizing examples.

Key differences of desktop flow logs V1 and V2

The following table describes the differences between desktop flow logs V1 and V2:

Feature	Logs V1	Logs V2	Details
Automatic Data Retention	Not Available	Available	V2 uses Elastic Tables, which are powered by Azure Cosmos DB and comes with a built-in time-to-live feature for automatic data retention.
Support for large log sizes	Roughly up to 50,000 to 80,000 action logs (maximum)	Roughly twice the number of V1 action logs (initially)	V2 could theoretically scale up to gigabytes worth of action logs per run in future, whereas V1 can only scale to the volume specified in this table.
Support for advanced reporting and governance	Not Available	Available	In V1, the AdditionalContext attribute is a file type, stored as a blob in Dataverse, making it challenging to parse for reporting and governance controls. Logs are much more accessible in V2.
Support for Azure Synapse Link for Dataverse integration	Not Available	Planned	In V1, the AdditionalContext attribute is a file type, stored as a blob in Dataverse, which isn't supported for synchronization to Azure Synapse.
Support for Dataverse auditing	Not Available	Planned	In V1, the AdditionalContext attribute is a file type, stored as a blob in Dataverse, which isn't supported in Dataverse auditing.
Support for Dataverse long-term retention	Not Available	Planned	In V1, the AdditionalContext attribute is a file type, stored as a blob in Dataverse, which isn't supported in Dataverse long-term retention.
Based on Dataverse Role-Based Access Control (RBAC)	Available	Available	Both versions use Dataverse RBAC, inheriting action log permissions from their parent flow session record.

Logs V2 offers significant enhancements over the previous version, V1. V2 uses the elastic tables feature, which is great for handling large data volumes, like action log scenarios, and has built-in data retention (TTL). Ideal for organizations needing to access significant amount of data for reporting, governance, and integration with automatic data retention control.

Note

The Audit changes to its data property under the advanced properties of the Flow Log table should be deselected until auditing is supported for logs V2. Learn more about this and other advanced table settings here.

Dataverse capacity demand calculations for logs V2

The following table shows sample Dataverse database storage consumption estimates per desktop flow run when using logs V2. It outlines the approximate storage demand for different numbers of actions, assuming an average of 3 KB of storage per action.

Number of actions	Storage demand per action (KB)	Total storage consumption (MB)
1,000	3	2.93
10,000	3	29.3
30,000	3	87.9
60,000	3	175.8
100,000	3	293
160,000	3	480

Important

The figures shown in the above table are just estimates and the actual storage consumption can vary significantly. The exact storage demand will depend on the specific details and complexity of each action log. Therefore, these numbers should be used as a rough guide for understanding the potential storage demand and planning your storage requirements accordingly.

Querying logs V2 data

Accessing desktop flow action logs data can be achieved by making an API call to the Dataverse backend, either using the traditional API call syntax or using the new ExecuteCosmosSqlQuery method. This method allows you to execute a SQL query against Dataverse, enabling the retrieval and filtering of data.

The data model of logs V2 is based on a parent-child relationship between the Flow Session and Flow Log tables. Every record inherits permissions from its parent flow session record. In order to query action logs of a specific desktop flow run, you can use the following query syntax.

Traditional Dataverse API call syntax

The following API call retrieves a specific flow session by its ID (9d51aa1f-315e-43ab-894f-bc445dfb049b) and then accesses the associated action logs using the flowsession_flowlog_parentobjectid relationship.

[Organization URI]/api/data/v9.0/flowsessions(9d51aa1f-315e-43ab-894f-bc445dfb049b)/flowsession_flowlog_parentobjectid

New ExecuteCosmosSqlQuery API call syntax using FlowLogs table

    [Organization URI]/api/data/v9.2/ExecuteCosmosSqlQuery(
    QueryText=@p1,EntityLogicalName=@p2,PartitionId=@p3,QueryParameters=@p4,PageSize=@p5)?
    @p1='SELECT+c.props.flowlogid+as+flowlogid,+c.props.createdon+as+createdon,+c.props.data+as+data,+c.props.level+as+level,+c.props.type+as+type,+c.ttl+as+ttlinseconds,+c.props.cloudflowid+as+cloudflowid,+c.props.cloudflowrunid+as+cloudflowrunid,+c.props.desktopflowid+as+desktopflowid,+c.props.flowmachineid+as+flowmachineid,+c.props.flowmachinegroupid+as+flowmachinegroupid,+c.props.flowsessionid+as+flowsessionid,+c.props.workqueueid+as+workqueueid,+c.props.workqueueitemid+as+workqueueitemid+FROM+c+WHERE+c.props.type+IN+(100000001)+ORDER+BY+c.props.data.startTime+DESC'&
    @p2='flowlog'&
    @p3='flowsession_9d51aa1f-315e-43ab-894f-bc445dfb049b'&
    @p4={"Keys":["@referencingParentId"],"Values":[{"Type":"System.Guid","Value":"9d51aa1f-315e-43ab-894f-bc445dfb049b"}]}&@p5=50

Learn more about querying JSON columns in elastic tables.

Breaking down the call into individual pieces

The base URL (https://[my org].api.crm[my region].dynamics.com/api/data/v9.2/) is the endpoint for the Dataverse Web API.
ExecuteCosmosSqlQuery is the method being called. This method allows the execution of a SQL query against Dataverse.
The parameters for the ExecuteCosmosSqlQuery method are provided in parentheses following the method name. These are:
- QueryText=@p1: The SQL query to be executed. In this case, the query selects various properties from a table where the type is 100000001 (desktop flow action log type) and orders the results by the startTime property in descending order.
- EntityLogicalName=@p2: This is the logical name of the table (flowlog) that stores the action logs.
- PartitionId=@p3: This parameter is used to identify the partition within Azure Cosmos DB where the query is to be executed. It's set to flowsession_[flowsessionid].
- QueryParameters=@p4: This is a JSON object specifying parameters for the query. In the previous example, it's specifying a key-value pair where the key is @referencingParentId and the value is the flowsessionid (GUID).

Known limitations

Logs V2 are only available for desktop flow runs that are launched from a cloud flow through the desktop flow connector action.
Changing action log version doesn't migrate previous desktop flow action logs to the new log storage type.
Cascade delete isn't currently supported. When you delete a flow session record, the underlying logs aren't automatically deleted.

Share via