What is causing this new Automation error? Error retrieving the issue type fields for project/typeId

[Mario Anthony Camillo]

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. 

[Birger Robrecht _avono AG_]

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.

[John Isherwood]

Hey good catch @Birger Robrecht _avono AG_ , my particular issue was a missing moustache bracket after a curly bracket, but the same error resulted.

[Mark HIGGINS]

Hi,

I just spent an hour chasing my tail, with this error, only to discover that one of the smart values in a field I was setting didn't have the }} on the end.

Not sure, the error message, meets the error

Mark

[Sonya McNeely]

Yeah, the error message hilariously does not meet the error. So, I was lucky to find this post and these comments point me toward the actual culprit being a smart value not resolving appropriately. 

[David Corlette]

I just ran into this with my system. I'm using Automation in Confluence to create tasks in Jira based on page contents. The whole thing was set up by one user, but then that user left the organization and their account was disabled. We had already transferred ownership of the rule and the "Acting as" for the rule to a different user. But it turns out that each individual "Create Jira issue" task in the Automation workflow also has a Connection to Jira that was under the old user account. Thus, when the connection attempted to fetch the issue types for the target project, it would throw a similar error ("Error retrieving work type for ...").

Personally I think that error message isn't very helpful - what's a "work type," we call them "issue types" everywhere else! - but using the drop-down next to "Update" and running a rule Validation revealed the real issue. We just had to re-create the Connection under the new user account, and then reset all the Create Jira Issue tasks to use the new Connection.

So two lessons from this:

1. Update dropdown > Validate rule is your friend ;-)

2. In addition to the top-level rule ownership, certain tasks also have Connections that are also owned by specific users.

[Julian Governale]

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. 

[Bill Sheboy]

Hi @Julian Governale 

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:

1. Disable the rule, wait a minute, re-enable it, and then test once more.  If that does not clear the problem...
2. Disable the rule, and re-create it from scratch, and then test.  If it works, delete the original rule.

Kind regards,
Bill

[Julian Governale]

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. 

[Bill Sheboy]

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:

• https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828
• https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-post

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: 

https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/#What-are-my-usage-limits

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.