Quickbase Pipeline Not Triggering When a Summary Count Changes? Trigger From the Child Records

A question in the Quickbase community asked why a pipeline never runs (original thread here). The setup was a leave request with several approvers. Each approver's decision is its own record in a child table, and the leave request has a field called # of REQUEST DECISIONS APPROVED. The pipeline was a Record Updated trigger on the leave requests table, filtered to "# of REQUEST DECISIONS APPROVED equals 7". All seven approvals came in, the count showed 7, and the pipeline did nothing.

The short version: the count is a summary field, and a summary field changing doesn't count as the leave request being updated. The fix is to move the trigger down to the decision records, where the saves actually happen.

I rebuilt this in a sandbox app with a Leave Requests table, a Request Decisions table and seven approvers, so the behavior below is what I saw there, not just what the docs say.

Why the pipeline never fires

A field named "# of ..." on a parent table is almost always a summary field: a count of child records that match some condition, here decisions where Decision is Approved.

Summary fields (and lookups and formulas) aren't stored on the record. Quickbase works them out when the record is read. So when an approver changes their decision to Approved, the save happens on their decision record. The leave request itself isn't edited, and a Record Updated trigger only listens for the record itself being saved.

In my sandbox, Sarah Lee's leave request was created at 11:07 PM. I then approved her seven decisions one at a time. After each save I read the leave request back:

The count climbed to 7, but Date Modified never moved. As far as Quickbase is concerned, the leave request was never updated, so there is nothing for the pipeline to react to. The same thing happens with a formula field or a lookup field. Changing a value somewhere else won't fire triggers on the record that displays it.

The fix in one sentence

Look up the count from the leave request down to each decision record, then trigger the pipeline when a decision is updated and the looked-up count has reached 7.

The final approval is a real save on a real record, so the trigger fires, and at that moment the lookup on that decision already shows the new count.

Step 1: Look up the count onto the decision records

1. Open the Request Decisions table and go to Settings > Table-to-table relationships.
2. Open the relationship to Leave Requests (the one that the summary field is built on).
3. Under lookup fields, click Add lookup fields and pick # of REQUEST DECISIONS APPROVED.
4. Save. You now have a field on the decisions table called something like Leave Request - # of REQUEST DECISIONS APPROVED.

Yes, you can look up a summary field over the same relationship it summarizes. In my sandbox, the decision that was saved last came back with the lookup already showing 7, and every decision for the same request showed the same number.

While you're in there, look up anything else you'll want in the notification, like the employee's name, dates or the manager's user field. The pipeline can read lookup fields straight from the trigger record, which saves an extra step.

Step 2: Build the pipeline on the decisions table

Create a new pipeline (or edit the existing one and swap out the trigger):

1. Trigger: Quickbase channel, Record Updated.
2. Table: Request Decisions (not Leave Requests).
3. Fields to watch: pick only your Decision field. Without this, any edit to a decision record, like a typo fix in a comment, can fire the pipeline once the count is already 7.
4. Filter conditions:
   • Leave Request - # of REQUEST DECISIONS APPROVED equals 7
   • Decision equals Approved
5. Action: your email or notification step. Use the lookup fields from the trigger record (employee, dates, etc.) in the message.

The second condition matters more than it looks. Say a request has eight approvers and the count is already 8. If one of them changes their mind to Denied, the count drops to 7 and the Decision field changed. Without "Decision equals Approved", that denial would send the "fully approved" notice.

If you need fields from the leave request that you didn't look up, add a Look Up Record step on Leave Requests using the decision's Related Leave Request value as the Record ID#, and use its fields in the message.

If the number of approvals isn't always 7

Pipeline filters compare a field to a fixed value, so "equals 7" only works when every request needs exactly seven approvals. If it varies, do the comparison in a formula:

1. On Leave Requests, add a numeric field Approvals Needed (or a summary that counts all decision records for the request).
2. Look it up onto Request Decisions, same as Step 1.
3. On Request Decisions, add a Formula - Checkbox field called Final Approval:

[Leave Request - # of REQUEST DECISIONS APPROVED] >= [Leave Request - Approvals Needed]

4. In the pipeline, filter on Final Approval is checked and Decision equals Approved.

In my sandbox, Final Approval was unchecked on the first six approvals and came back checked on the seventh save, which is the one you want to fire on.

Stopping it from firing twice

Watching only the Decision field handles most extra runs, but a request can still reach the target count more than once. For example, someone approves, changes to Denied, then back to Approved. If a second notice would be a problem, add a flag:

1. On Leave Requests, add a checkbox Approval Notice Sent.
2. Look it up onto Request Decisions.
3. Add a third filter condition: Leave Request - Approval Notice Sent is not checked.
4. At the end of the pipeline, add an Update Record step on Leave Requests that sets Approval Notice Sent to checked, using the Related Leave Request value as the Record ID#.

Now the first qualifying approval sends the notice and marks the request, and any later approval sees the flag and stops. This also covers the rare case where two approvers save within a second of each other, or someone approves several decisions at once in grid edit.

Testing it

1. Make a test leave request for someone like Sarah Lee, and add the required number of decision records, all Pending.
2. Approve all but one. Check the pipeline's Activity log. You should see no runs, or runs that stopped at the filter.
3. Approve the last one. The activity log should show one run that passes the filter and sends the notification.
4. Change any decision to Denied and back to Approved. With the Approval Notice Sent flag, nothing goes out the second time.
5. If nothing runs at step 3, open the last decision record and confirm the lookup actually shows 7, and that the trigger is on the decisions table and watching the right field.

Summary

• A Record Updated trigger only fires when that record is saved. Summary, lookup and formula fields changing don't count.
• Approvals are saved on the child decision records, so put the trigger there.
• Look up the parent's approved count onto the decisions, and filter on that lookup equals the target plus Decision equals Approved.
• Watch only the Decision field, and use a "notice sent" flag on the parent if a duplicate notification would be a problem.
• For a variable number of approvers, compare the count to the number needed in a formula checkbox and filter on that.