Trigger condition "created" not longer working

Hi Folks,

we’re having trouble with our triggers conditions.
They all worked properly since yesterday (when we just changed one string condition).
After that they don’t fire at any circumstances.

As all affected triggers start with the condition “Action is created”, we’ve set up a test trigger with just that one condition and now see that even that isn’t working. But if we invert the condition, it works. Details see below.

Is this a known bug/behaviour or do we miss something?

Thank in advance for any help!


  • Used Zammad version: 5.2.x
  • Browser + version: Safari 15.5

Expected behavior:

  • When using condition “Action is created” the trigger should fire every time a ticket is created.

Actual behavior:

  • When using condition “Action is created” the trigger won’t fire. Even if this is the only condition.
  • If we invert the condition to “Action is NOT merged into, received merge or updated” the exact same trigger fires.

Steps to reproduce the behavior:

  • Create a trigger with condition “Action is created”
  • Create a ticket (e.g. send an email to zammad)
1 Like

I have witnessed the exact same issue with our triggers.

1 Like

can you send me the output of “#: dpkg -l zammad” ?

Sure, this is on two affected systems, Ubuntu and Debian, the issue appears to be the same in both builds. I just noticed a new build version for Debian, so I upgraded and re-tested. The problem persists:

A slightly older build:

ii  zammad         5.2.0-1656011622.80bf57c1.focal amd64

The latest available build at this time:

ii  zammad         5.2.0-1656402719.ac194df0.bullseye amd64

Hi 7qubit,

at our system the output reads

| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version                         Architecture Description
ii  zammad         5.2.0-1656402719.ac194df0.focal amd64


I had exactly the same problem with the following version:


There was no error in the log. Simply “execute trigger” was missing.

I’m not sure if it has to do with the above mentioned version. but when I downgraded to “5.2.0-1655803594.29bf395d.focal” the problem was gone.

as i said i’m not sure if this version was the problem. i think there were other connections that i didn’t find it.

#: apt install zammad=5.2.0-1655803594.29bf395d.focal

1 Like

Same for me on Ubuntu focal, zammad 5.2.0-1656402719.ac194df0.focal

I then cloned and deactivated the auto reply trigger and removed this condition “action: created” from the cloned trigger. I was afraid that a mail would now be sent for every action, but this is not the case.

1 Like

As a workaround you can fix this in the database.


Find the trigger in table triggers. There you need to edit the condition column:

Replace this:

ticket.action: !ruby/hash:ActiveSupport::HashWithIndifferentAccess
  operator: is
    - create

with this:

ticket.action: !ruby/hash:ActiveSupport::HashWithIndifferentAccess
  operator: is
  value: create
1 Like

I’ve been forced to edit @sbrunecker s article.
Manual fiddling in the database is not suggested at any point.

Doing so can cause serious problems on several levels and may lead to serious issues.
Do not do it and wait for proper fixes.

Without proper warnings to copy cats you’re risking the security and stability of other users instances.
Please keep that in mind if you post workarounds or sketchy solutions the next time.



the fix is now in stable.

  • Wait for the package build.
  • Update your zammad.
  • Find all broken triggers
$ zammad run rails r "pp {|t| t.condition.dig('ticket.action', 'value').is_a?(Array) }&.map(&:name)"
  • Open your triggers in Zammad, check the ticket action and save them again.
  • Triggers should work.

At first, this didn’t appear to work on one of my testing systems, but I did get it to work eventually, here are my observations:

I upgraded to 5.2.0-1656576084.743b9821.bullseye and followed your steps. The Rails console command showed two affected triggers. I saved each trigger with the correct action. After saving the affected trigger they still didn’t actually trigger on new incoming e-mails and the Rails console command kept producing the same list of triggers.

My test instance has a few custom ticket objects I was experimenting with. One of which is a required field which needs to be filled in by the agent responsible for creating or handling the ticket. Only after disabling all custom objects (plus clicking on database update, and refreshing session), re-saving the triggers, the Rails console command didn’t show the affected triggers and they worked! Excellent!

After re-enabling the custom objects, the triggers still kept working as usual.

I have one more testing system which is affected by this issue and where I can try things without consequences. Would you want me to try specific actions or supply you with more details?

And you people probably don’t hear this enough: Thank you for your excellent work on this wonderful product and for being on top of these kind of questions in the Community Forums, it is really appreciated. :smiling_face_with_three_hearts:


Hi Rolf,

we also applied the fix and the triggers are working again as expected. Thx a LOT!


1 Like

Trigger for “Action is Created” is not working on CentOS install of Zammad.

Tried updating to the latest version and also running the command:

$ zammad run rails r "pp {|t| t.condition.dig('ticket.action', 'value').is_a?(Array) }&.map(&:name)"

Running this command found all of the triggers with the create action – but had no effect.

Also tried removing custom attributes, updating database, refreshing session, re-saving triggers and restarting zammad as mentioned by @dvanzuijlekom

New tickets are still not triggering the Auto-Reply trigger.

Release Details:

Name : zammad
Version : 5.2.1
Release : 1657222873.979ea9ca.centos8
Architecture : x86_64
Size : 461 M
Source : zammad-5.2.1-1657222873.979ea9ca.centos8.src.rpm

**also, this only seems to be affecting the Action is Created trigger – the Update Action seems to work as intended for me.

hi @dan3093 does the command still output triggers after you resaved them?

@rolfschmidt no, the command no longer outputs triggers. It only did so the first time I ran it.

I have also been running “tail -f production.log | grep trigger” to see if anything happens once the ticket is created in the system - but the log does not show any trigger events for when the ticket is created.


It appears that it is working. I had the trigger set to only send if it came from a customer and I was testing with my own email which is registered as an admin. Dumb mistake on my end.

Thanks for your support!

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.