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.

Parents
  • 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.

Reply
  • 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.

Children
  • 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.