Why do upgrades keep breaking our customizations—even when we follow best practices?

[Matthew_13]

Hi Community,

Every upgrade, we run into the same story basically custom UI tweaks, scripts, or workflows that worked fine suddenly break or behave differently , even though they were built upgrade safe.

This makes it hard to trust the our platform and slows adoption.

A few questions for the group:

• What types of customizations have caused you the most trouble during upgrades?

• How do you decide when to customize vs. use out-of-the-box functionality?

• What practices have actually helped reduce upgrade pain—not just in theory, but in real life?

Curious to hear what’s worked and what hasn’t for the rest of you using it?

[Mohammed8 · Accepted solution]

Hi @Matthew_13 

1) From my experience, heavy form customizations often lead to form breakdowns or performance issues. In one client engagement, every field change on the Incident form triggered a call to another record, which significantly slowed down form load and user interaction. 

2) In another case, a client wanted to change the behavior of the Save button specifically, to display a Yes/No popup where No option would save the form and the other would create a child Incident task. Identified that modifying the core Save behavior could easily break standard platform functionality and create upgrade risks. Instead, we proposed an OOTB alternative like there is existing Create Child Incident Task capability, copying that and  converting it into a custom button, and implementing the required logic there. To help the client make an informed decision between customization and OOTB, always have a (POC) demonstrating both approaches. This helps them see and understand customization versus supported platform features.

3) Whenever possible extending  OOTB behavior instead of modifying it. Documenting even the slightest of customization has always helped during upgrade.

Thanks and Regards,

Mohammed Zakir

[Mohammed8 · Accepted solution]

Hi @Matthew_13 

1) From my experience, heavy form customizations often lead to form breakdowns or performance issues. In one client engagement, every field change on the Incident form triggered a call to another record, which significantly slowed down form load and user interaction. 

2) In another case, a client wanted to change the behavior of the Save button specifically, to display a Yes/No popup where No option would save the form and the other would create a child Incident task. Identified that modifying the core Save behavior could easily break standard platform functionality and create upgrade risks. Instead, we proposed an OOTB alternative like there is existing Create Child Incident Task capability, copying that and  converting it into a custom button, and implementing the required logic there. To help the client make an informed decision between customization and OOTB, always have a (POC) demonstrating both approaches. This helps them see and understand customization versus supported platform features.

3) Whenever possible extending  OOTB behavior instead of modifying it. Documenting even the slightest of customization has always helped during upgrade.

Thanks and Regards,

Mohammed Zakir

[Matthew_13 · Accepted solution]

Thanks; good information for me!