Active Directory Attributes in Power Automate Desktop

[jtwohig]

I am just starting with Power Automate Desktop and am trying to create flows to add, read, and modify users in Active Directory.

It is really easy to do something but I can't see how to do much. I can get user info, create users, and modify users but it seems like only a few fields are available. 

In particular, I want to be able to check and populate the user principal name, employee number, and proxy addresses. There is a large list of attributes that might be useful if we could populate them automatically.

Am I missing a way to get at the other attributes?

[JamesP_MSFT]

Hello @jtwohig. 
The dedicated group of actions for Active Directory offer a plethora of fields for user creation/modification.
Regarding the checking, please user the Get user info action and take a look at the generated properties of the output variable.

[jtwohig]

Thanks. I will take a look when I am back in the office on Monday.

[jtwohig]

@JamesP_MSFT  When I did the Get User Info it only showed a few fields.

In Active Directory there are dozens more with the key ones for us being UPN and proxy addresses. If they are not correct when the accounts are created in Active Directory then when the AD Connect sync happens they get set up incorrectly in Office 365 and the only fix is to delete them and do it again.

Could I be doing something wrong with Get User Info that is only getting me those few fields?

[HoldTheDip]

I am looking for the same solution.  How to edit Active Directory attributes with Power Automate Desktop?

[mike-crowley]

You can pass the object's DN to a "Run PowerShell script" step and do whatever you want from there.

e.g.

set-adgroup %group_dn% -managedby %manager_dn%

[jtwohig]

Yes. But if I am going to have do some of it in Powershell I might as well do everything in Powershell. There is no need to use Power Automate. It would just be adding another tool and one more thing to go wrong.

[mike-crowley]

I agree with your general sentiment - searching for an in-box solution is what led me to this post in the first place, and I was just circling back to post a solution as a good citizen of the internet. 🙂

I don't fully agree with your comment however. In my case, I'm doing a bunch of work in Power Automate Cloud Flows, handing a bit off to the desktop, where most of it is addressed by the in-box connectors, and then sending the output back to the cloud for more processing. I wouldn't want to throw out all of Power Automate because I can't do this one step with a native connector.