---
title: "Impersonating in a Transform Map"
canonical: "https://docs.perspectium.com/space/Iodine/1705219/Impersonating%20in%20a%20Transform%20Map"
format: markdown
---
Purpose If you are using an Import Set and Transform Map for replicating data, you may have seen that data is being updated as the “System” user. If you want to have these records being updated by a specific user and/or have these updates run in a specific domain, you will want to use impersonation. This is done via the following steps: Determine the user to impersonate Impersonate this user via that user's  user_name Store the previous session Record Gets Updated Impersonate the previous session This last step is important. If you are impersonating within the Transform Map we highly recommend   you make sure you have handling to un-impersonate back to the original session. Otherwise, this job will remain running as the user that you have impersonated. In other words, the Subscriber Job will typically pick up a batch of records, process them sequentially, then finish. If you impersonate on the 3rd record and do not un-impersonate, the 4th record will run as the impersonated user. This can affect your Subscribing as the Activity Log may display the wrong user and the update may fail if this user doesn't have access/visibility to its record. Implementation Impersonation How you determine the user to impersonate will vary slightly. The general practice is to use the submitted data to query for a user on your instance to impersonate. If this user does not exist, use a backup “generic” user. Often it is the case where you don't have this user in your system, so you might just opt to always use a “generic” user. You can utilize an onBefore Script like the following: // Default username
var username = "Generic_ACME_User";
 
// Determine the user to use
var email = source.u_assigned_to_email.toString();
if(email != "") {
    var uGr = new GlideRecord("sys_user");
    uGr.addQuery("email", email);
    uGr.query();
    if(uGr.next()) {
        username = uGr.user_name;
    }
}
 
var oldUser = gs.getSession().impersonate(username);
target.psp_impersonated_user = oldUser; Where this will use the value passed into the [u_assigned_to_email] column to lookup a User [sys_user]. You would adjust this to whatever column you are using and populating in your Import Set Table. If a user with this email exists it will use this user's user_name. If not, it will use the user with user_name “Generic_ACME_User” (per whatever default user you create). It will then store this old user on the target record so we can easily access it later in an onAfter Script. Un-Impersonation In an onAfter Script you are just using the stored impersonation to un-impersonate our session. // Un-Impersonate from the stored impersonation on target record
var oldUser = target.psp_impersonated_user;
var impersonatedUser = gs.getSession().impersonate(oldUser);
gs.log("Impersonated: " + impersonatedUser + ", Switched Back to Original: " + oldUser, "Perspectium.impersonation"); The last statement there is just an optional logging statement to see that this impersonated a user and switched back to the user it was before. Storing the Impersonation You   do not   have to create or have a column on the target table named “psp_impersonated_user”. This is just one of the simpler ways to pass the impersonation from the onBefore to the onAfter script. Since this column doesn't exist in ServiceNow it won't pay any attention to this “psp_impersonated_user” value in the update. The remaining columns will be treated independently.