Passing user object to workflow script

Hi

I'm trying to get a workflow to run which will update extensionAttribute7 of a user object when it's been added to a group, based on the users job title.
e.g. Joe Bloggs gets added to the group, his title is IT, EA7 needs to be set to "03452"
Jane Bloggs gets added to the group, her title is Director, EA7 needs to be set to "56643".

My workflow identifies the correct user object, and if I specify the value of EA7 in the target properties as a text value, works fine, but because of the number of options for the value of EA7, I've had to create a script with a lookup table and I cannot figure out how to pass the users job title, or DN to that script.
I followed this KB to create the workflow and identify the user to be updated and my script will execute when it's specified in the Target properties.
(support.oneidentity.com/.../how-to-automatically-remove-a-user-from-specified-groups-when-being-added-to-another-specified-group)

I also read through this forum post, which helped me find the ActivityTarget method. I'm sure this must be what I need, but I can't get it to work.
(www.oneidentity.com/.../88312)

The best I can do is to use the lines

$user = $workflow.ActivityTarget
$user | Select * | Out-File E:\MC\Workflow\user.txtCode

Which then gives me this output

MemberType : Method
OverloadDefinitions : {System.Object ActivityTarget(string ActivityID)}
TypeNameOfValue : System.Management.Automation.PSMethod
Value : System.Object ActivityTarget(string ActivityID)
Name : ActivityTarget
IsInstance : TrueCode

But no matter what I change with the "$user = $workflow.ActivityTarget" line, I cannot get it to provide any information on the user object.
I've tried

$user = $workflow.ActivityTarget("Change object properties")
$user = $workflow.ActivityTarget("Add member to group")
$user = $workflow.ActivityTarget("Added member")

Which all produce an empty users.txt document, so I added the get method.

$user = $workflow.ActivityTarget("Change object properties").get("distinguishedName")
$user = $workflow.ActivityTarget("Add member to group").get("distinguishedName")
$user = $workflow.ActivityTarget("Added member").get("distinguishedName")

All of which result in "You cannot call a method on a null-valued expression" errors in the debug log.

Can someone please help point me in the right direction with this?

Many thanks

Matt

  • The tricky bit here is that from AR's perspective, the user is not the "workflow target" - the group is.

    What you need to do is mine the user name (i.e. added member) from the $Request (i.e. the in-process AR transaction that is being intercepted by your workflow).

    This article may prove helpful as a starting point.

    You could "embed" your script in the Update activity mentioned in the article - i.e. use it to calculate the value to be applied to the user instead of hard-coding something in the activity.

    Give it a whirl and come back here with further questions if need be.


  • Thanks  

    The article I linked seems to have pointed me in the same direction, so I can get EA7 to update statically, but I'm struggling with getting the activity target into the script.

    I've figured I can set the attribute to something static (e.g. the users DN), then get a second workflow to act on the user object directly once EA7 has been set to the DN.

    Is there a better way to pass the activity target to the script? Is there an option to get the $request.addedmember?

  • Hi  , thanks for the information.

    Apologies if there are 2 replies, I seem to experience issues posting and replying on here, it never seems to actually show that the action has finished!

    That's where I got to with this how to but I don't seem to be able to find the way to reference the user object when calling the script from the Target Properties of Change object properties in the workflow. Is there such a thing as $request.ActivityTarget?

    The only other way I can think of to do this is to set EA7 to be something specific (e.g. "NeedsUpdating") and then have a second workflow which processes users with this value so that they are the $request, but it feels to me like there should be an easier way of doing this.

  • Is there such a thing as $request.ActivityTarget?

    There's precisely the issue you are having though is that for this workflow, the "Activity Target" (as far as the AR $Request / Transaction is concerned) is the group.

    Your idea of "flagging" the object with "NeedsUpdating" using the Update Properties Activity is a good one as you can then have a Change Workflow that looks for that exact change.

    Within a script fired by that workflow, you can reference $Request.DN which will be the distinguishedname of the object being modified.

    This is in my view, the least complex / fastest way to solve your problem.

  • Morning, I'm the OP, but am having some issues with my account so am posting with this one!

    Thanks again for all your assistance  .

    I reached out to Quest Support who have provided a new script which works to set EA7 based on a single workflow.

    The workflow should be set up using the instructions here or here, then the script should be configured as

    Function FindMemberTitle($Request)
    {    
        $Members = $Request.Get("Member")
        
        foreach($MemberDN in $Members)
        {
        $eventlog.ReportEvent($Constants.EDS_EVENTLOG_ERROR_TYPE, $MemberDN)
        $Member = Get-QADUser -Identity $MemberDN -IncludeAllProperties   
        $eventlog.ReportEvent($Constants.EDS_EVENTLOG_ERROR_TYPE, $Member.title)
    
            if ($Member.Title = "IT")        
            {                    
               return "03452"
            }
        }
    }

    The only change I made to this was to include a lookup table rather than a load of If or a swtich statement, other than that it works perfectly.

  • Possible issue here:

    If ($Member.Title = "IT")       

    ...needs to be:

    If ($Member.Title -eq "IT")       

  • The forum post you referenced might be using slightly different methods depending on the environment. Ensure you’re using the correct API version or workflow configuration that matches your system.