Jan 28 2017

Print this Post

Service Manager Complex Approvals Tutorial: Part 1 – Introduction

I have been playing around with Microsoft System Center Service Manager and Orchestrator lately. The two applications are always better together and you cannot really master one without the other. In this multi-part blog, I will share some of the stuff I learned during the past couple of months.

In the form of a multi-part blog post, we will go through handling a complex review activity voting quota and working around rejected review activities when the business workflow has a different opinion than just cancelling the request. We are going to use Runbooks and PowerShell to connect to Service Manager and achieve desired results.

The example we use is a user requesting external email access. The request is checked for technical and business validity, approved (or rejected) by a security committee, then the VP and, if rejected by the committee, the CEO. Finally, a Runbook grants the user access to his email using OWA or ActiveSync, which are disabled by default in this scenario.

I tried to design the RunBooks to be as modular as possible; I am following guidelines from the free eBook System Center: Designing Orchestrator Runbooks as much as possible.

The parts are as follows,

  1. Introduction (This post!)
  2. Service Manager: Creating the Service Request.
  3. Orchestrator: Check and update Service Request. Coming Soon!
  4. Orchestrator: Monitor Review Activity and Custom Approval. Coming Soon!
  5. Orchestrator: Enable External Email Access. Coming Soon!

In this post, I will show the flowcharts I used before diving into building the service request itself.

Business Workflow

Always keep in mind how the business sees the solution you create, I created a workflow to share with the business stakeholders so we all have a clear understanding of how the service request works. I eliminated all technical jargon from this workflow; however, it is the cornerstone of all the technical work afterwards.

Here, the business had two scenarios that the service request may face,

  • The Security Committee approves. Then we only need the VP’s approval.
  • The Security Committee rejects. Then in addition to the VP’s approval, we also need the CEO to make the final decision.

The committee has eight members from five departments. The approval quota is three departments.

Technical Workflow

This workflow translates the business requirements into a technical workflow that shows the specific steps and applications that handles the request.

You can see that there are checks here, that can automatically reject the request for non-technical reasons – duplicate request, or user already has access – or fail the request for technical reasons – mailbox not found or VP cannot be identified. The difference is that a failed request may require attention by the System Administrators; hence, we create an incident to log the issue.

You may notice the little icons attached to each step, this shows which application is taking each action.

Checks workflow

Here are the checks we perform to validate the request technically and non-technically before requesting the approvals.

The first two checks are technical. The other two are non-technical. Hence the different action for each check. If all checks pass, we return also the username of the VP (more details about this in the following parts). If it rejected or failed, we return the error message to provide to Service Manager.

Update Service Request Workflow

This will be a Runbook that updates the title and description of the service request with information like username, department, title, etc… Additionally, it will update the VP review activity with the VP’s username retrieved during the Checks step.

That is it for this post. In the next part, we will create the service request using Service Manager.


About the author

Walid AlMoselhy

Permanent link to this article: http://almoselhy.azurewebsites.net/2017/01/service-manager-complex-approvals-tutorial-part-1-introduction/

Leave a Reply

Your email address will not be published. Required fields are marked *