In Service Manager we can configure an approval step with “Line manager should review”. That means that the manager for the user who created the for example service request needs to approve. The manager is configured on user account in Active Directory.  This works dynamic and fine as long as it is actually the manager that needs to approve. But what if we request a service and the approver depends on who is requesting the service and what kind of settings of the service? Then we can’t use the “line manager should review” feature and we don’t want to create one template for each possible scenario.

In this blog post I will show how you can build dynamic approval steps in Service Manager together with Orchestrator. I will use Orchestrator and Service Manager 2012, but it works almost the same in Service Manager 2010 with the Service Manager Integration pack for Orchestrator or Opalis. The really cool thing is that we use a runbook to update an approval step within the same service request.

In my scenario engineers can request temporary permissions from the Service Manager self-service portal. Instead of engineers have accounts with all permissions that they can possible need, they need to request permissions when they need it, and the permissions are removed after X hours. If we lose an account it doesn’t have any permission after X hours and no engineer will have an account with too much permission.

High level steps

1. Engineers request permissions for a system from the self-service portal. The engineer fills in a form with all needed information based on a service request template. The engineer can select system from a drop down menu.

2. The service request template includes tree steps

2a. Update manual approval step (Runbook)

2b. Manual approval step (Default approval step in Service manager). This approval step is blank, no configuration by default. Instead it is the first runbook activity that updates this approval step with reviewers.

2c. Grant engineer permissions (Runbook)

3. The first runbook activity in the template run and update the approval step with suitable approval group based on which system the engineer request permission. For example if the engineer have request permissions to Exchange the manual update step will be configure with the Exchange Expert Team group.

4. An expert team approves the request. This step is blank in the template; the previous runbook activity will add a security group as reviewers depending on the permissions that were requested.

5. The second runbook activity run and adds the engineer to a suitable security group in Active Directory depending on what kind of permissions that was requested. The runbook also writes a log to a log database and updates the service quest with the result.

6. The engineer can track the service request during the process and also see the result of the service request in the self-service portal

 

Let’s look at the runbooks

 

This first runbook starts with the runbook activity ID; it then gets the related service request. After that it maps the service the engineer input to a security group in Active Directory. After that it finds related Review activity and creates a related reviewer object. It then gets the group of reviewers from the CMDB and creates a relationship between the new reviewer object and the group from the CMDB. The second runbook is the runbook that will grant the engineer permissions. It starts after the manual approval step that the first runbook configured.

The second runbooks goes from runbook activity ID to service request, and then it gets the requesting user from the input in the Service Request. The runbook creates a time stamp plus the number of hours that the engineer requested permissions for. Then it maps the service in the service request to a security group in Active Directory and adds the user to the group, it then writes the settings to a log database. The last activity triggers next runbook. This runbook updates the service request with the result.

Looking at the process from the self-service portal it will look like

The runbook that grants permissions to the engineer writes all settings to a database. This database will be used to figure out when it is time to remove engineers from security groups again.  The database in my example is very simple, see picture. You can schedule a runbook like the one below to Query the database every X minute to see if there is any expire date passed, and if there are the user will be removed from the security group. You can also use this database as source for a report showing current temporary permissions. You can use SQL Report Builder to build a report like that, download Report Builder here.

None of my example runbooks have any activities for error handling; please see this blogpost for more info around fault tolerance in runbooks. I have not uploaded an export file of these runbooks, as it is a lot of values to re-configure in every environment. Instead I have uploaded a ZIP file,  20120319, with screenshots of all settings in all activities.

 Please note that this is provided “as is” with no warranties at all.

  1. Sorry have not seen that… Have you updated sequence ID correct? It should not move on to the next activity if the previous one is not completed yet.

  2. Jose Fehse says:

    Hi Anders, I have implemented something similar to this and SCSM is adding an Extra blank approver besides the one I tested. Not only that, but it is also letting the activity after the review activity to continue on, even though the review activity is still In Progress. Have you seen something like this? I’d think the empty approver is set when the activity goes to In Progress state and has no approver set, but I’m setting the approver before in the Runbook (and I can see it there as well). SCSM is 2012 SP1 UR2, as is SCORCH. Any ideas?

    Thank you,

    Jose

  3. […] Request to add user2group with dynamic group manager approval | Austrias System Center Blog on Dynamic approval steps in Service Manager with a bit of Orchestrator magicTalmud on VM lifecycle in Service Manager with Orchestrator magicAutomate adding AD users to AD […]

  4. Erin Day says:

    yes that would work i think. so kind of do it the opposite way. leave the group in but use a runbook to associate the return emails with the group. I guess the hardest part there would be where to trigger the runbook?

  5. Hi,
    Thanks for reading my blog. So if you could assign all members of a AD group as reviewer in a review activity in SCSM it would work for you? When someone replies to a change request approval step what kind of info is there in the e-mail? If there is also the change request ID I guess we could get the sender from the e-mail and the change request ID, then find that pair with Orchestrator and approve it by a runbook.

  6. Erin Day says:

    Hi, Thanks for this post, it’s great. I’m trying to modify it a little to use in conjunction with the “Tricky way to handle email approvals with the exchange connector” found here http://blogs.technet.com/b/servicemanager/archive/2011/02/08/tricky-way-to-handle-review-activity-approvals-with-the-exchange-connector.aspx

    Here’s our problem, specifically this is with approval activities with Change requests. We have a change request process where key business leaders must approve critical IT Application changes. These people don’t have access to SCSM2012 (nor would they use it if we gave it to them) I’ve found the approve/reject emails works great for these guys. Problem is it only works when they are specifically added to the Review activity. The email gets sent to them and they can approve or reject and the reply is applied correctly to the Review activity. In a dynamic world though, would be better if the review activity was an AD group, but alas the approve/reject email doesn’t as the connector doesn’t map the user back to the AD group in the review Activity.

    I’ve used your example along with the AD integration pack and the SCSM 2012 Integration pack as a basis to get the users from the member AD group and then pass it to your Create Related object piece. The settings i have for the Create Related object are:
    Connection: ourServerConnection
    Source Class: Review Activity
    Target Class: Reviewer
    RelationShip Type: Reviewers
    Source Object Guid: SC Object from “Get Review Activity”

    Under the fields section i have Display name= “Display name from AD Get User Object” (the AD command that gets the users).

    The Result?
    There are 5 members of the AD group and the job adds 5 Reviewers to the Review Activity. Problem is the Reviewer field is blank, but if you hover your mouse over the reviewer field it shows the correct name. Crazy or what? so it’s putting something over but i obviously haven’t got the fields right. and without this, the reviewer isn’t assigned correctly, and the email isn’t sent to the reviewer.
    Got any thoughts? i

  7. Pedro says:

    Hi Anders,

    I have created the runbook but it run into an error during “get runbook automation activity” phase, the error is “input string was not in a correct format”, can you help?

  8. Hi, I think as long as the runbook reports success in the runbook designer or the Orchestrator console it will also report success back to Service Manager. I will test it in my lab, see if I can change a service request to Cancelled from a runbook.

  9. Johan de Haan says:

    Hi Anders,

    In above blog post you say: “This runbook updates the service request with the result.” What is the best way to configure this?

    Default, a Service Request is failed when the last Runbook Auomation Activity result is failed. But I want to setthe Service Request with a Status completed and Implementation Results “Cancelled”, so when the runbook fails so the Service Request isn’t automatically failed. But when I use the Update Object of Class “Service Request” and I set e.g. the field Implementation Results = “Cancelled” I get the result in ErrorSummary.Text: “Cannot resolve display name [Cancelled] to name.”.

    Do you recognize and understand it? Can you help me with this?