I have an automation rule for team managed projects, that has been successful before and now is not working.
Essentially in one project (Deployment) when I'm transferring a specific Sub task to done, I had a issue created in another team managed project (SOC Team) with an associated slack message.
Original Automation Rule:
And when it last worked:
I tried to recreate it as a branched rule to no avail.
the error it claims is
which to me is saying that the Deployment project (10075, i think) doesn't have the Issue type "Awareness Post" (10130), which true, it is only in the SOC Team (10050, I think) project and thus can't grab the required fields. But this has already worked, why is the call to a different project now broken?
FWIW, the Scope claims just "Deployment" on these "some errors" when the actual scope is Multiple Projects, which it shows for the previous "success" automations.
Any help is appreciated, thanks!
its not letting me reply in comments, but
@Bill Sheboy Thank you very much for the quick input. I will find time to try that configuration, but any idea on how this original automation was working but now no longer is?
as a hail mary, one change I've noticed is this message from jira
"Your teams are using a lot of automation. At your current rate of usage, you may reach your limit before the end of the month. See automation usage "
does encroaching on this limit (first time we ever have and most likely ever will) , somehow affect these type of cross project automation calls? Huge shot in the dark there, but everything else seems consistent from when this rule was working prior.
I got this very error when using a wrong smart value ({{issue..customField_xxxx}}) in my rule to set the automation. So if anyone ever stumbles upon this post, check for double dots as this will cause this error.
The same issue appears for us today in our automation rules, using a company-managed project. As a test, we switched from the create action to the clone issue action and that worked. After the cloned worked, we switched back to the created action and this started working.
Not sure why at all, maybe it captured some values correctly in the metadata but this did allow us to get around this error we were seeing, but is certainly an issue that should be reported to Atlassian.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sometimes rules get "glitched" / broken due to repeated update / publish cycles. That symptom seems to be caused by a problem in the rule editor storing some incompatible data or not updating it. (Other posts have observed it happening with the create (or clone) issue action and selecting fields from the dropdown list without then clicking on the background to de-select the dropdown list before entering field data.)
The ways to generally check for this is:
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is great and very insightful, though the "glitch" is never fun to experience. I didn't even think to disable it and wait since we were just trying to get it working again. I will certainly keep this in mind, but hopefully we don't see it again.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Mario Anthony Camillo -- Welcome to the Atlassian Community!
I hypothesize this is a symptom of the intermittent type problems caused by each team-managed project (TMP) having distinct values for types, configurations, etc., leading to scope confusion in rules. The difference in behavior you see when the rule creates the issue on the main flow versus within the if / else block seems further evidence of this.
There are several similar defects in the public backlog for rule conditions and actions, but not this specific symptom.
Often the only workaround is to use the Send Web Request action to call the REST API endpoint for Create Issue to explicitly select the project and issue type by id:
Kind regards,
Bill
UPDATE:
Sorry, I missed your earlier question about usage limits. That is likely unrelated to the symptom you observed. Instead it indicates Atlassian is monitoring your rule usage and forecasting you will run out before the end of the month, based on your license level:
I recommend working with your Jira Site Admin to check your current usage, which rules are running frequently, and decide next steps. When the usage limit is consumed, your rules will halt for the entire site, so being proactive is key.
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.