I have the following scenario that I'm trying to find a solution for.
A company has recruiters in the field that currently use an xRM application to track Candidates (which is just the Contact entity renamed). They create activities for emails, calls, and appointments and there is reporting that shows where they are in the process with a Candidate.
The same company also has Home Office Recruiters that use a Siebel system today (which is going away). They want to move the Home Office Recruiters onto the existing xRM application but with their own customization (there are fields required for a candidate that only they use). I need to pull the Siebel existing data from Siebel and create the necessary activities (in the past) as part of the project.
Today, home office might initially deal with a candidate (in the old system) and then refer them to the field recruiter, who enters the candidate in the xRM system. But sometimes, that candidate is already owned by someone in the field and it being worked by them, while home office is working the same candidate in their system at the same time. You would think that bringing everyone into the new system would solve a lot of problems since that's what CRM systems are good at (making sure multiple people are contacting candidates at the same time). The problem is, they want to keep doing this.
Here is where it gets tricky. The Home Office Recruiters want their work on the Candidate to remain hidden from the field recruiters until such time as they want to "share" it. They don't want the field to see their activities or notes until they decide that they can (called a "SendOut"). Home Office Recruiters should be able to see the field's work at any time, however.
Option 1: I could add the fields that Home Office needs to the Candidate entity and use javascript to hide them. The field recruiter might already own the record because they imported it or entered in manually, so I can't really go strictly off of ownership here. Once a "sendout" is done (which might just be a flag on the Candidate entity), I could display the fields so that the field recruiter can now see the work Home Office did. But the activities created by Home Office shouldn't show up in the field reports.
Note that until the SendOut is actually done, Home Office wants reporting that only shows the # of activities that they are performing on the candidate.
One problem with this approach is that the field recruiters could see the home office fields in Advanced Find and add them to a view.
The other is, suppose a Home Office person imports a bunch of Candidates (or I load the old data from Siebel). The candidates might aleady exist and are being worked in the field already. The new candidates would be duplicates that are assigned to the Home Office person that imported them. That way, access is then controlled. When a SendOut is done, we'd have to detect the duplicates and merge the information. They don't like the idea of doing a manual merge, but I don't see any other options for this approach. We could detect duplicates during the import and try to keep only one record around, but that seems difficult since anyone (field or home office) could be importing anyone they want at any time. (The field only cares about duplicates in each region).
Option 2: I'm wondering if auto-creating a child entity on import called "Home Office Contact" is the way to go and putting the necessary fields there for Home Office, and have a 1 to 1 relationship between the Candidate and the Home Office Contact. What I'm not sure of is whether this new sub entity can be owned by Home Office while the parent entity might already exist and be owned by someone in the field. If it can, then that's great. But that means that on import we really would have to ensure duplicate detection fires across the organization. When home office creates an activity, I'm hoping it would be associated to the Home Office Contact entity and wouldn't be visible to the field?
Any thoughts would be appreciated!