Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

User Principal name does not match the sys_user email

Jonathan69
Tera Contributor

Hi there,

 

I am working on the implementation of SAM pro for one of my customers and after integration with SaaS products(M365 and Salesforce) I am facing the following issue; the user_principal_name is does not match the user email of the sys_user entry because of the domain name (that is slightly different) BUT it does match the user_name.

 

Now out of the box ServiceNOW matches the sys_user to the subscription based on the sys_user email. I was able to create a "Fix" to this by adding a scheduled job that runs after import and gets the sys_user based on the user_name and updates the subscription record wit the proper sys_id--> that worked.

 

The issue now is that the same happens in the samp_sw_usage table and when I try to execute a similar script for that one, the business rule "Rebuild primary key on update" aborts the update (error;

Operation against file 'samp_sw_usage' was aborted by Business Rule 'Rebuild primary key on update^04226fef87aee110d347cbf90cbb35aa'. Business Rule Stack:Rebuild primary key on update

 

I understand what this BR "Rebuild primary key on update" does, but I don't really understand why it is aborting my update.

 

My script is querying the sys_user table and looks for the user_name to find the proper user and sets the sys_id to the samp_sw_usage record before updating the record.

 

That brings up three questions. 

 

1st --> Can the "coalescence" by made on the user_name instead of the email. If yes how can I modify this ?

2nd --> If 1st not possible is there a know workaround ?

3rd --> If neither of the above is possible, can my workaround work ? 

 

Thank you in advance for your help !

Best Regards,

Jo

2 REPLIES 2

jonsan09
Giga Sage
Giga Sage

I've run into a similar situation were the UPN didn't match any of existing fields for users. I ended updating our LDAP import to include the UPN to the user table. I then setup a scheduled job to run after the 'SAM Import User Subscriptions' to update subscriptions table to match the record to the user.

Jonathan69
Tera Contributor

Hi ! Jonsan09 thank you for your reply. That does works for Subscriptions, but not for Usage in my case...