Skip to main content

Hello,

 

I created a custom event that triggers on add, update, and delete.

 

This custom event calls a workflow, and when creating a new work task, I get this error.

 

I no longer get an error if I modify the event to trigger only on creation, but having both creation and update enabled at the same time causes issues.

hello ​@NINO 

what doyou do in your workflow, my guess is that if you update the work task, then it trigger again the workflow as you tick update and you will then get a never ending story (update triger the update that rigger the update...)

best regards

vito


My guess is that the issue might be caused by a recursive trigger between the workflow and the custom event.
It seems that when the workflow creates a new Work Task, this new task is again triggering the same event (and workflow), causing an infinite loop.

You could try the following steps to confirm and fix it:

  1. Add a condition to your custom event so that it doesn't trigger when the task is created by a workflow.
    For example: &NEW:CREATED_BY != 'WORKFLOW'

  2. Review the workflow design to ensure that the “Create Work Task” step is not calling back the same event.

  3. Temporarily disable the workflow and test creating a task again – if the error disappears, that confirms the recursion.

So, it’s likely not a data problem but a configuration loop between the workflow and event definition.

 

 


For now, my workflow doesn’t do anything — it’s just a JS script that runs independently without any interaction.

 


For now, I only have issues with this table, JT_TASK_TAB. On other tables, I don’t encounter any problems — the workflow is identical and the event is configured in the same way


It might be related to the event trigger or projection access specific to the JT_TASK_TAB table. Some technical tables require explicit event configuration or additional permissions.


Okay, I’ll keep investigating :) From what I understand, the MAINT_ENG_APP_P002 and SERVICE_ENG_APP_P002 triggers are also being executed in addition to my three, which could be causing the issue.

 

But I don’t know if these triggers are part of the IFS Cloud standard.


It’s likely caused by multiple system triggers on the same table. Instead of disabling them, try limiting your workflow event to specific actions (like INSERT only) or add a condition filter.


@Mehmetkilivan yes, it works if I set it to insert only. The problem is that I also need the update trigger.


I enabled the watcher to see the events coming into my workflow, but the events are identical and arrive at the same time.

 


That’s a good observation. The identical events might happen because IFS sends the same payload for both INSERT and UPDATE actions in some projections. It’s not a bug, but a system behavior.
You could try checking the trigger type or rowstate field in the event JSON to distinguish them — it’s not a perfect fix, but usually the most effective workaround.


just a stupid question, but does it works if you trigger only on update (not on insert) ?


@Mehmetkilivan Interesting — if I add the row state to my custom event, it works.
I get three calls, but it works.

 

Thanks


just a stupid question, but does it works if you trigger only on update (not on insert) ?

No, it only works if insert is enabled, but update or both don’t work. :( => Except with the row state — in that case, it works. :)


Great! Thanks for testing it out, Nino. Yes, I also noticed that behavior adding the row state makes it trigger multiple times, but at least it works consistently.