[Emilyn]

Hi Bruce, I'm not sure, but it could be a minor difference in how they are querying for the value to display on the back end. I'm mentioning this because I have an active ticket open with a similar issue that is the result of Salesforce trying to get an ID, but mistakenly querying for a Name instead.
Is the ID still clickable?
If not, there are a couple of things you can do here:

• Short-term: copy/paste the ID from the error, duplicate the current tab and replace the ID at the end of the URL with the error ID and go. This will bring you directly to the record page that's causing the issue.
• Long-term: submit a ticket with SF (if you haven't already) so they can remedy the issue for your business.

I would say you could potentially write a custom override, but that would cost development time and I don't know if it's actually possible since that error handling is done by Salesforce. There's also the distinct possibility that this will be patched, which would nullify this override.

[Emilyn]

Hi Arun!
It's important that we use handlers for our triggers for many reasons:

• they keep logic out of the triggers themselves, which significantly improves legibility and ease of alteration because it allows the trigger itself to act as a sort of router, passing along tasks to the handlers
• Because the logic is separated out this way, it is far easier to pinpoint bugs and such when they occur
• they ensure that we are keeping our overall test coverage high for deployment, requiring a 75% coverage minimum where a trigger only requires a 1% min coverage

I'm sure there are many more, but these are the main ones I could think of off the top of my head.

[Emilyn]

If you did this, it would fail because you're essentially trying to make a duplicate record here. You are correct, however, in that the After context has access to the ID(s) of the updated record(s). In fact, with After Update we have use of trigger.new, which contains not only the ID(s) but all the fields for the updated records. To make changes to any of these fields, you could simply loop through trigger.new, updating the field values if they need to be updated. This is important and is one of the many reasons why it's not best practice to perform updates to updated records in After Update - if you don't validate those field values and instead set up the loop to always change them and update all the records again, you will end up in a potentially infinite loop.
Long story short, don't do this. Use Before Update unless it's absolutely necessary.