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!
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:
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.
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.
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.
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.
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.
Salesforce has an awesome "Login as User" feature, use that to test your security settings post migration before allowing (user) testers in the systems.
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.
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.