This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Is it possible to link a workflow to a managed unit so that it only acts on objects in the managed unit?

I have a manged unit that contains users that have not yet been synchronized to the O365 cloud. This based on a query of attributes 'vapso_associationstrguid_mailbox', 'vapso_cloudsyncstatus', 'vapso_cloudupdaterequired' & 'edsvaFirstEmailAddressUpdatedWorkday'. The purpose of the managed unit and Workflow/Script policy is to enable me to update the user's 'mail' attribute to the HR system once the user has been provisioned to the cloud or after a user request to change there email address.

I want to use a workflow (or other means) to inspect this managed unit and do the following:

1 For each user, set the 'edsvaFirstEmailAddress' attribute to the current value of the 'mail' attribute;

2 For each user, set the 'edsvaFirstEmailAddressUpdatedWorkday' to true. This is so that it then drops out of the managed unit.

I can mange the powershell script to carry out steps one and two above.

What I don't know is how I create a workflow and and then link it to the managed unit so that it only touches objects therein.

How do I do that please?

Or is it not possible to link a workflow to a managed unit?

  • Workflows are not really linked to directory objects.  "Change workflows" are triggered by actions such as an attribute update.  "Automation workflows" (which is probably what you want to use here) are simply triggered on demand or by a schedule.

    A workflow really offers little value here.  In this case, IMO, it would probably be just as good to create a "Scheduled Task script" type script module and launch it using an AR scheduled task.  

  • Thanks for the tip Johnny. I'll try that scheduled task approach approach.

    The second part of the puzzle is to use the change in the 'edsvaFirstEmailAddress' attribute to trigger a script that generates a CSV and sends it to the HR system. Presumably that could be done with a 'change' workflow?

  • Yes - that is correct.  So you would setup a change workflow that looks for a change to that property.  You can scope the "initiator conditions" so it only fires on changes to objects in specific locations and/or changes initiated by specific user(s).

    Within the workflow itself, you can embed a script activity that sends the information back to HR.

  • I was just testing a setting up a scheduled task and they don't have an option to link to a managed unit either?

  • There's no "linking" of those either.

    Your only "link" to the MU would be when you enumerate its contents in your PoSh script so something like:

    $MUContents = Get-QADUser -proxy -SearchRoot "CN=MYManagedUnit,CN=Managed Units,CN=Configuration"

  • It is absolutely possible to scope a Workflow to only affect the results of a Managed Unit.

    If it is a Change Workflow, set the "Workflow Options and Start Conditions" so that the Initiator Conditions are set to the "Any User" (or whatever is relevant) in the container of the Managed Unit.

    If it is an Automation Workflow, set the Search scope to be the Managed Unit.

  • Thanks again Johnny! I was expecting it to be like a policy where you can link it to an OU, ADLDS or MU.

  • Just had a look and I can see the options that you outline for the Change Workflow re Initiator Conditions focused on a Managed Unit.

    I can't see an option to set the Search Scope for an Automation Workflow. Could you detail that please?

  • I believe what Terrance is referring to is the scope of a search activity that you embed in the workflow itself to find the objects that you wish to process.  The results of the search will be presented as a list of distinguished names and can be referenced in a PoSh script thus:

    # Assumes Search Activity has been labelled 'MySearchActivity'

    $ObjectLIst = $FoundObject("MySearchActivity").get("distinguishedName")

    If you are already specifying your MU in your script as I suggested above, this is not required nor is the Search activity itself.