Synchronising with Active Directory is NOT the best approach
This is a deliberately argumentative statement that, throughout this series of posts, I want to explore and explain my reasoning behind. The other aim of this series is to provide a real-world example of a new starter/leaver process that can be implemented in Service Desk Express.
For many years architects have been pushing for Active Directory synchronisation from every enterprise application vendor with, in most cases, very good reasons. AD synchonisation provides the business with a single directory source that can be used for everything from authentication/authorisation services to location and reporting structure data depending on how well it is populated. No one, not even argumentative me, would argue that a single directory source is a bad thing, nor that single sign on wouldn’t be welcomed by every enterprise user. My argument is NOT with AD. My objection to AD/Service Desk synchronisation is from a business process perspective – namely I believe that the source of HR data (which is what is being synchronised here) is better suited to the HR/Payroll system within an enterprise rather than AD. I can’t imagine that there are many organisations who add their new employees to AD before they are added to payroll and, in my opinion, the system admins should be tasked properly with creating an AD/Exchange account such that OLA/SLAs can be managed and customer satisfaction monitored. So what, in my humble opinion, is the correct solution:
Data Flow Solution
As you can see from the diagram above, my solution would be to put the Service Desk in the centre acting as the hub through which human business processes are transacted. The initial employee record is created in the HR/Payroll system which then creates a client/customer record in Service Desk Express (using the Integration Engine). This in turn kicks off the New Starter business process that includes, amongst other tasks, an action to create an AD/Exchange account for the new employee. By updating the WinUserID field in the Client record with the user’s AD domainusername, the link between AD and Service Desk Express is then made and Self-Service Single Sign On can be provided. When employee records are updated (either through a request through the Service Desk or directly with the HR/Payroll system) the employee details are updated in Service Desk Express and then in AD.
New Starter Business Process
I am not going to discuss the initial synchronisation with the HR/Payroll system as this was discussed in a previous post (Using the Integration Engine to Manage Clients) and there is an appropriate Integration Engine package that can be downloaded and tweaked for your requirements. The key point to mention is that of “datakeys:”
As you can see Service Desk Express holds the datakey for both the HR/Payroll system (EmployeeID –> CLIENT) and AD (sAMAccountName –> WINUSERID). This is crucial to the solution.
In my example business process above, the employee is going to be provided with the following:
- Workstation (either static or mobile) with a standard operating system/applications build.
- Active Directory and Exchange account for the domain.
The important point to note about my example process is that activities happen both in parallel and sequentially and I want to demonstrate how this can be accommodated within business rules in Service Desk Express.
In the next post I will walk through the creation of the New Starter Process in Service Desk Express based on the output of the Using the Integration Engine to Manage Clients post I mentioned earlier.
Do you think this process would also work with the SDE Staff?
I’ve implemented this for clients and I must say kudos to the work flow.
Yep it would absolutely work for SDE staff as there is a similar WinUserID field in the _PERSONNEL_ table.
You’re very kind donating this expert knowledge for free.
So I tried to implement this with staff in 9.8, but it says:
2009-09-09 10:54:02.8470 ERROR [engine-1043] Task [1043:STAFF IMPORT]: Step 1.0 [Inactivate Staff]: Task.RunStep(): StoreRow exception: Exception caught while storing Data. Type mismatch.
I’m not sure why there is a type mismatch on the staff module as it looks the same as client?
Do you have full trace level debugging running against this package. That error message is a little limited. If you are still having trouble can you send me an email with an your Integration Engine package extracted as xml and I’ll see if I can help?
Hi Alan, I have a question on this.
Currently we’re working on implementing a unique ID across oracle/sde/AD so they can all “talk”. Problem arouse when we can’t put contractors into oracle due to not being official employees, but they DO get AD accounts (wierd eh?). So the way they are working this is that a contractor can/will recieve a Unique ID outside of the Oracle Payroll table, but then when they DO become perm they get their employee ID as well.
Well trying to create a integration package I get an error when there is a entry with only Unique IDs and nothing in the employee ID. I believe its because it null/empty nothing there.
I was trying to think of a way to pseudo enter something in here so SDE doesn’t think its a duplicate.
if IsNull(sourceRow(“Employee ID”)) then
targetRow(“Client ID”) = sourceRow(“Unique ID”)
targetRow(“Client ID”) = sourceRow(“Employee ID”)
doesn’t seem to work at all,
Any ideas? Hope I explained this coherently!