Sunday, August 2, 2015

Service Manager - Employee Management, Part 4

12:00 PM Posted by A 1 comment
I know. I know. Super overdue on this one.
NOTE: Times have changed and so have my opinions. Please read this first -

No time to waste. Let's build that Service Request Template!
The first thing we'll have to do is create a Service Request Template of the type "Service Request, Human Resources" aka the class we created when we originally devised this management pack of ours. We're doing this because need all of our custom properties available to us and to Orchestrator. To do this, we're going back into Service Manager and heading to the Library menu.

Select the Template options and then on the right hand side hit "Create Template". You can call the template whatever you'd like but since I plan on using this for a bunch of other HR style/AD changes I'm going to adopt the naming convention of Employee - Action. So this in case, Employee - Create. The class again is going to be "Service Request, Our Custom Class Name." Just hit browse and start typing "Service Request" you'll see two options. The stock Service Request class and our new custom one. Finally as is standard within the SCSM/SCOM universe where are we going to save this template? It needs to be saved in an Unsealed Management pack. If you've already created one where you are storing Lists for this management pack go ahead and just choose that one or if you prefer, create a brand new one just for storing these types of templates in. Then hit OK.

The new Service Request form will open up along with your custom new tab. On the General tab, as is the norm for Service Manager there are a few fields that are mandatory that we need to set. Now we could set them here or in the Request Offering we provide the values so that on Create/Submission of the request those fields get set. Given this is our first pass at this, let's remove any minor issues by setting those fields now. Now, while it isn't a mandatory field I suggest setting the title of the request to "New Employee" or "Onboard Employee" - the point is, provide some context here.

Alright. I guess will. I have to ask, why? It isn't mandatory.

So, if you have some basic notifications workflows setup in Service may have one that says "When SR goes from New to In Progress - notify the Affected User their SR has been created." When that notification goes out, you may want to say in the body of the email that "Hey, thanks for submitting Create New Employee" or something. Once you have said values defined in the template, hit Apply. Yes. Apply. I want to leave the form open because...

Has Service Manager synced Runbooks from Orchestrator yet?
In the last post, we created a runbook that would do the actual creation of our new user. In order to call that runbook the following things must be true -
1. The runbook needs to be "Checked In" within Orchestrator
2. Service Manager must have run a sync with Orchestrator
3. Assuming SCSM had a successful sync, in the Library -> Runbooks tab you should see the runbook we created

If you see your runbook in the runbooks list, congrats! If you don't double check steps 1 and 2. If it is checked in the next questions are...

1. Has the SCSM/SCORCH sync been setup in the Administration -> Connectors tab?
2. When was the last time it successfully ran?
3. Did it run, but with errors?

I will tell you that if you've never set this up or it runs with errors, almost 10 times out of 10 the issue is you haven't granted your Service Manager Service Account, Administrative permissions on Orchestrator. This of course assuming your SCSM service account is the account you defined in the connector to be used. If it's another account, then that account needs admin permissions on your Orchestrator instance.

Build the Runbook Template
In the runbook list, find your Employee Create runbook. Select it and on the right hand pane click "Create Runbook Automation Activity". Service Manager will pop a brand new window similar to how you've seen other activities get created (such as Review, Manual, etc.) Go ahead and name your Activity the same name of your runbook. Yes, it can be different but to keep things simple within this entire example of mine call it the same thing. Again, you'll have to choose the management pack to save it in. I suggest the unsealed Human Resources management pack you are keeping lists and the just saved Service Request in.

Similar to the Service Request template, we have some fields to fill out. Give this Runbook Activity a title and description.

I did two other things here, defined the area and stage. Why? Well to me it just seems good practice to define as much as possible from the outset because when it comes to Service Manager SQL reporting I can count on these fields having data.

Is Ready for Automation. You checked that. It's unchecked by default. This sounds important.

AND IT IS! It is unchecked by default but you have to check this off in order for Service Manager to call Orchestrator to execute this runbook. It's a very, very, very common thing to accidently look over. That and...

Now head over to the Runbook tab

Here we see the name of the runbook as you defined by Orchestrator in the un-editable "Name" field. We also see DING!!! ActivityGUID. Remember ActivityGUID? It's the thing we created in the first step of our Runbook's "Initialize Data" Activity. You may have been scratching your head the whole time thinking "How the hell does this runbook start?!" Welp. This is how. The Service Request on create is going to feed that runbook this information.

1. Click Edit Mapping
2. Select and expand the "Object" tree
3. Select "ID"

If you think on this just a bit longer this means we could have called ActivityGUID anything we wanted. We could have called it "Magic Sauce" because these products (SCSM/SCO) don't care about the name here. We're calling it ActivityGUID for our own readability in the future. We know that the runbook receives the Activities GUID property.

For those who aren't familiar, GUIDs are unique identifiers. In fact they are Globally Unique Identifiers. Using GUIDs we can count on dealing with a unique, single object. Remember the Runbook and how we always chose "Related Object GUID" ? Making more sense? Eh? EHH?!

Alright enough reflection here. Make sure "Is Ready for Automation" is checked off and you've set the ActivityGUID property to the above. Hit OK and close this form out.

Back to that Open Service Request Template
Now go back to the Service Request template we still have open. Within the Activities tab, hit the plus button.

With the menu that pops open, we're able to add Activities into our Service Request. Having just created our new Runbook Activity, go find it/search by the name you gave the RB Activity and add it into your Service Request. Once you've found it and hit OK, it pops up the form.

If you think about this, I'm sure the architecture choice was something like...

"Build the template to whatever you want, and then make final specific choices of the instance of one of those wherever you place it."

For example, I could foresee someone creating a RB Activity having "Is Ready for Automation" unchecked by default, but when placing it in your Request checking it off. Or perhaps making the inputs to the runbook general and never defined until you place it in the request.

Anyway. Hit OK and drop this runbook in your Service Request. Then hit OK and save your Service Request template.

95% done with this whole thing. I promise.

The final step. Build the Request Offering.
With the template created, we can now build a Request Offering. This part in comparison to whole thing is the easy part. This is our presentation layer on the portal that is going to take user inputs and map them to our custom properties, execute our custom runbook, etc. This is the part that makes this whole thing look simple.

The other thing is that it's crazily self explanatory. So I'm going to go over the parts that affect our custom request and runbook.

In the User Prompts section we define...well the information we need to solicit from an end user entering information the form. Now I've defined a lot more than our basics hence the slider bar in my screenshot. But that doesn't change anything.

I've asked for the new hire's first name (required), middle name (optional), last name (required), job title/position name (required), department (required), and their manager.

I want to draw your attention to the last two. Department and Manager. As you'll recall in step 1 of this series I made Department a list and I made Manager a relationship. So for department I simply select "MP Enumeration List" and pick the list in Service Manager where I'm storing my Departments (which to bring this full circle) is why I saved Departments in a list as it means I don't have to go into and edit this request every single time I need to add a Department. I can simply go to "Lists" and add/remove. Plus it means multiple Request Offerings can leverage the same list so I only have one place to make edits. Finally, since Manager is a relationship type within the request I need to get a list of objects within the Service Manager database. But a very specific object type. I need Active Directory users that are managers.

Easy. I got an AD Group for that.

WRONG! And I'm not saying that to be harsh. I'm saying it because it's impossible within Service Manager to query an AD group because that kind of relationship isn't kept in Service Manager. So how do you do it? How do you get All Managers within your organization given this caveat in Service Manager?

How about all Active Directory Users whose Manager property is not null? So how do you do it? Fortunately, a previous blogpost of mine explains this! You can check it out here.

Let's wrap this up, NOW!
Finally. Map the User Inputs to your custom properties.

Right after you save and publish it :)

As no doubt you can see, there are a lot of steps to this entire process but holy crap are they worth it. Because guess which department isn't manually creating Active Directory accounts again?

Well. Yea...wait. I have more stuff I want to add! I need more properties!

Then go for it. You have the management pack, just add a new property, seal it, import it, you're good to go.

Ok! But, I need approvals! I want someone to ok a new hire!

No sweat. Go back to your Service Request template add a Default Review Activity and place it before the runbook activity. Then give it a name, add some reviewers, etc.

Holy crap that makes perfect sense.

I'm glad it does :)

Wait a second. I could use this exact same management pack for updating employee information, terminating employees, extending end dates on accounts. Right?

Yes you can because you built the management pack to do it! Just build a new Service Request template and Request Offering for those things and you're good to go.