Dear Triggre-Team,
In my alex-schilder.triggre.net domain I’ve probably made a mistake somewhere in an automation flow which adds EmployeeApplications.
Let’s first start where it all begins: I’ve got an user-flow which is called: ‘Wijziging medewerker’, where I’ve got a page which is ‘Applicaties toevoegen’. In this page I’ve got on the left side 2 tables where the first table is:
all the ‘available’ applications (applications which the employee hasn’t got already and the applications which haven’t been chosen already).
And where the second table is:
all the ‘applications’ which are already linked to the employee.
On the right side of the page there’s a table which shows the ‘RequestApplications’ where request = current request (from the funnel) and it shows an ‘action’ column, which is either add or delete.
So this all works fine as I’ve tested it and it all looks good.
However, when the request has been approved and realized (afgehandeld), then an automation flow (handleChangedEmployeeData) is triggred when the RequestStatus is edited to ‘afgerond’.
This automation flow triggres a flow (just one for now) part which is ‘AddAndDeleteEmployeeApplications’. This flow part check which RequestApplications have the action ‘delete’ and which RequestApplications have the action ‘add’, and then adds or deletes the right EmployeeApplications.
Now, I’ve tried to handle the request in 2 ways:
-Easily, like in 99% of requests this will be done in reality. So I’ve waited for each email (which is triggred by a change of status) to come in and then I’d do the next change
-Quickly, for tests, where I’d create the request, then right away approve the request and straight after handle the request.
If you handle the request the easy way, all goes well. This will be the case in 99% of the requests.
However, if you handle the request quickly (which might happen in practice as well), the EmployeeApplications are added 3 times.
Why I think this happens?
Well, I’ve got some automation flows running when the RequestStatus is edited. One of those automation flows is addEmployeeRequestPDF, where there’s first a PDF created where all the (changed) data of the Employee is being documented in the PDF, which takes a while apparently. When the PDF is ready, I add it to the specific request. I’m doing this in an automation flow so the user doesn’t experience any lag or performance issues when he’s working in the application.
So, this automation flow is triggred, and then when I directly approve the request and the status of the request is changed again from ‘voor akkoord’ to ‘in behandeling’, and I immediately handle the request again so the status is changed from ‘in behandeling’ to ‘afgerond’, this all while the addEmployeeRequestPDF isn’t ready yet. So, when addEmployeeRequestPDF is ready, I think it looks for changes of statusses of requests where the requestStatus is now ‘afgerond’ – that’s the status when it has to add the EmployeeApplications through automationflow handleChangedEmployeeData, so it adds the EmployeeApplications 3 times, because there’s been a change of status 3 times, but the current status is already ‘afgerond’.
There are 3 changes of statusses:
– From ‘concept’ to ‘voor akkoord’
– From ‘voor akkoord’ to ‘in behandeling’
– From ‘in behandeling’ to ‘afgerond’
This is the only explanation I’ve got for adding the EmployeeApplications 3 times when I handle the request quickly.
In addition, the emails which are triggred through the automation flow don’t go well either, I get the same email (the one of ‘Aanvraag afgerond’, flowpart sendMailToITmanagerAndHRmanager which is triggred by automationflow sendRealizedMailToRequestor) multiple times for one request, so here I think the same problem applies.
So the questions here are:
- Am I right?
- If so, how can I overcome this issue? Would it be a solution to have 1 automation flow for everything I do with requests? Instead of multiple automation flows which are triggred by a change of RequestStatus?
Thanks in advance, I hope the explanation here is clear and I hope we can fix this issue soon, so I can go live with my application.