Dynamics NAV Development for Non-Developers: Part 1 – Good Idea or Not?
In this series, we will be discussing some light Dynamics NAV development options that any user (with appropriate permissions) could tackle with only a minimal amount of background and practice. Before we jump in, it's worth considering whether or not a given user should perform light development changes themselves. Some examples of light changes include adding a field to a table, adding a column (field) to a list page, and making small adjustments to reports.
Four things for Dynamics NAV non-developers to consider:
1. Your partner has an advantage in making changes to the application.
If you are a user of Dynamics NAV, you almost certainly have a partner that either implemented the solution for your company or that supports you as issues arise and new customizations are required. This partner has the training and experience to design customizations, consider the ancillary impact and consistency, and ultimately test those customizations – all hopefully better than you could. This does not mean that you could not perform some of these tasks yourself, but the difference in backgrounds needs to be identified because you are starting at a disadvantage.
While still taking those points into consideration, performing minor changes yourself can save some modest dollars. Over months or years, those costs can add up. Additionally, there is an advantage to both you and your partner if someone at your organization is able to speak to the application at a deeper level.
2. Documentation and versioning.
When making these “light” changes, it is still important that you are working with your partner to ensure the changes are made consistently - with respect to the rest of the application. That consistency includes documentation, object versioning, object checkouts, naming conventions, database management, and test/development database refresh schedules. There are many different possible approaches to managing these and every partner has a slightly different perspective. The important thing is that you and they are managing these the same way.
3. You could potentially cause damage if not careful.
Things that could go wrong in writing your own customizations include:
• Accidentally overwriting previously implemented changes
• Accidentally overwriting a good object with a bad one
• Overwriting good code and business logic with bad (depth of this risk is dependent upon your license)
• Inadvertently purging existing data
• Crashing the application
• Corrupting the database.
The above are generally sorted by the risk of occurrence and the potential impact (least to greatest). With a few precautionary measures, these risks can be mitigated, but they need to be understood nonetheless. Each will be discussed in this series, within the context of the specific change being described that could expose the respective risk.
4. If you don’t have time to devote to NAV regularly, your knowledge of the tools will need to be repeatedly relearned.
The tools available for light development are not overly-complicated, but using them requires some familiarity with related nuances. Finding the place, process, property or trigger you need is often the hardest part of making a change. If you do not use these tools regularly, you will find yourself forgetting and then needing to relearn the development interface again and again.
I am a strong proponent of absorbing some development tasks in-house, as long as the above risks are understood and addressed accordingly. If you take all of these precautions and maintain solid communication with your partner, you will avoid potential confusion, lost work, added cost at your next upgrade, and general frustration. You will also better enable your organization to “own” the solution and more specifically cater it to your specific business needs.
Check back for more posts in a continuation of this series.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.