Author: David Masri Founder & CEO

In this article I outline everything you need to (at least) be aware of about setting up users prior to coding your data migration or integration with Salesforce.

Let's get started!

The Salesforce User Object supports user External Ids, you should use it.

Even though you can create an External Id on the User Object, you can't always use it when Upserting ( polymorphic fields are not supported - for example: Activity WhoIDs & custom object owners). But you should still set them for all users that exists in the source system, for two reasons:

• It enforces the 1 to 1 relationship between the Salesforce user and the source systems' user records.
• It enables the Salesforce User object to be used as a cross reference table in your migration or integration code. Though you may need to first download that data when using it in your transformation code\layer.

You can set Audit Field values. (But then you can't really use upsert)

When gathering requirements always ask your client if they want to set the Audit Fields (such as CreatedDate and Createdby) as part of the Data migration. (To do this you will need to first enable the feature). The way you code your migration completely changes if you have to set these fields because you effectively can't use Upsert.

You can't Upsert data into objects and set the audit fields at the same time, because all the updates will fail. (This is true even if you are overwriting the audit data with the same values.) So, you have to code your inserts and updates as independent loads.

You may think, this is a data migration, why do I care about Updates? - Because if you find an error with the data that you loaded, and you want to be able to fix it without writing new code (especially during QA & UAT) - Your only option is to code your migration code to do a delete and then insert. This allows you to repair the data using the same code that will be used for the production migration.

Because of this some people prefer to load the audit data into custom fields, which isn't a bad option if you just need the information for historical reference.

If they have activities, Create Inactive users in Salesforce.

In addition to setting the Audit fields as part of the data migration you can also set owner fields to an Inactive User (by enabling the same feature). This is a great idea for historical activities (Tasks & Events) and as the owner field for these objects map to the "Assigned to" field. To do this you will need to create all the legacy users as inactive users in Salesforce. Inactive users don't require licenses.

Never set the Owner field to an Inactive User (Except for Activities)

Though you can technically, never set the owner field to an inactive user (except for activity type records that are essentially historical data) - this akin to migrating bad data. You should ask for proper rules on how to reassign these records as part of the migration.

All user licenses should be purchased and be set up prior to performing your data migration.

Companies sometimes try to save money by pushing off purchasing licenses till the last minute. Let them know you need the licenses in place to migrate record ownership.

Complete your security set up before running your migration.

If you don't, you can inadvertently give a user access to data they should not see! Even if you are still in the QA\UAT phases - users should not be allowed to see sensitive data.

As part of QA, use the "login as User" to test your security setup

Salesforce has an awesome "Login as User" feature, use that to test your security settings post migration before allowing (user) testers in the systems.

You should have a designated integration\migration service user.

It's imperative to know what records are modified by your integration\migration. (Remember sometimes you are migrating to an already in production system) So, you should have a designated integration service user. Only give it the permissions it needs to do its job. For data migrations you can deactivate the migration user after going live to reclaim the license.

Consider Setting the integration service user account password to never expire.

Would you believe 50% of Salesforce integration jobs fail 90 days post go live? Why? Because the integration service user's password expires! Consider setting it to never expire, but first check with your security team to make sure you are not violating policy by doing it.

Have a question you would like to as see a part of my FAQ blog series? Email it to me: Dave@Gluon.Digital

This article is adapted from my book: Developing Data Migrations and Integrations with Salesforce.