Workflow trigger based on proxy address

How do your users get in M365 in the first place?

1) Azure AD Connect replicates them there
2) Active Roles creates them

If you are relying on 1), do you have ARSS backsynch configured to bring back users' AzureObjectIDs?  If not, then you could set this up and rely on the event of edsvaAzureObjectID being set on the on-prem AD object to determine that the M365 object exists (the mailbox should exist at pretty much the same time)

Hi Johnny,

We use AAD Connect to sync our users to Azure, we also have backsync in place to bring back users AzureObjectIDs. Unfortunately we add a user to a security group and this then assigns them a license, the time this process takes can vary so unfortunately we cannot rely on the AzureObjectID. 

Surely i can use the proxy address as a trigger given that ARS lets me set it in the first place, have you been able to achieve something similar in your environment? 

In your start condition filter, rather than "ProxyAddresses of Workflow Target contains X500" you should try "Changed value of workflow target object property" and enter the text 'X500'

So in your filtering conditions, you would end up with:

Proxy Addresses from Requested Changes contains "X500" (quotes added by AR)

In your start condition filter, rather than "ProxyAddresses of Workflow Target contains X500" you should try "Changed value of workflow target object property" and enter the text 'X500'

So in your filtering conditions, you would end up with:

Proxy Addresses from Requested Changes contains "X500" (quotes added by AR)

Hi Johnny, i tried what you put above however that didn't seem to work for me... 

In the Operator Conditions i have the following: 

Operation that starts this workflow: Modify Properties

Target Object Type: User

Workflow start upon a request for changes to: Any Properties

Initiator Conditions

Any User, Container domain.com

Filtering Conditions

proxyAddresses from Requested Changes contains x500

Have I missed something in one of the conditions? 

TIA. 

Hi infra_2020 

I suspect the reason why the workflow isn't being triggered might relate to where the change is being initiated.

As AAD Connect is changing the ProxyAddresses field natively in AD (as you'd expect), and because a workflow doesn't react to a DirSync Controls from AD, there is no trigger being raised in Active Roles.

Am I correct in saying that if you manually modify a Users ProxyAddresses to contain an x500 entry, the workflow fires no problem? Then successfully completes whatever your script aims to do?

The way around this would be to write a policy script which handles changes from DirSync Controls, which either just completes the required changes to the ProxyAddresses field, or sets an attribute to trigger a workflow.

This script would need to be in an Administration Policy, and you'd want to ensure you only deal with the exact request types you're interesting in, IE:

if ($Request.Class -ne "user") {return}

If($(IsAttributeModifed -Attribute "ProxyAddresses" -Object $Request)) {return}