Pass OperationReason control to a workflow when triggered from a PS script?

Hello, we are triggering an on-demand workflow from a Powershell script using Set-QADObject but we need to record the request reference number as the OperationReason in the workflows activity operation so if someone checks the users change history the reference number should be recorded in the "reason" box next to the operation performed by the workflow

Example of code we are using:

$workflowParams = @"
    <RunParameterValues xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:schemas-quest-com:ActiveRolesServer:WorkflowParameters">
      <RunParameterValue name="userDN" syntax="String">
        <Values>
          <Value isEncrypted="false">
            <RawValue>$userDN</RawValue>
          </Value>
        </Values>
      </RunParameterValue>
      <RunParameterValue name="mbxLimit" syntax="String">
        <Values>
          <Value isEncrypted="false">
            <RawValue>$mbxLimit </RawValue>
          </Value>
        </Values>
      </RunParameterValue>
     </RunParameterValues>
"@

Set-QADObject -Identity $WorkflowDN -ObjectAttributes @{edsvaStartWorkflow=$true;edsvaWorkflowRunParameerValues=$workflowParams} -Control @{OperationReason="RITM580647 - Test"}

The -Control doesnt do it.

Also looked at this ADSI approach but still cant find a way of passing a string to a workflow activity operation reason.

Then found this but cant see a way passing a workflow parameter to the Control Value

Any advice is appreciated for this seemingly simple task.

  • The syntax of your "set" appears to be correct.  Are the other Virtual attributes getting set?  My only suggestion would be to add the "-proxy" switch to this command line.

    Observation:  This is an odd way to start a workflow.  I'm curious why you implemented it this way.

  • An activity inside an Automation Workflow can set an operation reason, but this functionality is very limited - currently, Workflow activities can only set a hard-coded operation reason. In your case, you would want to set a different ticket number every time, so that won't work.

    In order for this to work as desired, the activity run by the Automation Workflow would have to be a custom script module. It can pull out a custom Workflow parameter value using $workflow.Parameter(name) to get the ticket number and then leverage that value on the Set-QADObject cmdlet against the object modified by the scripted activity.

  • I'm just curious now - is your ticket number being entered by a user or is it coming from some other automation?

    If the former, you could implement some customization of the Web UI to allow the user to enter the ticket number, have a Change Workflow "catch" this and then have a script activity insert the ticket # etc. into your Change history using a set command line like you have.

  • Are the other Virtual attributes getting set?

    Hi Johnny, yes, they are. The update to the user object applies successfully and I can see it in the users change history but the Reason: is <none>

    My only suggestion would be to add the "-proxy" switch to this command line.

    I have a Connect-QADService -Proxy earlier in my script so I believe the -Proxy switch is not required

    I'm curious why you implemented it this way.

    Essentially, our requirement is to trigger an on-demand workflow from a Powershell script and pass parameter values to the workflow such as username and attribute value to be updated, ideally also pass the request number as well which is to be recorded in the users change history along side the activity operation.

    I was initially using ADSI providers to trigger the workflow as per guidance in KB 4340980 but I realised you could achieve the same using Set-QADObject.

    I'm new to Active Roles so please do advise if there is a better way of doing this.

  • is your ticket number being entered by a user or is it coming from some other automation?

    It is coming from another automation which retrieves Requests from ServiceNow. Our security team does not allow direct integration between ServiceNow and Active Roles

  • Hi Terrance, Yep this is is what I am finding. I was just hoping there was a way to do this without using a custom script. I'm new to workflows so there may be something I have overlooked