Monthly Approval Reset vs Automation Triggers in AppSheet

AppSheet AppSheet Q&A
,
1

Multi-Cycle Approval Workflow with Unreliable Email Triggers in AppSheet

I have an AppSheet application with multiple email notification workflows that are triggered based on approval and rejection actions by different user roles (Implementor, 1st Level Approver, and 2nd Level Approver).

Current Notification Flow

The intended email behavior is as follows:

  • When a new entry is created by Implementor, an email is sent to 1st Level Approver (working as intended).

  • When 1st Level Approver approves, an email is sent to:

    • Implementor

    • 2nd Level Approver (different script)

  • When 2nd Level Approver approves, an email is sent to (same script and recipient logic):

    • Implementor

    • 1st Level Approver

  • When 1st Level Approver rejects, an email is sent to Implementor.

  • When 2nd Level Approver rejects, an email is sent to Implementor (using the same script as 1st Level rejection).

  • When Implementor updates an entry that was previously rejected, an email is sent to 1st Level Approver to restart the approval process.

Current Implementation

  • Approval and rejection states are stored in multiple TRUE/FALSE columns.

  • Each email automation has its own TRUE/FALSE “Email Sent” flag to prevent duplicate notifications.

  • Once an email is sent, the corresponding “Email Sent” column is set to TRUE.

The Problem

Only the first notification (new entry → 1st Level Approver) works reliably.
All subsequent approval and rejection notifications behave inconsistently.

The core issue occurs when Implementor updates an entry after it has been approved or rejected:

  • To restart the approval process, I reset the approval-related TRUE/FALSE columns back to blank.

  • However, the email automation triggers depend on these approval columns to fire.

  • Resetting these columns causes the email triggers to fail or behave unpredictably.

At the same time:

  • If I do not reset the “Email Sent” columns, approval and rejection emails do not send again on the 2nd, 3rd, or later approval cycles.

  • If I do reset the “Email Sent” columns, they conflict with the approval reset logic and break other email triggers.

Summary of the Challenge

I need a solution that can:

  • Allow approvals and rejections to repeat across multiple cycles

  • Ensure each email notification fires only once per action (no duplicates)

  • Avoid breaking automation triggers when approval states are reset

  • Maintain a clean and predictable approval workflow when an Implementor updates a previously approved or rejected entry

Any recommended design patterns, best practices, or real-world examples for handling multi-cycle approvals with reliable automations would be greatly appreciated.

Thank you.

2 Likes
2

There may be more details required to know the exact issue, but it would be good to leave the TRUE/FALSE columns to either of the two states - TRUE or FALSE. It sounds that you are introducing a third state of blank.

It may be also worthwhile to explore what you mean by “blank”. Could you mention how exactly you make the column blank?

Is it not possible to set those TRUE/FALSE columns to just FALSE as a reset? Any specific reason a third state of blank is required?

2 Likes
3

Hi, I’m also involved in the project above.

The blank state is the “Awaiting action” state. We also have an indicator that uses the blank state to show that the entry is “Awaiting approval”. The false state is the “Rejected” state.

The approval state columns reset to “blank” whenever the implementor edits an existing entry that has been approved or rejected. This is to restart the whole approval process and to show that said edited entry is awaiting approval.

1 Like
4

Thank you. Could you update how do you make the column “blank”?

I would instead try creating an enum column with three options, namely

'Awaiting approval" , “Rejected” , " Approved"

and make the column required, so that any one of the three options is always necessarily selected. I would then use that enum column in the desired expressions.

My feeling based on the details shared so far is the third “blank” state in the Y/N two state columns is creating an issue of unpredictable behaviour you are seeing.

This may or may not be the final or only issue. However I believe using a three state enum column is a much cleaner implementation.

2 Likes
5

I was helping a client a couple of years ago where they were struggling with the same challenge. The problem was the stale data in their devices, people closed their laptops before the data was saved, etc. When we changed all approvals and rejects into another child table, the process was much easier to create and it started to be 100% reliable.

3 Likes
6

Nice, practical suggestion Aleksi​:+1:

1 Like