I have a few scenarios in my application that depend a user interaction via editing a form screen. When the form is submitted, a workflow is run that triggers a webhook and notifies the assigned user of the changes. Unfortunately, I have found that the user editing the form screen tends to make sometimes as many as 3-5 submissions within a 10 minute period, likely because they are second-guessing their changes or needing to leave the app to gather additional data for the form.
I’m curious on any ideas folks have in capturing these changes as a group vs. responding to each individual update. The notifications need to be fairly real time, however a 10 minute notification buffer could be acceptable.
I have considered checking the last updated date I store in the target table for the same day or (TBD) some time period and only firing a notification if the update has not yet taken place. The challenge is that if the user makes other changes, they may not be reflected yet when the notified assigned user checks at the first notification (based on the user behavior I see). I might also consider moving this to a half hour frequency scheduled workflow but will need to determine if that truly reduces the total Glide update usage or not.
If I weren’t using Glide, I might try to catch all updates and de-duplicate them by the user and relative time and only send one notification, but doing this in Glide seems a bit cumbersome.
What is the nature of the notification? Glide has a native “Show notification” action that doesn’t require any integration and therefore won’t use updates.
If editing the information is a scattered process by nature and you notify users at every update and you concerned about your update count, then I think you have three options:
Amend the user experience to force users to not scatter their updates. If it’s an issue with fields being left blank, then you could make fields required. Or perhaps set a visibility condition on the submit button if you are working with a custom form.
Change the way you notify users, either the nature of the notification (what I suggested above) or the frequency (you referred to this).
Scope how many updates you might expect and see if this aligns with your budget. Additional updates first $1 per 50 updates and the number of updates on your plan can be set to not be capped (in number of updates).
Is there an opportunity to send updates to a helper table, then aggregate updates for each user every 10 minutes?
Say user 1 might have updates for project 1, project 3, project 4 if there are updates for them in the last 10 minutes. Then you clear the “notified” rows from the helper table when the flow is completed.
Might still be pretty costly, but less than the way you’re doing it now.
The nature of my update/notification is a trigger webhook (99.9% of the time for a transactional email).
The purpose of this post was to go deeper into potential logic for #2 in your suggestion, but simply adding a “notified” bool might be enough.
This also might be a good solution, I would need to only log updates once, so maybe a workflow can check if the row ID for that particular user exists and not add an additional row if that’s the case.
I need to think about this one more but you guys gave me some good stuff to think about. Thanks.