SCSM Out of Office - Prevent Work Item Assignment

Adam_Dzyacky

This is a request that's come up here, here from @Tom_Hyde and here from @Carol_Lee.

Clearly this demands some kind of solution and that's why it's the latest repository available on my GitHub with all the source ready to be viewed and modified at your discretion should you so chose. In it, a few things to help get you started:

1. Management pack to extend your System.Domain.User class with Out of Office concepts ([true/false]OutOfOffice, [date]OutOfOfficeStartDate, [date]OutOfOfficeEndDate)
2. Management pack to introduce workflows that will prevent Work Item assignment when the Assigned To's OutOfOffice property is true
3. Optional PowerShell influenced from the SMLets Exchange Connector so you can set the OutOfOffice property across all users from Exchange into Service Manager. Wire for Orchestrator or SMA and then this OutOfOffice property can be set by simply setting your out of office via Outlook!

Currently, this will prevent Work Item assignment on the following Work Item types:

• Incidents
• Service Requests
• Change Requests
• Problems
• Release Records
• Manual Activities

Justin_Workman

@Adam_Dzyacky
You're the hero!  You deserve the gauntlet!

Joe_Burrows

Justin_Workman said:

@Adam_Dzyacky
You're the hero!  You deserve the gauntlet!

Hes a Physicist!

Adam_Dzyacky

Many thanks for the badge @Joe_Burrows

Jari_Juntunen

Noob here. Does this work with scsm 2019? I'm having some problems getting this working.

I have the extended user classes with the MPs provided and when I change out of office to true in user form it shows ok. But in the users view all the out of office fields are empty. Also I can still assign a work item to user who is out of office. The user I tested with is a global operator in service manager, does that matter?

Adam_Dzyacky

Hey there @Jari_Juntunen - haven't tested it out with SCSM 2019. But since the .NET dependency didn't change (as it did from 2012 to 2016) I don't know why this wouldn't work.

Well... that's not entirely true, the amazingly awesome @Gerhard_Goossens recently made a pull request to the repo that rectifies some issues with some of my original variables used in this. I tried to complete the pull the other day but for whatever reason it won't complete the merge. So while I attempt to sort that out, if you download the forked repo directly from him you should be able to reseal the workflow MP with the included key and upgrade.

Carol_Lee

Hi @Adam_Dzyacky , somehow I just came across this thread today. Thank you so you much!! I will try the solution out in our environment. We are still on SCSM 2016.

Adam_Dzyacky

Version 1.1 is now out on GitHub

This release contains bug fixes as identified by @Gerhard_Goossens. Thank you for your contribution!

While there are no new features with this release, nothing stops those from being added with more PowerShell for this script based workflow which you can freely edit with the SCSM Authoring Tool.

Jari_Juntunen

For whatever reason this is not working on my system (scsm2019). Maybe the smlets don't work but can't really pinpoint this since I don't get errors.

Would it be possible to use type projection to get analyst OOO status to show on incident form and how would I do this? I have made some tests and I can make class extension (quite easy actually), but I'm struggling to understand type projections.

Adam_Dzyacky

Would it be possible to use type projection to get analyst OOO status to show on incident form

I don't see why this wouldn't be possible. But it's worth pointing out that if you've extended the user class per the MPs included in the solution, you can open the Assigned User, go to that user's Extensions tab, and you would see the OutOfOffice true/false property which should be null by default if all you're looking to do is see the value. But I suspect you're looking at exposing this property in the portal's Incident form, so I'd check out one of the original Cireson Knowledge Articles details this. Haven't tested myself, but since its a Class Extension and the user is already being pulled by virtue of the Incident, I think you may be able to just place it on the form without a Type Projection.

I'm struggling to understand type projections

You wouldn't be the first to say that. Type Projections are nothing short of beyond useful for all sorts of things in SCSM, conceptually I think are easy to understand, but difficult to implement from scratch. The explanation almost always given on this front is something to the effect of "Think of it as a pre-built SQL query in that all of the JOINS have been done for you." For example, if you were to create a View in the Console you could use any class or a combination class (type projection). Those TPs generally are something like Incident and Affected User. Two classes, presented as a single concept. As you might expect, if you can use two classes you could also use any number of them. Just like SQL, the more JOINS you perform the more expensive that query/search can become. Alright, enough explanation. If you want a quick, easy way to build Type Projections @Justin_Workman's latest community contribution is the SCSM Projection Builder. A 100% PowerShell GUI based solution that uses SMLets to assemble a management pack containing a custom type projection. This thing is great for all sorts of reasons, the least of which being you can quickly assemble a TP and then see how it's formed in XML.

As far as testing goes, a quick visual sanity check you can perform is

1. Obviously making sure the user in question has the property set to true
2. Administration -> Workflows -> Status -> look up the ooo workflows. Is the WF at least triggering for the Work Item class in question? Then, is it successful or failed?

Jari_Juntunen

@Adam_Dzyacky Thank you! I will try these.

mhendawy

Hello Adam,

Thanks to explain the way of the prevention as I followed your guide to apply , the OOF solution. and I already did and when I monitored the WF status and it triggered the work item, but I faced that there is no prevention. and all work items are assigned to the the user that the OOF extension is true.

Adam_Dzyacky

So it's worth highlighting that there isn't "prevention" per se. It's more so the assignment isn't permanent. So while you can assign to someone that's out of office, the workflow engine should kick in and then undo it moments later.