Greetings, I'm a little green on FIM and looking for some advice.

We have an HR system where we store the information on Contractors, Interns, and Employees.

The business process for converting Contractors and Interns to Employees is to terminate the Contractor and re-hire as an Employee. This gives us a different employee number for the "live" entry in the HR system.

Also, there is a "Supervisor No" attribute that is a Reference attribute for their manager. This is their employee number.

What do I do in FIM? If the Employee number is the anchor, won't the system consider the employee a new object? Is there a way to connect the new employee record to the metaverse object that was a contractor or intern, and update the anchor attribute (the new employee number)?

I was thinking of using a different custom field in the HR system as the FIM_Sync. But just realized that if this became the anchor, then no managers would connect since the Supervisor No is an Employee number.

Thanks in advance for helping.

-Doug

*** Update ***

I read some of the articles on Correlation ID that are in the 2003 version of MIIS the TechNet library. So a follow up question would be what happens between the CS and MV when the HR object changes.. Assuming I have this FIM_Sync attribute to be my Correlation ID.

• Contractor is created. Employee ID is anchor and FIM_Sync field is populated.
• New object in CS
• Projected into MV
• Provisioned out to AD and other systems, but they don't have the FIM_Sync attribute in their schema.

• Business Event.. Contactor converted to Employee:
• Contractor in HR system terminated (employment_state) and FIM_Sync entry removed.
• Employee record created in HR system and FIM_Sync value populated with what it was in the contractor record
• New Employee object in CS
• Does Contractor get disconnected?
• Does the Employee CS object get joined to existing MV object?

• Edited by D Gilmour Thursday, January 16, 2014 3:51 PM Update

At one of my previous projects we solved the same scenario as following:

1. That was not a fully automatic process.

2. Once we receive event that Contractor is terminated in HR, we put that user in "Terminated Contractors" set, disabling his active accounts, where the object resides for 30 days (business policy) before his accounts are removed from target systems.

3. There's a custom workflow which triggers a notification to administrators if the following criteria are met:

• Name/Surname of fresh Employee are equal to one of the members of "Terminated Contractors" set
• Employee record from HR came within a week after Contractor's termination date (also, a business policy, agreed at customer's level. HRs are lazy and not necessarily process that transfer same day).

4. IAM Administrator contacts HR to ensure that persons in question are actually the same one. Upon confirmation, manual join is made. Once object is joined, Correlation ID is written back to HR (actually, a buffer database acting as HR source) to ensure that the join can be made automatically.

We faced several problems, though, which are beyond the scope of FIM itself:

1. HRs were creating Employee record before terminating Contractor's one. A major pain, since new accounts are created, et cetera.

2. HRs were creating Employee records too late (that's why we set a "timeout" for a week, initially it was two days)

3. We had a case once when Contractor was terminated and new Employee came with the same name, but those were different people and HR application doesnt allow to differentiate "contractor fired" and "contractor moves to employee" events. That's why we had to stick to a manual and documented procedure.

• Proposed as answer by Vladimir Zanadvorov Friday, January 17, 2014 8:01 AM

At one of my previous projects we solved the same scenario as following:

1. That was not a fully automatic process.

2. Once we receive event that Contractor is terminated in HR, we put that user in "Terminated Contractors" set, disabling his active accounts, where the object resides for 30 days (business policy) before his accounts are removed from target systems.

3. There's a custom workflow which triggers a notification to administrators if the following criteria are met:

• Name/Surname of fresh Employee are equal to one of the members of "Terminated Contractors" set
• Employee record from HR came within a week after Contractor's termination date (also, a business policy, agreed at customer's level. HRs are lazy and not necessarily process that transfer same day).

4. IAM Administrator contacts HR to ensure that persons in question are actually the same one. Upon confirmation, manual join is made. Once object is joined, Correlation ID is written back to HR (actually, a buffer database acting as HR source) to ensure that the join can be made automatically.

We faced several problems, though, which are beyond the scope of FIM itself:

1. HRs were creating Employee record before terminating Contractor's one. A major pain, since new accounts are created, et cetera.

2. HRs were creating Employee records too late (that's why we set a "timeout" for a week, initially it was two days)

3. We had a case once when Contractor was terminated and new Employee came with the same name, but those were different people and HR application doesnt allow to differentiate "contractor fired" and "contractor moves to employee" events. That's why we had to stick to a manual and documented procedure.

• Proposed as answer by Vladimir Zanadvorov Friday, January 17, 2014 8:01 AM
• Unproposed as answer by D Gilmour 21 hours 29 minutes ago

At one of my previous projects we solved the same scenario as following:

1. That was not a fully automatic process.

2. Once we receive event that Contractor is terminated in HR, we put that user in "Terminated Contractors" set, disabling his active accounts, where the object resides for 30 days (business policy) before his accounts are removed from target systems.

3. There's a custom workflow which triggers a notification to administrators if the following criteria are met:

• Name/Surname of fresh Employee are equal to one of the members of "Terminated Contractors" set
• Employee record from HR came within a week after Contractor's termination date (also, a business policy, agreed at customer's level. HRs are lazy and not necessarily process that transfer same day).

4. IAM Administrator contacts HR to ensure that persons in question are actually the same one. Upon confirmation, manual join is made. Once object is joined, Correlation ID is written back to HR (actually, a buffer database acting as HR source) to ensure that the join can be made automatically.

We faced several problems, though, which are beyond the scope of FIM itself:

1. HRs were creating Employee record before terminating Contractor's one. A major pain, since new accounts are created, et cetera.

2. HRs were creating Employee records too late (that's why we set a "timeout" for a week, initially it was two days)

3. We had a case once when Contractor was terminated and new Employee came with the same name, but those were different people and HR application doesnt allow to differentiate "contractor fired" and "contractor moves to employee" events. That's why we had to stick to a manual and documented procedure.

• Proposed as answer by Vladimir Zanadvorov Friday, January 17, 2014 8:01 AM
• Unproposed as answer by D Gilmour Friday, January 24, 2014 2:16 PM

Thanks for the reply. That seems a bit much. I was hoping this tool would cut down on the complex processing not add to it..

Anyone else have any other thoughts?

Hi-

Unfortunately you're going to end up with two Metaverse objects without some sort of linkage in the HR system feed between the two records. A lot of HR systems I've worked with have a unique key that is often hidden in lieu of a friendly employee ID type number. You might ask your DBAs to diagram out the schema here relating the actual person to their contractor and employee positions inside the database. Usually these systems aim to have one record per physical "person" and then various records for their different positions - employee, contractor, etc.

The HR system is an ASP. Somehow, they've hooked up their reporting (Cognos I think) to a web service that a contractor wrote the MA to...

The contractor conversion to employee is two separate entries.. something about start time and tenure calculations.

If I disconnect from the metaverse object, move the correlation Id to the new employee that will be imported into the CS, will it join on the correlation Id? and then update changed attributes? 

The HR system is an ASP. Somehow, they've hooked up their reporting (Cognos I think) to a web service that a contractor wrote the MA to...

The contractor conversion to employee is two separate entries.. something about start time and tenure calculations.

If I disconnect from the metaverse object, move the correlation Id to the new employee that will be imported into the CS, will it join on the correlation Id? and then update changed attributes? 

As long as that correlation ID is still in the Metaverse, yes. You might need to do something like export it to the FIM Service MA and import it back in to persist it. Fundamentally data can't exist in the Metaverse without a connector backing the attribute. (You could turn on do not recall attributes but that's a bad idea.)

Is there a possibility from a process perspective to have the data entry folks put the contractor's ID number in an alternate identifier field in the database that you import?