[CoE Starter Kit - QUESTION] Admin | Inactivity Notifications v2 (Start Approval for Flows) – Flow modification date used as sole inactivity criterion causes false positives

[s-inigo]

Does this bug already exist in our backlog?

• I have checked and confirm this is a new bug.

Describe the issue

The flow Admin | Inactivity Notifications v2 (Start Approval for Flows) uses admin_flowmodifiedon as the sole criterion to determine whether a flow is inactive, triggering an approval notification to the flow owner when that field predates the configured threshold (default: 6 months). This causes false positives: flows that execute regularly and continuously but have not been modified during that period — because they are stable and working as expected — are included in the inactivity notification and potential deletion process. The filter condition applied by the flow is the following:

(admin_flowmodifiedon lt @{body('Get_past_time')} or admin_flowmodifiedon eq null)
and admin_flowdeleted eq false
and admin_flowstate ne 'Stopped'
and admin_flowexcusedfromarchival ne true
and admin_FlowEnvironment/admin_excusefromarchivalflows ne true
and admin_FlowEnvironment/admin_environmentdeleted ne true
and _admin_flowenvironment_value ne null
and admin_flowispublished ne false

Expected Behavior

The inactivity criterion should consider flow execution data (e.g. last run date) as a complementary or alternative signal to admin_flowmodifiedon, so that only genuinely unused flows are flagged for the archival process.

What solution are you experiencing the issue with?

Governance

What solution version are you using?

3.27.5

What app or flow are you having the issue with?

Admin | Inactivity Notifications v2 (Start Approval for Flows)

What method are you using to get inventory and telemetry?

Cloud flows

Steps To Reproduce

Deploy CoE Starter Kit v3.27.5, solution Center of Excellence - Governance Components, in a production Power Platform GCC/Commercial environment.
Ensure there are flows in the tenant that have been running regularly but have not been modified in the last 6 months.
Run the flow Admin | Inactivity Notifications v2 (Start Approval for Flows).
Observe that the flows running regularly are included in the inactivity notification process despite being actively used.

Anything else?

This issue has been identified in a production environment with real maker and flow data. The current behavior generates unnecessary notifications to flow owners for resources that are actively in use, which undermines trust in the governance process. We have observed that earlier versions of the CoE Starter Kit (prior to the v2 flows, introduced approximately in July 2022) incorporated usage and execution information as part of the inactivity logic, which provided greater accuracy. We would appreciate guidance on whether customization is the recommended path and, if so, the advised approach to extend the flow logic without introducing unmanaged layers that could break future solution upgrades.

[Star-Donovan]

MS has said the flow last run not being included is by design:

• Inactivity process also picking up active scheduled flow #6094 (comment)
• https://youtu.be/PZ5u_2E9uUI?si=Jk-Zcnp-ALN_oW3m&t=620 (starting at 10:20 , "Currently the CoE Starter Kit can't gather information about flow runs, so we don't know if a flow has been run in the past 6 months. But even if we could we do not believe that these would indicate that a flow is useful and still needed. This is because flows have triggers that aren't based on human action.")

Those comments were from 2023, though, and per some comments last year supposedly this is on the list to be worked on:

• [CoE Starter Kit - BUG] Inactive flows #9937 (comment)
• [CoE Starter Kit - Feature]: Inactivity Processes to check last run/access/use date of apps/flows #9819 (comment)

Of course, CoE is 3 months behind on new releases now, so who knows when or even if we'll be able to include flow last run in the inactivity checker without having to manually edit, creating unmanaged layers.