DevOps updates on behalf of another with Power Automate

I had a need to use automation to do DevOps updates on behalf of another person so when the DevOps adoption metrics were done we the stats were slightly more accurate. This can only be done using REST API and will need permissions. This post is part of the DevOps and Power Automate series.

DevOps with Power Automate posts

• Connecting and Creating an item in Azure DevOps
• Updating Start and Due dates and other fields
• Using DevOps Rest API
• Running a WIQL query
• Updating items without Notifications
• Updating a task on behalf of another person

YouTube Version

It’s on the backlog!

Permission required to makes updates on behalf of another

The trick to being able update on behalf of another is to update the ChangedBy field to another persons email address. This is not normally allowed, it breaks the rules. So the permission we need is to by pass the rules and make illegal updates.

Permissions are managed in Project Settings, you then click on permissions. Click on Users at the top and then click on the user being used in the flow to show their permissions. Under Boards check the permission for Bypass rules on work item updates. This needs to be set to Allow.

Make Updates on behalf of another

Now we have permission is ignore the rules we can test out a flow. In the REST API documentation for updating an item https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/update you will see there is a boolean parameter bypassRules. This can be added to the relative URI using & to separate the parameters.

In the body section I have added an update to the ChangedBy field. This update updates the State to active and performs it on behalf of Dan. In the task history we can see the update and see I did it on behalf of Dan.

Word of caution

By passing the rules also means that the updates behind the scenes that happen are turned off. If we change the state to closed using the same technique the we get an error when we open the work item.

So make sure you have checked the updates you are doing and include all the fields you need to update, even the hidden ones.

Second word of warning is no checks are done on the updates. So you can assign a task to an email address that doesn’t have access, or update to a state that is not valid. So treat this one with caution.

Conclusion

This is a very powerful trick. But should be treated with extra caution and it has made me double check permissions on a ew projects so access to by passing the rules is limited.