Is it ever OK (fundamentally / philosophically speaking) to directly update production with a email message template change?

Great question! Eli already provided the perfect answer!

I just want to add an additional layer as we had the same discussions in our company. --> Its totally ok to update in production...if your process allows it!

One solution would be to conduct a risk assessment, which helps define specific rules based on the level of risk.
For example, low-risk changes, such as fixing a typo, could be exempt from requiring a second person for review.

This approach ensures you stay efficient while managing potential risks appropriately. You can add the results of your risk assessment to the process. While you might allow more freedom on trivial issues, you can also add more requirements for high-risk scenarios. It´s a win-win.

Some examples (this is not my actual list)

Low risk:
- Add a Value to a List item
- Fixing typos of content that is NOT code related (!).
- Adding translations

Medium:
- Trivial JS code
- CSS / UI changes that don´t include logic

High:
- ItemType changes
- SQL , C# 
- JS code if it does more than UI
- Change Workflow
- Fixing typos in Method items (!)

Very high (affects other departments)
- Security related changes
- Changes that have influence to a connector (CAD, etc.)

Depending on the risk level of a change, different measures are required to ensure quality and minimize potential issues:
- Tests on independent test server required
- 2nd person required
- Other entities required (IT, external partner,...)
- Needs update of documentation
-...

In addition you have general risk minimizing actions that apply always:
- Only trained experts are allowed to do these changes
- Major Updates done outside main working hours.
- Backups
- Regular meetings that ensure everybody is up to date
- ...

If somebody know more, I would be happy to hear about your approach to the topic!

Great question! Eli already provided the perfect answer!

I just want to add an additional layer as we had the same discussions in our company. --> Its totally ok to update in production...if your process allows it!

One solution would be to conduct a risk assessment, which helps define specific rules based on the level of risk.
For example, low-risk changes, such as fixing a typo, could be exempt from requiring a second person for review.

This approach ensures you stay efficient while managing potential risks appropriately. You can add the results of your risk assessment to the process. While you might allow more freedom on trivial issues, you can also add more requirements for high-risk scenarios. It´s a win-win.

Some examples (this is not my actual list)

Low risk:
- Add a Value to a List item
- Fixing typos of content that is NOT code related (!).
- Adding translations

Medium:
- Trivial JS code
- CSS / UI changes that don´t include logic

High:
- ItemType changes
- SQL , C# 
- JS code if it does more than UI
- Change Workflow
- Fixing typos in Method items (!)

Very high (affects other departments)
- Security related changes
- Changes that have influence to a connector (CAD, etc.)

Depending on the risk level of a change, different measures are required to ensure quality and minimize potential issues:
- Tests on independent test server required
- 2nd person required
- Other entities required (IT, external partner,...)
- Needs update of documentation
-...

In addition you have general risk minimizing actions that apply always:
- Only trained experts are allowed to do these changes
- Major Updates done outside main working hours.
- Backups
- Regular meetings that ensure everybody is up to date
- ...

If somebody know more, I would be happy to hear about your approach to the topic!