01

Configuration comes first

Standard applications, Studio-style configuration, access groups, automated actions and documented workflow changes can address many requirements. Custom code should not be the automatic response to a familiar process.

The implementation team should first explain the standard path and the operational trade-off. A small process adjustment may be safer than a permanent software extension.

02

Good reasons to extend

A custom module can be appropriate for a differentiating operational rule, a specialized approval sequence, an industry-specific record, a controlled external integration or a user experience that standard views cannot responsibly provide.

The requirement should be stable enough to encode, valuable enough to maintain and specific enough to test.

03

Protect maintainability

Extensions should use supported inheritance and module patterns instead of modifying core files. Include access rules, upgrade considerations, tests, documentation and ownership for future maintenance.

Before release, test ordinary users as carefully as administrators. Permission errors and unintended record visibility are common sources of operational risk.

04

Make the decision visible

Record the gap, alternatives considered, chosen approach and expected maintenance cost. That decision log helps future teams understand whether an extension remains necessary as the platform evolves.