The record audit displays a nwTransactionId which seems to also appear on the Jobs app, but I’m unable to search against it, if I try I get a HikariProxyPreparedStatement error.
Hi Anleo! This field is used by our internal audit logic to ensure we don’t insert duplicate records. It can not reliably be used to trace a transaction.
It also should never be exposed. Where are you seeing this on the Jobs app?
Thanks @brendan.b it’s available via the advanced filter. Can you please advise then how does one trace the originating transaction from the audit record i.e. I’m trying to hunt down the logic responsible for making a change.
The platform does not have any sort of transaction tracing today. You can check users and timestamps on Jobs to see if any match the audit history. The same can be checked in Workflow Queued Transition Inquiry. Finally, you may be able to reach out to Support and the Operations teams to assess Access Logs if you suspect the mutation occurred via endpoint request.
1 Like
@anleo.pienaar are you interested in determining which transaction updated a particular record or, more generally, the logic responsible for an update?
If you’re after tracing the logical path of a particular transaction, debugging via the Logic Block Debugger or using Application Monitoring can be helpful. These tools will allow you to dig into the flow of actions responsible for a record modification, and I can provide some additional documentation or information if that would be helpful.
If the goal is instead to investigate what transactions caused the state of a record that already exists, the tools that @brendan.b mentions are the most useful:
2 Likes
Thanks @ross.blackburn it’s the latter, we did try and narrow it down based on the timestamps that correspond with jobs, the issue is that there is no exact match, these are typically large batch jobs and there is high traffic of various jobs running at the same time. There was no workflow change in this case.
1 Like