Sunday, March 22, 2015

I'd Love to Use a "Direct Reports" style Service Request but...

10:01 AM Posted by A 2 comments

Perhaps you're an IT department who...well maybe needs some work when it comes to Active Directory management (titles aren't right, manager/direct report relationships are incorrect, etc) OR maybe your structure and maintenance is flawless! In either scenario - you'll recognize the importance of it when it comes to Service Manager queries (or Office 365, because SharePoint will showcase these things as well).

As I recall (and no less found around the internet) was something to the tune of "I want to build a Service Request for a new hire workflow and I need to be able to select managers." or in my case I wanted to build some Service Requests that were available only to managers and other select AD groups and within those requests only show My Direct Reports. Because if I were to use such a query, it opens up a lot of really interesting Active Directory automation possibilities such as, but not limited too...
  • Change one of my employee's titles
  • Change one of my employee's names
  • Terminate one of my employee's
  • Order hardware for one of my direct reports
  • etc.
There are certainly a lot of really basic requests you can do, but if you're like me keeping the end user in mind (in this case a manager) - you've just made a select group of requests SUPER friendly and easy to use on the Service Manager portal. So you get to building, you start building the request and then you run into your first problem.

Wait, how do I show only my direct reports?

SCSM does offer a way to do this, but I ran into the identical problem as described here ( with fortunately a solution! Consider that post absolutely mandatory to start building these types of requests. Suffice it to say, there is a way to build the query natively in SCSM, but it comes with significant performance issues. As Shaun resolves, he built a custom management pack for the specific purpose of targeting just this AD relationship. It results in a significant performance boost for the query and more importantly - never fails! Way to go Shaun!

Alright, so you start building the request/query, you publish it, you start testing with your own AD account with some dummy AD accounts that report to you to test this and it works. Great! Well, almost. Because while I wouldn't fault you for deeming completion, there is something you wouldn't have thought of...because it's a bug in SCSM.

I published a request that shows a manager's direct reports, but managers are calling in complaining that they see people that were let go/left the company. I even checked Active Directory, they don't report to them anymore! How the hell is this relationship known?!

Ugh, so close yet so far right? As I said, this turns out to be a known bug in SCSM (See here). Despite the AD relationship not existing (i.e. being NULL) the relationship is kept in SCSM. This comes down to the AD Connector while being very aware of the change, not updating this particular relationship in SCSM. But SCSM is infinitely customizable right? Of course it is! We can build ourselves a management pack out of this! Because if you haven't started customizing SCSM, you're going to want to now.

As Travis Wright points out how to import additional AD properties in 2009 while at Microsoft you can get any other property you want in his example the web page attribute of AD - But great, the website...that's neat I suppose and I thought you said we were going to build a management pack to get out of this? Correct! What you'll need to do is follow Travis' post exactly but you'll want to include an additional property and that's the "Enabled" property (a Boolean true/false value). Now you'll be able to query all direct reports who are Enabled in AD, thus truly showing all of your active Direct Reports! (If you want to go the extra mile for other potential uses, go ahead and sync some password properties like PasswordLastSet, PasswordNeverExpires, etc. If I were you, when naming this custom Management pack of it something like "UserCustomizations" or "AdditionalADProperties")

So once you've imported the Direct Report management pack and are syncing the additional properties...NOW you are ready to build your queries.

Scenario 1: I want a service request to show all of my direct reports
    1. Select the first "Manages User"
    2. Scroll down and select username
      1. Set it equal to the Token: Portal Username
        1. By setting this, you are saying whoever is logged into the portal... use their username (i.e. a manager goes to the portal, this query would obtain any employee who reports to them)
    3. Then select "User (Manager and Direct Report)
    4. Now find and add the "Enabled" property
      1. This allows you to target Direct Reports that are Enabled (i.e. You won't see disabled employees)
    5. On "Display Columns" tab select "User (Manager and Direct Report)"
      1. Pick any fields you want to display for the Direct Report such as "Display Name" (Which is their first and last name), Job Title, etc.

Scenario 2: I want to see all Managers (AD users that have direct reports)
    1. Select the second "Manages User"
    2. Scroll down and select username
      1. Set it to is not empty
    1. Select User (Manager and Direct Report)
      1. Find the "Enabled" property and set it equal to True

Scenario 3: I want to see my supervisor as a selection in a Service Request (seems weird, it would only be one selection)
    1. Select the second "Manages User"
    2. Scroll down and select username
    3. Set it equal to the Token: Portal Username
      1. In setting the Username property above, you are settings yourself or whoever is logged into the portal as the token

That's all for now, hope I've managed to help someone through this slightly bizarre setup!


  1. Hello, great post!
    I've faced with a problem: Direct report users are correctly displayed in query result on Portal but display name eq portal user name (which initiated service request)'s looks strange but if you click on name you'll see real preson name (Direct report users which is not eq Token:portal user name.
    Why is it happen?

  2. Glad to help, but I gotta tell ya - I am super fascinated to know how you did that! Seriously, I need to go try to make this happen now. Anyway, I've run into a somewhat similar scenario when I was originally doing this wherein I saw duplicate employees in the list... so honestly, not entirely surprised you've managed to find a new bizarre scenario. Regardless, I've updated my "Scenario 1" above to provide more context as to exactly what you need to pick in the "Display Columns" so as to obtain things like "Employee Name, Title, etc." If this still isn't working out for you, reply back!