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

Hi Frank,

I’d recommend sticking with your organization’s process for managing changes. Here’s why:

• The fix you’ve described might be super simple, but sometimes fixing a small problem reveals another problem.
• It’s possible that the issue will resurface in future deployments if it’s fixed in production but not the source package.
• We (the community) don’t know the details of your company’s implementation or why certain processes/policies exist. 

At the very least, I’d suggest asking the person/group that handles deployments whether this particular issue can be fixed on the fly in production. That way everyone is on the same page. 

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!

Thank you this was very insightful

Thank you!!! Will keep in mind of those risk assessments for when I come into the days the I need to work with that type of system