A group of Microsoft Products and technologies used for sharing and managing content, knowledge, and applications.
Hi,
Based on your scenario, I would recommend recalculating the total savings from the child Tasks list whenever a task is created or updated. This approach is generally more reliable because it helps prevent double-counting and ensures that the parent Projects list always reflects the latest values.
You can achieve this using the following flow structure:
1/ Start with the trigger "When an item is created or modified" on the Tasks list.
2/ Initialize a variable:
- Name: TotalSavings
- Type: Float
- Value: 0
3/ Add a Get items action for the Tasks list.
4/ Filter the results using the Project lookup ID: ProjectLookupId eq @{triggerBody()?['ProjectLookupId']}
Please replace ProjectLookup with the internal name of your lookup column. In SharePoint, lookup IDs are typically exposed as the internal field name followed by Id.
5/ Next, add an Apply to each loop using the items returned from Get items. Inside the loop, increment the TotalSavings variable with: float(coalesce(items('Apply_to_each')?['Savings'], 0))
This expression safely handles blank or null values while ensuring the calculation remains accurate.
6/ Once the loop has completed, use an Update item action on the parent Projects list:
- ID: Project lookup ID from the trigger
- Total Savings: TotalSavings
In addition, I would recommend keeping loop concurrency disabled, as the flow updates the same variable during each iteration. This helps avoid unexpected calculation issues.
You may also want to consider scenarios such as task deletions or tasks being reassigned to a different project. To make the solution more robust, a scheduled reconciliation flow can be helpful. For example, it could periodically recalculate totals for all projects and correct any discrepancies that may occur over time.
If the flow is not returning the related tasks as expected, I suggest reviewing the Get items output in the flow run history. In many cases, the issue is caused by filtering against the lookup's display value rather than its numeric ID, or by using the column's display name instead of its internal name.
To summarize, the key advantages of this approach are:
- It recalculates totals directly from the child records, reducing the risk of double-counting.
- It uses a lookup ID filter and a null-safe expression for savings calculations.
- It takes into account decimals, pagination, concurrency considerations, task deletions, and project reassignments.
- It provides a troubleshooting path for the most common lookup filter issues.
Additionally, you may also want to consider posting your question in the Find Answers | Microsoft Power Platform Community.
That community is focused specifically on Power Platform topics and includes many experienced users, Microsoft experts, and partners. As an Independent Advisor, my Power Platform resources are somewhat limited, so I want to be careful not to provide guidance that may be incomplete. The Power Platform Community is often in the best position to offer more specialized recommendations and potential workarounds for complex scenarios.
I hope this helps.
Best regards,
If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.