I have an automation that uses a webhook trigger. we need to purge the logs and bulk process. when i purge obviously it clears the logs and the next run just stores everything without processing. and i believe since it is a webhook trigger, i cannot manually execute and export all data. is there a way to add a single dummy row to the stored data table?
A webhook trigger automation processes the received data every time it is invoked.
What you are describing about storing the received data without processing the first time is only for polling automations.
the trigger uses a webhook module to pass in some parameters when it is called, retrieves data, emit unique items module, etc. This all happens in the entirely within the trigger.
for reference, here is the automation in question.
fec07be1af73484b84d6e1b3bfd3c90f
I think you would have to add temp logic to your trigger assembly to fetch or mock up a single data row, send the webhook manually via curl so it then stores that single row, then undo the temp logic in the assembly. The next time the webhook is received it will then process normally.
If you think you will need to do this again in the future, might be best to add a query param to the webhook url when invoking it for the reset, then use a Query Parameter module in the assembly to check for the reset mode and use that as a condition for the logic to store a single row. Then you wouldn’t have to do the manual assembly edits again in the future when resets are needed.
but if i change the trigger logic and save with anything to create that temp row, it purges the logs again since the trigger reset. so i didnt think it would hold. or am i missing something
Try and see, I don’t think it will purge when saved.
does having the webhook module in there and causing it to auto clear the unique row identifier on the trigger module have any affect it?
Your trigger is a hybrid, I have no idea b/c we haven’t built something like it ourselves. Try it and find out.
(yes edit/save purges)
so maybe i am going about this wrong. the reason i am using the webhook module is i need two distinct triggers to call the automation, and i need the automation itself to have a singular trigger to store the processing together and not have two automations with separate logs and the chance for double processing. The webhook module is just there to pass in a parameter easily when i call it using an execute automation module. is there a better way to handle that?
If 2 automations are invoking it via an “execute automation” action, then it seems the webhook module is not needed.
what would i use to pass through a value though? that value is being used as part of the initial query? i thought the only way to do that is execute automation action and a webhook module in the trigger to catch.
The parent automations can pass a query parameter value in the “execute automation” action. The trigger assembly can use a Query Parameter module to fetch the passed value.
used the query param module and same result but i was able to work around while using an emit head module, run it once only allowing 1 to go through, saved that value from the logs, then disabled the emit head and let the rest process only to go back and purge that original single value from the logs to catch up. sort of convoluted process to get what i needed but it worked.
yeah, what you are doing isn’t a typical scenario
yeah my use case is centralized around needing separate triggers, one time based and one on demand. if i put them both in the same automation it only uses an AND case between them instead of an OR. so i had to separate the automations into two different triggers which called a single automation to do all the processing. I needed it to use a single because if they were separate then records would be processed in duplicate.
in the long run it might be helpful to be able to choose if multiple triggers is AND or OR. as is, if it is a time trigger it defaults to and with no way to change it
Early in the system’s development the multi-trigger AND/OR logic could be toggled.
We undid it b/c it was causing too much confusion and we generally didn’t find use cases that needed it.
i know typically my use cases are atypical (there is a joke there im sure). how would you recommend handling that case above? or is what i did the best case?
Nothing better really comes to mind. Is a good approach given current system functionality.