Recently, a customer approached me with questions about how a particular custom report could be deployed to all users. After explaining all the ins and outs of Dynamics GP customization deployment, it occurred to me that a lot of users (and their IT support folks) are not entirely aware of how to best manage customizations across their companies. This lack of understanding can potentially lead to lost customizations or reports when a workstation is replaced or when an upgrade is performed. This blog explains the options you have and pros and cons of each of them.

I have previously written a blog series discussing the different customizations options available to GP users, so we are not going to get into those details here. Instead, I am going to focus on the simplest and most common customizations which involve modified reports and forms in Report Writer and Modifier. These types of customizations create modified dictionaries (files) that reside somewhere in your network and must be accessed every time the user runs a modified report or opens a modified window, for example. The location where these dictionaries are stored, and how they are deployed to users can affect performance, increase or decrease your risk of losing a valuable customization, and make it easier or harder to do maintenance and updates to the customizations involved.

By default, custom forms and reports are stored locally on the Dynamics GP Data directory in each workstation. Any change you make on any particular workstation (such as modifying a report or window) will be stored locally and will not affect any other users. The alternative way is to configure your system so that customization dictionaries are stored on a central location accessible by everyone (such as a shared directory where every Dynamics user has read/write privileges). If that was the case, then the changes made from any workstation would affect all other workstations.

I always recommend keeping customizations local, even if this means that a “deployment” process must happen after every new change has been tested and approved. You can tell if a GP client is setup for local or shared location for the dictionaries by looking into the pathnames inside the Dynamics.set file in each workstation. I also recommend to make sure that all users have the same customizations so that these are standardized across the company. It may be useful to have the same report modified in two different ways for two different users, but that is usually an exceptional requirement. Keeping all customizations standard across all users takes the guesswork out of an upgrade process and reduces the risk of losing important customizations. Ideally then, you want to have a single set of modified dictionaries that you can deploy across the company.

So, what are my options for Customization deployment? In short, here are the different deployment options for custom dictionaries:

1. Shared custom dictionaries: Dictionaries stored in a shared location
• Pros:
• Simplifies deployment — you place a custom dictionary in the shared directory, and everyone will be accessing the same customizations.
• All users have the exact same customs, all the time. There is no guessing here about that.
• Cons:
• You cannot modify custom dictionaries while being used. So, you need a “development” workstation configured with local customs where to make changes before deploying them. Then, copy the resulting dictionaries to the shared location so that everyone gets the new changes. This is easier said than done, since all users need to be out of their systems so that the replacement of dictionaries is allowed.
• Creates unnecessary network traffic. Think about a modified invoice report, or check. Every time someone prints a check or an invoice, the system has to fetch the custom report from the shared location. If you have lots of users, this will add network traffic accordingly.
• Shared reports and forms dictionaries are more prone to corruption as they are being used by many users.

2. Local custom dictionaries: This is how GP comes by default
• Pros:
• Since customizations are local, the operations related to them are quicker and less prone to issues. When the user prints a modified invoice or a check, the modified formats are found in the local workstation, so all is good and quick.
• You can modify reports or forms anytime, since you are not sharing the local dictionaries with any other user.
• Cons:
• You need to have a deployment strategy as well as a backup strategy. When you deploy, you need to basically copy the new dictionaries to each workstation (or export a customizations package and import them to each workstation). That can be tedious if you have a lot of users. I recommend to always keep exported “Packages” with all customizations and have some versioning technique for them in case you wish to go back to a certain version if a new customization does not cut it.
• Because each workstation has its own set of dictionaries, you may end up with a “creative” user that changed something on their workstation and then no one else has this change. Worse yet, when you update everyone with a new change in the “unified” version of customizations, this user’s changes will be lost since they probably never told you about them anyway.

3. “Hybrid” solution: At our larger customers we have implemented a very successful “hybrid” solution that allows the “best of both worlds” when dealing with the pros and cons above. We suggest configuring GP to use store the custom dictionaries locally (the default setup) on each workstation. Then, keep a “master” copy of all custom dictionaries somewhere in the network accessible by all users. Finally, create a windows domain login script that runs for each Dynamics GP user, and copies the custom dictionaries from the shared directory to their local directory upon login to windows, in essence replacing their existing dictionaries with copies of the “master” dictionaries. This results in GP Clients using dictionaries locally, but being refreshed every time the user logs in. Any change to the shared “master” custom dictionaries is done on a development environment where all new custom work is done. When the work is completed and tested, the dictionaries in the shared directory are replaced with local dictionaries from the development environment, and all you have to do is alert all users to log off and log back on, so all workstations are updated with the new code. This solution works very well in an environment where the installation of GP is done in a standard way and all users have the same features installed, all of which is best practice anyway.
• Pros:
• Even though it takes some effort to setup initially, this solution encompasses the best of both local/shared dictionaries deployment options discussed above.
• Since customizations are local, the operations related to them are quicker and safer.
• All users have the same customizations.
• Modifications take place on a separate development environment until properly tested and approved, which is a best practice.
• If a user gets “creative” and makes changes (or even damages) a report or form, a simple logoff and logon process will refresh their custom dictionaries, fixing the issue.
• Cons:
• It does take a bit of work and expertise to setup the scripts.
• You need to designate a development environment, which for smaller customers could simply be a specific workstation that you know has the latest customizations and that will be used for the purpose. In larger companies, it will probably be one of the Dynamics GP test servers.

Taking care of your customizations and keeping them standardized and backed-up are an important part of your overall Dynamics GP management strategy. Understanding the available options can go a long way in helping you avoid confusion as to who has what installed, and also avoid issues when upgrading your Dynamics GP environment.

If you have any questions about managing your Dynamics GP environment, contact us!

Tags: Managing customizations, Report Writer, Modifier, Packages