Conditions on related modules


I have three conditions based on the same module that the workflow is run against, and one condition that is based on a module that is related 1:N to the same module that the workflow runs against.

The condition based on the related module seems to be ignored.

Could this be a permissions issue, how can I check?

Should the workflow check all related records on the many side? It does update all related records when I remove the condition on the related module.

Hope this makes sense

Many Thanks


I don’t really know enough about Workflows to answer your question, sorry…

But it seems your text contradicts itself - if you say the condition is ignored, why do you say that removing it changes behaviour?

This might mean that the condition is correct, but perhaps the action isn’t doing what you want?

Sorry I’ve written this wrong, I’ll edit thanks.

So it seems what’s happening is that if I have one condition on a field from the related module, and that field also has an action defined on it, then the workflow works as expected.

When I add another condition for another field in the related module, the workflow action doesn’t fire, even though I have test data that meets the conditions specified.

Does this make more sense :\

Maybe… I guess it all depends on which field, which condition, etc.

If you can reproduce this in the live demo, you know it’s not only a problem in your system; and you make notes of the list of steps to take and then file it as a bug to be fixed by the team.

1 Like

Thanks, I started to reproduce the steps, but after a while it lost my custom module and seemed to reset.

Pretty certain this is a bug in SuiteCRM though, as soon as I add a second condition on the related module, the actions never fire, even though I have test data to meet the conditions.

I’ll have to find another way to accomplish what I need for now.

Thanks for you help and input.

The demo resets are periodical, to clear up whatever people do in the app. So you could try and make a note of what time it happens, and try to figure out how often they do it. After a reset, start your steps, you should have enough time…

I am getting an error at step 5

1)Module Builder - Create custom “subscriptions” module with two drop down fields:-

2)Subscription Name - {AC,MT}

3)Subscription Status - {Active,Cancelled}


5)Studio - Create one to many relationship with contacts > subscriptions, contacts being the primary 1:n > Save and Deploy <<<<<Error here

6)Studio - Add drop down field to Contacts - {1-10,11+}

7)Add two test Contacts, set their trucks to 11+

8)Add two subscriptions to each contact. One subscription with Subscription Name set to AC, and the other set to MT. Subscription Status of all four subscriptions should be set to active.

9)Create workflow as follows:

10)Workflow module - Contacts

Conditions - {Contacts}Trucks=1-10,{Subscriptions}Subscription Status = Active, {Subscriptions}Subscription Name = MT


Set Subscription Status to Cancelled

  1. Change trucks to trigger workflow

I’ve looked through the log around the time I expected the AOW to fire.

There is a chunk of SQL that is throwing an error - #1054 - Unknown column ‘’ in ‘on clause’

This appears to be because the SQL is using the table name instead of the alias in the join

LEFT JOIN dvv_subscriptions [color=#ff0044]contacts_dvv_subscriptions_1[/color] ON AND contacts_dvv_subscriptions_1.deleted=0

LEFT JOIN dvv_subscriptions_cstm contacts_dvv_subscriptions_1_cstm ON [color=#ff0000][/color] = contacts_dvv_subscriptions_1_cstm.id_c

Does this look like a bug to you?

It will look like a bug to me if, when you fix it, the error goes away and the program works fine. :slight_smile:

Does it?

I discovered that one of the condition fields resides in the cstm table of the custom module, this is where SuiteCRM stores fields created in studio. The rest of the fields were created in module builder.

After uninstalling the module, adding the field in via the builder and redeploying, the SQL error went away. It seems SuiteCRM is not constructing SQL correctly in this workflow scenario.

However, the original problem still exists.

This is a tough one, I’m not sure what else I can say, I just don’t know enough to be able to help you.

If you have a list of reproducible steps for this bug, by all means open an issue on Github. But don’t get your hopes up about seeing it fixed anytime soon…

I have created a list of steps and reproduced the issue using the Bitnami installer

I’ll open an issue on Github



1 Like

Thank you.

Here is the link for future reference