Passing Variables from Workflow into Powershell Script

Have you considered an entirely different approach?

What I have done with some success is used dynamic groups populated using Active Roles virtual attributes.

Here's an example...

I want to give a user only an E3 license OR an E5 license

First group:  E3_License_Group
Second group E5_License_Group

Don't allow the Help Desk to directly manage the membership of either group.

Make the groups dynamic as follows:

Membership Rule for E3 group:

License_Granted = E3

Membership Rule for E5 group:

License_Granted = E5

Add the License_Granted virtual attribute to your web interface and add a PVG rule to your provisioning policy that allows only E3, or E5 or None as acceptable values.

Your "audit trail" for the licensing will be the change to the contents of the virtual attribute.

In my suggestion above, I forgot to explicitly mention that you should create a stored, boolean virtual attribute "License_Granted" (or whatever other name makes sense to you).

Thank you for this, its a very interesting approach to this issue and something for us to think about.  But we would really like to understand how to pass variables to our scripts when running them in AR workflows.  We have other workflows where this would be very helpful to know how to do as well.  Thank you.

There's a few ways to think about "variables" when it comes to Active Roles.

Typically, when you are integrating scripts, you want to work values from the current transaction that AR is processing.

Let's take a simple example - updating the Description of a user.

When you change a user description through the Active Roles UI, a "$Request" object is generated (this is what I call a transaction and its contents the "payload").

Within this $Request object are several useful things that can be accessed using various properties and methods:

$Request.DN is the distinguished name of the object being modified

$Request.RequestedAttributes is an array containing the property(ies) being modified in the current transaction

If you know which property is being changed, you can pull its value directly from the transaction like this:

$ChangedPropertyContents = $Request.Get("description")

OR if it's a multi value:

$ChangedPropertyContents = $Request.GetEx("somemultivalueproperty")

'Hope this is helpful.

Yes, this is very helpful.  So if a helpdesk user has added say John Doe with user ID abcjxd to an AD group, if we wanted the workflow to run a PS script to manipulate abcjxd, that object would be under the “$Request” variable? 

So we could essentially run the command remove-qadgroupmember -identity ADGROUPNAME -member $request.samaccountname  and it should work?

It's not quite that simple.

You would want to run your script to check whether the user is "allowed" to be a member of that group.

The thing to keep in mind is that the addition of a member to a group is a group change and thus the object in the $Request is the group.

The user being added is part of the group's member property change.

To learn a bit about the structure of your request, I would suggest you take this code and execute it with a change workflow triggered by a group member add to see what an inbound membership change $Request looks like:

function DumpMembershipChangeRequest($Request)
{
$str += [System.Environment]::NewLine + "Property values modified in the directory object" + [System.Environment]::NewLine

# This will get you the group being changed
$str += "Object DN: " + $Request.Name + [System.Environment]::NewLine

# ---- Retrieve properties from in-process data -----

for($i = 0; $i -lt $Request.PropertyCount; $i++)
   {
   $item = $Request.Item($i)
   $str += "Property name: " + $item.Name
   $str += ", Property value(s): "
   # ----- Retrieve Property values -----

   # This will give you the list of the members being added

   foreach($value in $item.Values)
      {

      $str += [string]$value + "// "

      $str += [System.Environment]::NewLine
      } #End of values parsing loop

   # ----- Write output into a log file on the AR server ----

   Add-Content "C:\TEMP\AR_Request_contents_dump.txt" $str

   } # End of request property iteration  

} # End of dump membership change request

The workflow though takes care of that... I have an if/else activity that checks to see if the user they are trying to add to the group is already a member of another licensing group.  If it IS a member of the other group then I want to run this PS script that will remove that user from the AD group.

If the user they are trying to add is NOT a member of the other licensing group, then proceed.  See snippet:

https://drive.google.com/file/d/159thqvUv8Jh2UQSNCHeKCLLQbjYCcLPC/view?usp=sharing

this is my condition:  drive.google.com/.../view

So the crux of it is that you need to get the AD object name of "Added Member" which is what I was trying to illustrate with the script above.

You start with $Request.Item which contains a list of property / value pairs.

Referring to the above script:

$Item.name will be "member" (the group property)
$Item.Values will be your added member name(s)

You could also try $AddedMembers = $Request.GetEx("member") which should return a list / array...though I am not 100% sure that will work.