Approval Rule getting in the way

Hi Team. 

I have an issue with a workflow. The workflow Run AS accounts for the user who started the workflow. The workflow starts when a BOOLEAN VA is selected. 

As you can see in the screenshot, there is an approval rule. If approved, it add adds the workflow target to a security group. Then, it sets an attribute on the workflow target and the values of the account's email address that initiated the change. Finally, it runs a Powershell script. 

If I disable the Approval rule, everything runs as expected. When I enable the approval rule, the step where it sets an attribute value to the email address of the person who initiated the start of the workflow is blank. I assume the Approval rule is getting in the way or taking over the following steps as the service account.?

Any suggestions? 

Top Replies

Parents
  • Hi  

    Let me re-cap,

    You have a change approval workflow, where if anybody changes the value of a VA (either 0 to 1 or 1 to 0), the initiation conditions are met.

    The normal flow the workflow should be:

    Pre-Operation

    • Approval Task activity step: Get approval from the Service Desk

    Operation

    Post-Operation

    • Add to Group activity step: Add the workflow target users into some group
    • Update object activity step: Initiates a new request to update some attributes of the workflow target user (not sure what the email address bit was doing)
    • Execute Script activity step: Execute a PowerShell script, to do stuff in the workflow target users in OneDrive (permissions and possibly something else)

    However, with the approval step disabled, the workflow operates as expect, but with it enable it doesn't.

    Are you able to share the output of the change history for a user when it doesn't work? Specifically, the details in the Workflow activities and policy actions, and also any events related to any warnings or errors in the Active Roles Admin Service event log? Also can you confirm the version of Active Roles your using?

  • Hi Stu. Thanks for the reply. On the update object step. The activity target is the workflow target, and on the user account, I have a VA. I update this VA with the email address of the initiator. I then read this value in the Powershell script. 

    I noticed in your screenshot that you have a Change Auditor. We also use Change Auditor I seem to recall something else I was doing where CA got in the way. 

    Here is a screenshot of the change history on the account that does not work. The item in red is not running because there is no email address set in the VA on the update task. 

    The update activity from the event log 

    Workflow activity for changing properties of an object ("Update" activity) completed.
    Activity name: Change object properties
    Workflow name: Service-Desk_Office_365_OneDrive_Access_Approval
    Workflow GUID: 2b1d48ea-582a-ef11-a6ba-005056be56c4
    Workflow instance GUID: a68d7b38-5ae9-4606-ba35-fd95a8f97785
    Operation ID: 18-343660
    Operation GUID: abbafcc0-0204-436d-ad3f-1cca94bca7f2
    Object name: Test-xxxxx
    Object parent container: something
    Object type: user
    Initiator: Administration Service (internal connection)
    Activity run as: Administration Service (internal connection)
    Activity operation ID: 18-343671
    Activity operation GUID: 32327a96-3b70-4157-bc7d-466e9d777510

  • Hi  

    I was able to re-create the issue with something similar in my lab, I'd suggest you raise an SR.

    One options might be to add a "Save Object Properties" activity step (that I named "Initiator") as below

    Then within your update activity step, get the value from the "Saved Object Properties" 

    A seconds option would start as the same as option one, by adding the "Save object properties" activity step, but if you don't need the email address set against the user account for any other reason than from your script, you could just query the Saved object properties from your script

    IE:

    $InitiatorEmailAddress = $workflow.SavedObjectProperties("Initiator").get("mail") 

  • Thanks Stu. I was looking at doing just this as it happens. Your method actually looks easier than what I was coming up with. 

    Change Auditor script 100% gets in the way of some tasks. I do have a feature request open with Quest for something similar 

Reply Children