Unanswered

Action announces fail though it was actually performed

(0) Share

Report

Posted on by TorTsuk Microsoft Employee

I am building a Power Automate flow that creates a task in one Azure DevOps project every time a task with specific characteristics is created in a separate Azure DevOps project. I can see that the tasks are being created as planned, but I am still receiving a 404 error for the action, saying that the work item I just created does not exist or that I do not have permissions to read it. This is also causing the rest of the actions in my flow to fail.

Categories:

Building flows

I have the same question (0)

All responses (5)

Answers (0)

Sort by

Expiscornovus 33,871 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

Hi @TorTsuk,

I see you in your screenshot the two scope actions are collapsed (Create item in OSGS and Update and Notify). Can you by any chance expand those scope actions and make screenshots of what is nested within those two scope actions?

Ideally a one screenshot of the failed flow run with the error messages of the nested actions and one screenshot of the flow setup in edit mode (so we can see what your design is). This will help us in with troubleshooting and finding the root cause of your issue.

Was this reply helpful? Yes No
TorTsuk Microsoft Employee on at

Like (0)

Report
Copy link

Link copied!

Sure here is a screenshot, the error text is:
"
{
"status": 404,
"message": "TF401232: Work item 47339031 does not exist, or you do not have permissions to read it.\r\nAzure DevOps ActivityId: 55e4aba2-4d35-4ff8-8767-5fa4356194eb\r\nDetails: {\"$id\":\"1\",\"innerException\":null,\"message\":\"TF401232: Work item 47339031 does not exist, or you do not have permissions to read it.\",\"typeName\":\"Microsoft.TeamFoundation.WorkItemTracking.Server.WorkItemUnauthorizedAccessException, Microsoft.TeamFoundation.WorkItemTracking.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a\",\"typeKey\":\"WorkItemUnauthorizedAccessException\",\"errorCode\":0,\"eventId\":3200}\r\nclientRequestId: 490a4771-c637-4b51-8ad0-96f0e65aae4b",
"error": {
"message": "TF401232: Work item 47339031 does not exist, or you do not have permissions to read it.\r\nAzure DevOps ActivityId: 55e4aba2-4d35-4ff8-8767-5fa4356194eb\r\nDetails: {\"$id\":\"1\",\"innerException\":null,\"message\":\"TF401232: Work item 47339031 does not exist, or you do not have permissions to read it.\",\"typeName\":\"Microsoft.TeamFoundation.WorkItemTracking.Server.WorkItemUnauthorizedAccessException, Microsoft.TeamFoundation.WorkItemTracking.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a\",\"typeKey\":\"WorkItemUnauthorizedAccessException\",\"errorCode\":0,\"eventId\":3200}"
},
"source": "vsts-eus.azconn-eus-002.p.azurewebsites.net"
}
"

Was this reply helpful? Yes No
Expiscornovus 33,871 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Hi @TorTsuk,

Might be a security configuration on the OSGS project?

In which area does this work item get created and does your account/the account you are using in the connection actually have read permission to view work items in that area node?

https://developercommunity.visualstudio.com/t/tf401232-work-item-78167-does-not-exist-or-you-do/826088#T-N826179

Was this reply helpful? Yes No
TorTsuk Microsoft Employee on at

Like (0)

Report
Copy link

Link copied!

No, as you can see in the screenshot - the Work Item is created, and ID of newly created WIT is provided in the error message.

I found an answer somewhere else and mark "no" under returning all work item fields. and it solved it.

I do have a different issue now - I am trying to write into custom field and no name I use for it works

Was this reply helpful? Yes No
Expiscornovus 33,871 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Hi @TorTsuk,

Thanks for sharing your solution.

Btw, I was not suggesting that you aren't able to create work items, obviously that part works 😁

It is possible to set security on area paths of work items, to be clear. That was the scenario I was talking about. That is a different permission setting than the one for the ability to create work items itself.

Was this reply helpful? Yes No