Flow Automation: Summing List Values via Action
In a Flow Automation workflow, you can use the Sum function action to add up a numeric field across every item in a list, such as the refunded amount across a customer's returned orders. This lets you build conditions based on totals — like how much a customer has been refunded recently — without manually adding up amounts yourself.
This guide explains the fields available for this action and shows a complete example of using it together with the Count function action to detect and automatically cancel repeat return abuse.
When to Use the Sum Action
Use the Sum function action when:
- You need the total value of a numeric field across a list, such as a customer's total refunded amount.
- You want to compare that total in a condition further down the workflow.
- You need a numeric result to feed into later steps.
| Note: This article covers only the Sum function action. For the complete workflow it's used in, see "Flow Automation: Building a Workflow to Detect Repeat Return Abuse." |
Field Descriptions
| Field | Description |
| List | The list contains the values to sum, such as the orders returned by a Batch query orders action. |
| Numeric Field | The numeric field within the list to add up, such as the refunded amount. |
| Result Name | The name of the numeric result Flow generates, shown as Sum (or sum(2), sum(3), and so on if you use more than one Sum action in the same workflow). Reference this result in later conditions. |
Supported Actions
You can add the Sum function action after any step that returns a list, including:
- Batch query orders
| Note: Currently, the Sum function only supports lists returned by the Batch query orders action. |
Example Use Case
Here's a complete, real-world example that uses both the Count function and Sum function actions to automatically cancel new orders from customers who show a pattern of return abuse: 2 or more returns within the last 6 months, where the total refunded amount from those returns is $20 or less.
Path 1: The Customer Is Already Flagged as a Repeat Offender
If the customer placing the order is already tagged from a previous review, the workflow skips straight to canceling the order:
- Trigger: Order created
- Condition: Customer is tagged as a repeat-return customer — Yes
- Action: Create Order Risk Assessment — flag the current order as high risk
- Action: Cancel Order — with Refund and Restock Items turned on, and no customer notification, so the cancellation is silent
Path 2: The Customer Isn't Flagged Yet — Analyze Their Recent Orders
If the customer isn't already tagged, the workflow checks their recent order history before deciding whether to cancel:
- Trigger: Order created
- Condition: Customer is tagged as a repeat-return customer — No
- Action: Batch query orders — retrieve the customer's orders from the last 6 months, filtered to returned orders, sorted by creation date (ascending)
- Action: Count — count the number of returned orders
-
Condition: Count is greater than or equal to 2
- If No: The workflow ends here — the order is not flagged
- If Yes: Continue to the next step
- Action: Batch query orders (1) — retrieve the refunded amount for each of those returned orders
- Action: Sum — add up the refunded amounts from the returned orders
-
Condition: Sum is less than or equal to $20
- If No: The workflow ends here — the pattern doesn't match low-value, high-frequency return abuse
- If Yes: Continue to the next step
- Action: Create Order Risk Assessment — flag the current order as high risk
- Action: Cancel Order — with Refund and Restock Items turned on, and no customer notification, so the cancellation is silent