Merging three different automation rules to one rule

[Jamshaid]

I have the following three rules that are working separately. I have around 40 type of projects where I will be implementing these rules. Each type of project will have the same sort of logic but key differences will be there. If I stay with this structure, I will need to handle 40*3=120 rules which will become much difficult to handle. I am unable to merge these as if the first one fails, the other two will never run keeping then one after the other in a single rule.

Rule 1

Rule 2

Rule 3

[Bill Sheboy]

Hi @Jamshaid 

Are you trying to merge the logic of the rules into one single rule, and / or...

Are you trying to use three rules to span all of the possible 40 projects, or...

Something else?

And, what are the types of your projects: company-managed, team-managed, JPD, etc.?  That will impact what can be done and how any merging could happen.

Kind regards,
Bill

[Jamshaid]

Hi @Bill Sheboy 

I am trying to merge these rules to one. The project is company managed project.

[Bill Sheboy]

First thing: given some of the possible rule collisions and uncertainty in the rules shown, I recommend pausing to meet with your Jira Site Admin, explain the initial need, and ask for their help.  Until that happens...

I am still unclear on what the "40" represents and what problem the rule is trying to solve.  That is, "why do this?"  The images are truncated and do not show all the steps, making them more difficult to compare.

Let's start with: what problem are these rules trying to solve?  The "why" not the "the how".

Next, what is the "40" part of your scenario?

• are there 40 possible values in a custom field which the rule needs to check, one by one
• are there 40 different Jira projects for the rule to run against
• something else?

Next, the rule uses the undocumented list function contains() on a list of values in a condition:

{{relatedCT.split(",").contains("CT179")}}

This will produce a list of true / false values, not a text value.  And so when the result is compared to a text value with the "contains" operator in the Smart Values Condition, that result is also undefined / undocumented.  I recommend instead just testing with the operator and removing both the split() and the contains() function.

Finally, I grabbed the images of your rules and put them side by side for comparison.  They are quite similar, and without knowing the "why do this" or what "40" means:

• Rule 1 and rule 3 could be combined using an if / else block, with branching to linked issues in each one
• Rule 2 creates work items in the PEN project while the other rules could be running.  This will lead to collisions and unpredictable behavior of at least Rule 1.  Mapping out everything that needs to happen in the scenarios may reveal a better approach.

[Jamshaid]

@Bill Sheboy  this is what I am trying to achieve

🥅 Goal
Prevent duplicate issues in slave projects (e.g., CT1) from the same parent issue (e.g., CM1_1).

🧩 Problem
Multiple questions in CM1 can trigger issue creation; with ~60 data points, backend de-duplication is necessary.

🔄 Baseline Behavior
When CTs are created initially (Week 1), ensure only one issue per CM1_1 per type.

⚙️ CT List Generation Step
Compare new CT_list (from current questionnaire) with existing linked CTs for CM1_1.

For each CT in CT_list:

If no active CT of that type exists → create (unless automation rule already handles it).

If an active CT already exists → do nothing.

For CTs not in CT_list but previously created:

Mark them as inactive.

Note:
CT_list contains the keys of the project where the issue needs to be created. These CTs are basically 40 — that’s what I meant earlier.

This version should render well on the Jira Community, with proper headings, bullets, and highlights. Let me know if you want it shortened or reformatted further.

[Bill Sheboy]

Have you tried creating a single rule as you describe it above?

Perhaps using if / else blocks for the top-level condition checks, with any needed branching inside each block.

[Jamshaid]

it breaks if the first condition does not meet. it does not check for other conditions

@Bill Sheboy 

[Oleksii Melnyk]

Hi @Jamshaid !
Hi! You can use Lookup tables, where the key will be your unique projects and unique values ​​for them.

After that, you can use "if-else" conditions to define your projects and use values from this tables

[Jamshaid]

Thanks. Could you please share some resources regarding this

[Oleksii Melnyk]

I think it must be similar to these screens, but of course you need to add your own actions.

In this case if you have issue created in Project A, it will be cloned with summary CLONE - 1. If in the ProjectB, summary will be with number 2

More details: https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Create-lookup-table/