Options
Work Item - Affected User relationship
Jason_Meyer
Customer Advanced IT Monkey ✭✭✭
When we have staff move from one company to another, all past work items are updated to reflect that the person is working at the new company. In our environment this is not accurate, the issue/request needs to stay with that company.
Fred Flintstone works for Slate Rock and has 200 IRs and 150 SRs.
Fred Flintstone quits and now works for Spacely Sprockets A new user profile is created (automatically from our Active Directory connection)
Fred Flintstone has 1 IR while working for Spacely Sprockets.
When I run a report on Spacely Sprockets I get all of the past issues that Fred had at Slate Rock which isn't correct.
Any thoughts/suggestions on how we can mitigate this to get accurate reports for Rocks R Us
0
Answers
Hrmm..
You're saying that these are two wholly separate accounts but the way you describe it, sounds like they are a single account. So let's assume they are in fact two different accounts. Is your query based on the User's Department attribute or something else?
They are two different AD accounts (unique GUID) that have the same name.
Yes, if I query for all tickets for the new company in our SSRS Archive environment, all tickets for that person show up.
What attribute does Service Manager use to connect to the Affected User? Appears that it is DisplayName, when it could/should be the GUID.
Thats odd. Service Manager itself uses domain name and username (SamAccountName) as the database keys for a user.
Does Fred Flintstone at Slate Rock and Fred Flintstone at Spacely Sprocket have the same DOMAIN\Username combo?
If so, I'm not actually sure how ServiceManager would handle that but i guess your experience explains a lot.
If not, then SCSM will see them as two different users and then its down to how your SSRS report is wired up. If its joining on DisplayName somewhere, you might get this.
Does Fred Flintstone at Slate Rock and Fred Flintstone at Spacely Sprocket have the same DOMAIN\Username combo?
Yes, but only one ID exists, he quick Slate Rock.
Guessing this is just the way SCSM works with the object relationships versus actually storing the affected user data along with the ticket.
Any further thoughts on this? Would it be possible for the database to use the GUID as the unique key? Even SamAccountName could be duplicated in a large organization over years.