Approval Rule getting in the way

Hi craig mcfarlane 

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 craig mcfarlane 

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 

Just as an FYI, Stu, your suggestion worked perfectly and is now running as it should. I have never really used saving properties in workflows but now I have seen it I really like it. 

As always, thank you for taking the time to reply; I have once more learnt something new today. 

 Stu.Pollock, I love grabbing saved properties , where i was using Powershell Get-QADUser to look up the value, I can now just grab them from the workflow. This really is epic. Cant thank you enough for that bit of info