Create useful documentation and keep good records of testing processes and results. Testing scripts, both human-oriented and C/AL Testability Tool-based, should be retained for future reference. Document the purpose of the modifications from a business point of view. Add a brief, but complete, technical explanation of what must be done from a functional design and coding point of view to accomplish the business purpose. Briefly record the testing that was done. The scope of the record keeping should be directly proportional to the business value of the modifications being made and the potential cost of not having good records. All such investments are a form of insurance and preventive medicine. We hope they won't be needed, but we have to allow for the possibility that they might be needed.

More complex modifications should be delivered and installed by experienced implementers, perhaps even by the developers themselves. Small NAV modifications may be transmitted electronically to the customer site for installation by a skilled super user. Any time this is done, all the proper and normal actions must occur, including those actions regarding backup before importing changes, user instructions (preferably written) on what to expect from the change, and written instructions on how to correctly apply the change. There must also be a plan and a clearly defined process to restore the system to its state prior to the change, in case the modification doesn't work correctly. As responsible developers, whenever we supply objects for installation by others, we must make sure that we always supply .fob format files (compiled objects) and not text (.txt) objects. This is because the import process for text objects simply does not have the same safeguards as does the import process for compiled objects.