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
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
Hi @Bill Sheboy
I am trying to merge these rules to one. The project is company managed project.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks. Could you please share some resources regarding this
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.