Wanting to build out selection of Ticket Type → (Incident) → Incident Category (this is initially hidden and shows up fine after selecting Incident - this part is working):
In the above example, the “Incident Category” object is never presented, despite the group being previously set (and used previously to show the Ticket Type object):
If I change the condition from a “set to” selection to “Not Set”, the “Incident Category” object does show up once you select the Ticket Type (intended behavior, except we need to use the Group selection as a filter - so if it’s set to an IT team it will add in the IT incident options (I’m stripping them all out in a previous step):
Type is incident works. I need “Group is” to work, and it’s not. I believe there is a bug here. I’ve simplified these rules down by just always displaying the group + type, and still nothing. “Group not set” works in combination with “Type is Incident”, however my goal for conditions is “Group is ABC Help Desk, DEF Help Desk, GHI Help Desk, etc” + Ticket Type is Incident THEN show the Incident types object. The groups are not registering as having a value, even when they do, rendering the “group is XYZ” useless. Everything looks like this:
I do not, and it’s really preventing me from implementing Zammad at this point. I’ve passed it on to a web developer I work with regularly - he is familiarizing himself with the system and going to try and see if this is a simple fix or not, at this point I’m waiting to see what he says.
The general hiding of the fields works well. Also showing the fields based on objects that are present with the general Zammad installation like group or type works great. If you change the rule that a certain value of a self created selection field is requested, it does not work anymore. If you use the operator “was changed” it works. @dominikklein which version are you using?
Are you able to show us steps on how you set up your workflows, etc.? I’ve deleted rules, reinstalled zammad, etc. at this point - I can’t get my example to work at all. I installed from the package, not from source - I’m not sure if that would make a difference. Are there logs I can check for workflows firing?
At least for me, your example with only the “static” Zammad fields from the screenshots is working (but maybe it’s one simple piece that I did not completely reproduce).
So I found something in addition to the custom select fields that may be contributing to my specific case.
Context: Each org in my environment will have 4 groups: Information Technology, Maintenance, Materials Management, Human Resources - we don’t want other orgs’ groups showing for end-users outside those orgs - in theory this should all work well.
I have a workflow early (priority 1) on that removes all groups from the group selection, and another (priority 2) that adds specific ones back later on based on the user’s organization (The specific named groups mentioned above that are named after their specific org).
In my testing, it appears that once a group is removed and added back, its value is no longer considered in core workflow logic in later workflows down the line of priority. Removing the step that removes them, and changing the org specific filtered workflow to instead remove all other groups vs adding back the org’s specific groups allows it to work, as the group is never removed and then added back.
