Need help tracking down something changing a field

Kai Tingey
Tera Guru

Hi All


Every morning at 6:30~am *something* is changing all our user records email addresses to lower case.

 

Screenshot 2025-05-26 141758.png

 

I can't find what is causing it.

 

The full LDAP import runs at 01:45 (you can see that in the log above), and that is setting the email correctly. Then at 06:30 or so, something else comes along and changes it to all lower case. 

 

There are no scheduled jobs running at that time, no workflows, no flow executions. Nada. The audit log isn't telling me much.

 

Has anyone got any ideas how i can track down what's doing this? It's not really hurting anything but it is pretty annoying now that i know that it's there.

7 REPLIES 7

James Chun
Kilo Patron

Hi @Kai Tingey,

 

Have you checked the Notification Device [cmn_notif_device] table?

There is a BR in the table that syncs the value of the email address to the same field in the user table.

It doesn't explain why it's updating at 6.30am but worth a look.

 

Cheers

SuyashJ41731830
Tera Contributor

Hi 
@Kai Tingey 

1. Check sys_audit and sys_audit_delete Tables More Deeply
You may have already looked, but try filtering these tables precisely:

Table: sys_audit

Field name: email

Table name: e.g., sys_user

Changed between: Use the time range around 6:30 AM

Add columns for: Created, User, Fieldname, Old Value, New Value

If the User is "system" or a specific integration user, that can give a clue.

2. Scripted Background Jobs or Fix Scripts
While you’ve ruled out scheduled jobs, check for:

Fix Scripts in System Definition > Fix Scripts.

Script Includes or background scripts that could be running on a time-based trigger (via custom script logic).

Look for scripts with toLowerCase() or manipulating email.

Try:

email.toLowerCase()
Search across all script types using "Studio" > Global Search or Script Search in the Application Navigator (Script Search plugin).

3. Business Rules
Check for Business Rules on sys_user that might fire on update or insert.

Filter by:

Table: sys_user

When: before or after

Insert / Update: true

Active: true

Look for any rule that may standardize email addresses.

4. Integration or Inbound APIs
Even if nothing is scheduled, an external system (e.g., an HR platform or identity manager) might be pushing updates early in the morning.

Check syslog_transaction or ecc_queue for integration activity around that time.

Look at REST API logs in System Web Services > REST API Explorer > Logs, especially if you're using MID Servers or external sources.

5. MID Server or Discovery
If Discovery or Orchestration is running at off-hours, and user data is tied to a CI or another discovery process, it could be updating attributes.

Look in:

Discovery Logs

Orchestration Debug

Scheduled Data Sources

6. Set a Watchdog Script
If all else fails, set up a temporary Business Rule to log or notify you when the email field is changed to lowercase.

Example:

javascript
Copy
Edit
// Business Rule: "Track Email Lowercase Changes"
if (current.email != previous.email && current.email == current.email.toLowerCase()) {
gs.log("Email changed to lowercase for user: " + current.name + " by: " + gs.getUserName());
}
Set it as:

Table: sys_user

When: after

Filter condition: email changes

You can even send an email or log extra context like gs.getUserID() or client IP.

If my response helped please mark it correct
Thanks, and Regards,
Suyash

very helpful suggestions thankyou

 

cant find any scripts that are setting it with studio search unfortunately

the closest discovery runs an hour after the changes are made

changes are made by 'system'

no business rules that are making that kind of change

scheduled data sources all look ok

 

i like the idea of creating a business rule to track changes, but is there any way for it to write *what* made the change? if all i'm getting is more logs saying it was changed, then it's probably not a lot better than sys_audit.

Maik Skoddow
Tera Patron
Tera Patron

Hi @Kai Tingey 

as the change occurs nearly at the same time and because the changing user is "system" it can only be an internal job, flow or workflow. Otherwise, for any integration, you would have any integration user there. So I highly recommend going through all of them and validate them one after another.

Maik