Though unique, it is not unique across multiple transactions.
For example:
User 1 saves a change that causes some newly deployed code to throw an exception, that we have caught, logged, and displayed a standard error message.
User 2 makes a change that causes some other exception, in some other area of the application. Again, we catch, log, and show standard error message.
Both users generate an incident. Depending on the length of time it takes to investigate the issue, there could be more logging done for the same ticket. When we go to look up the logs by Incident sys_id, we have to sift through any logs with that sys_id logged to it.
By having a unique transaction id, we could add that to the standard error message... maybe even give the user a link to auto generate an incident pushing the transaction id into the description. Then we can lookup just the logging associated to the that particular issue.
So that is my base business need, but lets expand. What if it is a transaction not triggered via a standard form. What if it comes from a UI page or a widget in Service Portal or maybe via a integration and is not tied to a single record. Again, if we have a transaction id, then we can include that in our logging and issue responses and can find logging for a specific transaction.
Having read this last bit, it clarifies even more that a business rule isn't the way to go. I need to generate the id at the very start of each process endpoint.
