...

It is possible to ingress fake mail to TEST, but the process is a lot of effort for low return. Basically, the way you do this is you send mail to PROD service now as the user you want to emulate, then you copy and paste the received message details from PROD service now into TEST service now, then tell ServiceNow to 'process message' on the fake received mail you created manually in TEST. Does that sound hard? It is. Verifying the user detail is a sufficient test of this bug.

Backeberg reticence for releasing this

As I wrote up the test cases for this, I spotted several anomalous users in TEST and DEV. I quickly discerned that IST imports in DEV and TEST were broken. After I fixed those, I noticed further issues. We do special processing on imports for IST table, where we only run the transform script on a row entry in the import table if the value changed from the last run. As these values are only changing rarely, very few records are getting updated that would use the changed transform script. Ergo there were several users that were not fixed by the changes for D941.

Therefore there will also need to be a manual deploy for part of D941. We will need to do a one-time change to set all affected records to Active.

And that reminds me of a compounding bug. If we are also setting the graduated for a certain year, and then the next year rolls around, and the records continue to not change, those records will continue to be Active, even though the reasons for that will no longer exist.

I think one possible way to fix this entire issue, rather than doing this one time change, is instead to do a delete of all of IST, or at least a delete from IST of all the unicorn users. This would force THOSE records to all go through the update process.