There are universal constants that come with CRM systems. Here are the most common and consistent findings I’ve observed in my career while building solutions:

If a field isn’t required, it won’t be populated

Make fields requirements either through the page layout, or conditionally with a validation rule or dynamic form. RARELY does a field need to be required system-wide.

Users will divert from the “happy path” of system usage

Guardrails may need to be established to prevent user wandering, creating or editing records they shouldn’t. In Salesforce this can be done in a number of ways: page layouts, dynamic fields, permissions, validation rules, etc.

If it can happen, it will happen

Build each solution accounting for every possible system usage scenario (within reason). Robust thought before production deployment will reduce technical debt and boost end user confidence in the system.

There’s rarely a “perfect” solution forever

Working with technology often comes with compromise as not everything desired is possible or reasonably feasible. HOWEVER technology changes often and what may be impossible today may be possible tomorrow. Those building systems should always keep this in the back of their mind and not get sucked into the “perfect” mindset.

Business process will change, it’s a matter of WHEN not IF

A solution should be built to easily accommodate for minor changes at the very least and if possible, major changes. One way to avoid costly system overhauls is to be more generic in naming fields, often the hyper specific names won’t resonate with the next set of leadership or new business process.