Members of a Group for a Review Activity

Suppose you select a group for a review activity to approve a request. The current behaviour seems to indicate that the group object will get a vote towards the approval – not the members of the group which makes it hard to track the percentage approved. We don’t want the user to have to worry about who is a member of a group and creating a static group isn’t very flexible – plus the group required to approve a service request may change depending on the type of request. In this example I look at a user being able to change their job title – but not without approval from a HR group they select.

The Runbook for this is a little more complex – the actual changing of the title can be done later and is easy – but let’s look at how to dynamically generate the review activity and add the members of the selected group. In the request offering a user will be able to see their current job title, type in a new title, and select a HR group to route the approval to.

Since Service Manager will launch the Runbook I provide a Runbook GUID as an input parameter. I set up a component Runbook (Get Service Request) which will return the service request GUID as I use this later on. This is a simple Runbook which takes in the Runbook GUID – looks up the relationship to the service request and returns the GUID of the service request.

Back to the main Runbook – when I create my request offering I’m going to perform a query to list the groups which can approve the request. When you perform a query – the selected object is attached to the service request. I use a Get Relationship activity to discover this group.

I want the display name from the group to use later on so a Get Object activity returns the group object for me. As everything in Service Manager is represented by an object – I use the Create Related Object activity from the Service Manager integration pack to create a blank review activity. Properties relating to a review activity (but not the reviewers can be filled out in here). One of the important properties is the sequence ID – this tells Service Manager where in the workflow to place the activity. It is 0 based so I select 1 for this activity. The other field of interest is the ID field – when the activity is created it shows a value of {0}. This indicates to use the next available ID for the reveiw activity. I have prefaced this activity with RB – this allows it to keep my naming convention.

Now for some PowerShell – as there is no built in activity in Orchestrator to enumerate the members of a group – I have a small script which does this for me. I call the script inside it’s own executable so that it can import the Active Directory module correctly – the output is returned as an array.

The next part of the Runbook takes advantage of how Orchestrator handles multiple objects – each name returned from the script causes the next activity to be executed multiple times depending on the number of objects. We use the Junction activity to flatten the execution stream after the multiple paths are complete. The activities inside the junction are fairly simple – I create a related Reviewer object, get the user to add – then create a relationship to add the user to the reviewer object.

On the Service Manager side I have created a new Runbook activity and added that to a service request. When I create the request offering I need to specify some extra details in the prompts. The first prompt simply displays the user’s current job title – this is based on the Portal user name set as a token. The final prompt allows the user to select one of the HR groups to do the approval. The class selected is Domain Group – I have set a filter on this to only display groups with HR in the name. The last tab is where we add the selected group object to the service request. Failure to check this will result in no object being discovered when the Runbook runs.

When added to a service offering and selected in the portal the request looks as below.

I can worry about actually changing the title later on – it will just involve adding another Runbook activity to run after the approval is complete.