Sorry, your browser does not support JavaScript

How to Migrate ACT! Crm users

ACT! allows data for inactive users to remain in the database without assigning it to an Active user.  Most other CRMs do not allow this.  You will usually want to keep the data for the inactive users, but assign it to an active user in your new CRM.  Here's how it's done.

Definitions

User Types  

Each data record in the ACT! has 3 user types.  These are stored as a UniqueID pointer into tables containing user settings.

  • CREATEUSERID - This is the original Record Creator.  Once entered this cannot be altered.
  • EDITUSERID - This is the last user who made a change for the record.  If record data is modified or a related record is changed i.e. Note, History etc., this will be the user who made the change.  If no changes are made, this will be blank.  This is a system field and cannot be modified by a user.
  • MANAGEUSERID - This is the Record Manager/Owner of the record.  This field is set to the Record Creator when entered.  This field can be modified by any user.

User Status  

Each User can have one of the following status settings.

  • ACTIVE - Able to login to the database.
  • INACTIVE - Cannot login to the database. Data entered during their use of the database remains in the database.
  • DELETED - This is a soft delete.   Some data will remain like the Record Creator.  

Mapping ACT! Users to Target System Users

When users leave the organization, instead of deleting them from the ACT! database, they are usually made inactive and a new user is assigned their license.   Most CRM's don't support maintaining inactive users in the same manner as ACT!   Even if the new CRM allows inactive users, they usually don't allow migrated records to be created for inactive users.  Therefore, something must be done to properly reassign the ACT! data that belongs to the inactive users.  This includes their Notes, History, Opportunities etc.

The Exporter software allows you to do this from the Map User tab.    Below are a few examples of how this works.

Salesforce --  In this example the users ACT! System, Betty Browser, Chris Huffman, and Ernst Anderson are assigned to the SFDC User ID 00541000000QeuzAAC  the remaining users are assigned to SFDC UserID 00541000000Qf00AAC .
To obtain the Salesforce ID, the users must first be manually entered into Salesforce as Active users.   Then export the User object using the Salesforce Data Loader or Jitterbit.

SF User Map

ZOHO --  In this example the users ACT! System, Betty Browser, Chris Huffman, and Ernst Anderson are assigned to the Exporter generated ID UCF47F0E8-4A3B-498F-A327-CFF670D48AAC  The remaining users are assigned to U9A952FCB-ECF6-4FCE-92D1-047686F03BD2.  To get the Exporter generated ID into ZOHO, the Users must be manually entered including a valid e-mail.  Then using the Migration tool, the ACT_User.csv file must be imported making sure that the e-mails match.  This will cause the Migration tool to insert the ID from ACT! allowing the users to be properly assigned.  

ZOHO User Map

In order to have the ZOHO migration tool recognize the UserID, it must be brought in using the migration tool.  If you have assigned the users by any other method, you must use the migration tool making sure that the names and e-mail addresses match what is in the system.  You cannot export the User object and use the ID.