7

I am migrating to Salesforce.com from an on premise CRM system. I have a large amount of historical data relating to users who have now left my company. I need to bring this data into Salesforce and retain the information about who originally owned these records. I have a regulatory obligation to record and maintain this information.

I would like the owner of the record to point to an inactive user record representing each historic user. In that way I will have a consistent way of reporting on who did what when.

However I cannot load data into Salesforce and assign it to inactive users. It appears that I must activate the user, load the data and then inactivate the user without reassigning their records. This poses a problem because I don't have enough licences to cover all current and historic users.

I could break the data load down into batches based on owner to fit within my licence limit but this would be rather time consuming.

I have considered adding custom fields to the relevant objects to store the historic user information but I dislike that solution because it is not as tidy as using the Owner field. I and my users would have to look in two places to determine who was the owner of a piece of data.

I have considered using Chatter Free licences for the inactive users but such users cannot own these records.

I could use Chatter Plus or Force.com One App licences but I would have to request these from Salesforce which might incur an extra cost. So I am reluctant to do so.

Are there any other possible solutions that I could consider?

5 Answers 5

4

It's now possible to migrate data with inactive users (as of Winter '16) here are the release notes about it:

Migrating data to Salesforce and mass updating records just got easier. Now you can set audit fields when you create records through the API and update records with inactive owners without contacting Salesforce.

5

I would suggest your first solution.

  1. Import users that are no longer with your company
  2. Import Data related to users in step 1
  3. Deactivate users from the step 1
  4. Import all other users
  5. Import Data related to users in step 4

Tip! You can call SFDC support to temporarily deactivate the created date thereby retaining your historical created records.

4

Salesforce can grant what they call "courtesy licenses" for a brief period of time for migration projects if you ask them nicely for just this case. I know this from direct experience.

I would imagine they'd be especially supportive if you're a new customer moving off something else.

2

Will Salesforce temporarily (for a week or so) increase your User limit just for importing data? They do other things when it comes to data import, like allowing you to set Created Dates so you can accurately import historical information so they may allow this.

Otherwise I would recommend doing this in batches and avoiding custom objects; I think custom User objects would cause many more headaches down the road than it is worth, especially when it comes to reporting. It might be more tedious, but it would be worth it.

1

One approach would be to create users, load data, and inactivate, in batches - but that would take longer as you've pointed out.

If you must have a homegrown solution :

The other quick (and possibly) dirty solution would be to create your own User (or more aptly named Legacy User) Object, and load in all your inactive users. (Load in the UserId from the legacy system as an External Id column, so that it can be matched on)

You will need to create a lookup on all the Objects that you're migrating data into, to this Custom Legacy User Object.

Use External Id to map the Records being loaded to Legacy Owner Records. As for the Record Owner, this could just be a Data Admin or similar user with a Role, depending on whether or not you would like for users to be able to see those records.

The other extreme end of the spectrum of course is just to add a text field on all object, which has the name of the Legacy Owner. The advantage that a Custom Legacy Owner Object provides is the ability to capture details such as Job Role, Leaving Date, and other information that might be relevant.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .