LDAP Import ignores Reference qualifier

[Marko5]

My instance is using the CSM application and therefore has a core_company and an inherited customer_account table. 

The LDAP import of users includes the company (as string).

I want to avoid to mix up data and want to force that users have companies on the core_company table and contacts have companies on the customer_account table. I set two reference qualifiers on the company fields at the sys_user and the customer_contact table and it is working fine if you try to set companies manually.

But the import of users in the sys_user table (standard data source->transform map) is ignoring the reference qualifiers and sets customer_account records as company for users.

Any ideas if there is a secret property or attribute to set to make the import respecting the reference qualifier?

[AB3 · Accepted solution]

When importing users into the sys_user table using the standard data source and transform map in ServiceNow, the import process may not automatically respect the reference qualifiers set on the company fields. This can result in incorrect assignments of the customer_account records as the company for users. To address this issue, you can try the following workaround:

1. Create a transform script: In your transform map, you can create a transform script that runs before the company field is set. This script will validate the company value and determine the appropriate target table based on the type of record being imported (user or contact). Here's an example of how the transform script could look: 

(function runTransformScript(source, map, log, target /* GlideRecord */) {
   // Check if the record being imported is a user
   if (target.getTableName() === 'sys_user') {
      var company = source.company.toString(); // Assuming company is a string field in the import source
      var customerAccount = new GlideRecord('customer_account');
      
      // Check if the company exists in the customer_account table
      if (customerAccount.get('name', company)) {
         // Set the company field to the customer_account record for contacts
         target.company = customerAccount.sys_id;
      } else {
         // Set the company field to the core_company record for users
         var coreCompany = new GlideRecord('core_company');
         if (coreCompany.get('name', company)) {
            target.company = coreCompany.sys_id;
         }
      }
   }
})(source, map, log, target);
​

1.  Attach the transform script to the transform map: In the transform map configuration, locate the "Advanced" section, and set the transform script you created in the "Run script before field map" field.
2. Test the import: Perform a test import to validate if the transform script correctly sets the company field based on the record type (user or contact) and respects the reference qualifiers.

By using a transform script, you can customize the import behavior and ensure that the company field is correctly assigned to either the core_company table or the customer_account table based on the type of record being imported.

Note: Make sure to adapt the script to match the specific field names and table structures in your instance. Additionally, thoroughly test the import process after making these changes to ensure the desired behavior is achieved.

For asking ServiceNow-related questions try this :
For a better and more optimistic result, please visit this website. It uses a Chat Generative Pre-Trained Transformer ( GPT ) technology for solving ServiceNow-related issues.
Link - https://nowgpt.ai/

For the ServiceNow Certified System Administrator exams try this :
https://www.udemy.com/course/servicenow-csa-admin-certification-exam-2023/?couponCode=NOW-DEVELOPER

[Marko5]

Thanks, that helps. 

Meanwhile the user import was changed to Azure user provisioning, which is even worse. Azure is writing the user table directly with a ServiceNow admin account. (Yes, I know, but that is how the Azure - ServiceNow integration is working)

I solved it with some business rules on the user table for now. Hopefully ServiceNow will improve that integration with Microsoft, because from admin/architect point of view it is awfully solved without transform maps.