0

I have created a CiviRule that Triggers on "Email address is added" with a linked condition of "Field Value Comparison Email.is_primary = 1"

It is triggering and the action is happening. However, it is happening 2Xs. Which shows an error message to our users.

In API4, if I select Email > get -> Where Contact id = xxx; it shows 2 results. If I select Email > get -> Where Contact id = xxx & ->Where email is primary - yes; it shows 1 result.

The activity that is happening when this triggers is a contribution from a first-time donor. Any ideas why the Link Condition above does not limit my trigger to 1X? Thanks

Here are the screenshots of the Rule setup per request of jitendra enter image description here enter image description here

EDIT: I added more information being sent to the logs. I can now see the Email ID # along with the condition value (per suggestion of ErikH). It is not getting the correct condition on "Email is Primary=1". That is showing 1 for both times but the email table has one with 1 and one with 0.

I added to the condition "& Location Type=Home" Now it just processes the rule 1x.

enter image description here

9
  • I have also switched the condition to No. It did not trigger the CiviRule. I would have expected it to trigger 1x for either condition. The email table has 2 rows when a CRM user is created, one is Primary and one is not.
    – Iowa Boy
    Nov 4 '20 at 16:18
  • Can you check if the condition actually checks the correct values? Nov 5 '20 at 7:44
  • How do I check that?
    – Iowa Boy
    Nov 5 '20 at 15:57
  • You can debug the isValidCondition function in CRM_CivirulesConditions_Generic_ValueComparison Nov 6 '20 at 8:28
  • Not sure if this depends on how your rule is configured. Can you add a screenshot for the complete set of triggers? Nov 6 '20 at 11:43
2

Check to see what your default email location type is and add that as the second condition: "AND Location Type = [default]"

The issue was that both email table entries (Home & Billing) are initially created as Primary. But the non-default email is then updated to not Primary. So the CiviRule processes before the non-default email update happens. .

Thanks to ErikH and Aidan for their help in troubleshooting this.

3
  • That works for you Iowa Boy, but is not a generic fix. People could use other location type than home as default ones. The "real" fix should check why it compares the same value twice. Also, I would recommend to change your fix to check for the default location type so it remains flexible? Nov 11 '20 at 7:34
  • Thanks ErikH. Just to be sure I am understanding you, 1. I can change a setting so that the billing email is not set to primary in the Insert process? 2. or do i need to adjust the answer above to have step one check to see what is set as the default email location? Or 3. You can submit the proper generic answer and I give it a vote.
    – Iowa Boy
    Nov 11 '20 at 15:51
  • I meant step 2 for your fix :-) And I guess in CiviRules the fix would need to be to add a check to see if there are more primary ones or smthing like that. My concern with your fix would be that this would not be correct if someone decides to have another location type as Home as the default one? Glad you found your fix, could you please add an issue to the CiviRules repo (lab.civicrm.org/extensions/civirules) for the generic issue (which your fix only partially solves as stated above). And refer to this thread? Could be a postCommit would also solve the issue. Nov 11 '20 at 16:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.