Stub Users Reviewed - Aric Levin's Digital Transformation Blog

I have encountered many engagements in which the client needed to migrate data from other systems which had users that were not longer within the organization, and those users did not require access to Dynamics 365, but the client wanted to keep track of who the original owners or users that created the records were.

Microsoft Dynamics provides the ability to create Stub Users. Stub users are user records that are created in Dynamics CRM. These records are designed for users that do not exist in CRM, but can be referenced during an import process. The user accounts cannot be logged into the system, and modifications to the user records are not possible either.

Stub users can only be created using the Create or Create Requests methods of the SDK (or using an import tool such as SSIS with Kingswaysoft).

Stub users are different from interactive users and disabled users. The following table shows the difference between the users types:

User Type	Full Licensed User	Non-Interactive User	Office 365 Synchronized User	Stub User
Access Mode	Full	Non-Interactive	Full	N/A
CRM Licensed	Yes	N/A	No	No
Synchronized	Yes	Yes	Yes	No
Visible in Admin Portal	Yes	Yes	Yes	No
Has an Organization Id	Yes	Yes	Yes	No
Enabled in CRM	Yes	Yes	No	No
Has Access to CRM API	Yes	Yes	No	No
Has Access to CRM UI	Yes	No	No	No
Can be created using CRM	Only in On-Prem	Yes	No	No
Can be created using Import Process	Yes	No	No	Yes
Can be created usin API	Yes	Yes	Yes	Yes

Stub users are different from regular disabled users in the sense the disabled users can consume a license, and disabled users can still be a part of Office 365 or Active Directory.
When migrating users, the users should be originally created in the target environment (whether Online or On-Premise), and only then the migration should occur.

Another import thing to note, is that when stub users are created, they are automatically assigned the SalesPerson security role, and that security role cannot be altered. If you need to provide these users other permissions, you will need to modify the SalesPerson security role to have those permissions, and revoke them after your migration has been completed, as stub user records cannot be modified in any way after they are created.