This article offers a overview of some of the concepts behind Microsoft Dynamics GP Security, including tips and best practices for managing security.
Originally published in Q3 2017 GPUG Magazine
There is probably a section of Microsoft Dynamics GP that you hate going into; the mere thought of making changes brings cold sweats and a racing heart…Security. I’m purely guessing, of course. I mean, what other reason could there be to account for the persistent, “Don’t touch it; it’s not broken” attitude that is prevalent across so much of Microsoft Dynamics GP’s Customers? Well, it’s pretty common that Users will be very vocal in complaining when they can’t get into a window or run a report they think they need, but they are usually a lot less vocal about times they think they shouldn’t have access to that same window or report.
Basics
First off, some quick details on the concepts behind Microsoft Dynamics GP Security. A User is set up in Microsoft Dynamics GP, and that User can be given access to one, none, or all your companies. For each company you give a User 
access to, you can add him/her to some roles. A User can have completely different roles for each company. These roles are what give a User permission to do things in Microsoft Dynamics GP. All this information is stored in the DYNAMICS database (or whatever your system database is named). Simple, right?
Access (Administration > Setup > System > User Access
Setup)
One of the first things that a User will notice is when they don’t have access to a Microsoft Dynamics GP Company that they were expecting to get into. While controlling access to companies is probably the easiest part of managing Security, there are some things that you should consider and be aware of before simply moving on. When a User is given access to a company database, Microsoft Dynamics GP goes out to SQL and adds that User to the database you selected. Why should you care? You can run into issues when you have a test company. Most Customers will have a test company; if not, stop reading and create a test company. The test company is probably refreshed at some point in time on a regular basis. Well, if you have some Users who have been bad or are being trained, and you only give them access to your test companies after a refresh of the test company, you will notice that they can’t login to the test company, and you get an error when you try to remove and re-add them to the test company. The issue is with how SQL stores its User information. When you refresh your test company, all the Users assigned to that database are an exact copy of what is on your production database. If that User didn’t have access to the production database, but they have access to the test database, after the refresh, Microsoft Dynamics GP will think they should have access, but SQL will not allow them to connect. It gets worse: When you try and remove the access to the test database, you get an error. Now we must get serious and open SSMS. Go to your test database and expand Security > Users and find, and then delete, the offending User. Now you’ll be able to go back into Microsoft Dynamics GP and give them access to the test company again. The better solution would be to simply give the User access to both the test and the production companies; then just remove all their roles for the production database. That way even after a refresh, they’ll still be able to get into the test database, and they can’t do bad things in production.
Tracking (Administration > Setup > System > Activity Tracking)
One of the best practices that probably more companies should be taking advantage of is Activity Tracking. Activity Tracking, as the name implies, tracks Users and what they do in the system. This is not an audit trail; it will not tell you who specifically changed a vendor’s EFT information, but it will tell you the people who’ve saved changes to the vendor record. It can be very powerful, but there are some drawbacks. Don’t rely on it and think that you will be able to tell what everyone is doing; it can be frustratingly terse at times when describing what record is being changed, and it can be a bit of a size hog. If you start tracking all activities, be prepared for an uptick in SQL utilization. You can configure what activities you want to track and what Users/companies you want to track in. The tracking information is stored in DYNAMICS. dbo.SY05000.
Alternate/Modified Forms (Administration > Setup > System > Alternate/Modified Forms and Reports)
You control what version of your alternate/modified forms and reports a User will see by assigning the particular version you’d like to use to an Alternate/Modified Forms and Reports ID. You can then assign this ID to a particular User and company under User Security (Administration > Setup > System > User Security).
Roles/Tasks (Administration > Setup > System > Security Roles / Security Tasks)
One of the key things to keep in mind about Microsoft Dynamics GP Security is that it is based on a pessimistic view. Essentially, you have no rights to anything unless they are specifically granted to you. The current security architecture is a role-based system. So, a User is given one or more roles, and those roles have certain tasks that are assigned to them. These tasks are what say, “You have access to this Window”. One of the more complicated parts of Security is trying to find out what particular Task/Role will give a User access to a particular window. Your best bet is usually to take your time and familiarize yourself with some of the naming conventions of Tasks.
- ADMIN_Module_Resource – Administrative tasks related to a module, usually the Setup, Routines, and Utility windows, can be found here. e.g. ADMIN_INV_005* allows a User to reconcile inventory.
- CARD_Sequence – These are a bit tricky; they are usually the “cards” like the Customer card or the item card. There isn’t really an easy way to search through other than looking through the task names. e.g. CARD_0501* allows a User to maintain employees (Employee Card).
- INQ_Module_Resource – These tasks will give a User access to the inquiry windows in a particular module. e.g. INQ_FIN_004* will allow a User to view GL journal entries.
- RPT_Module_Resource – These will control the reports (including posting reports) for a module. e.g. RPT_SALES_004* is the task for the Sales posting journals.
- TRX_Module_Resource – Controls entering/posting any transactions into the system. e.g. TRX_INV_005* gives permission for posting in the inventory module.
You can always double-click on any of the tasks on your system, and that will take you to the Task Setup window where you can inspect exactly what a Task allows. Generally you’ll leave the product to Microsoft Dynamics GP, and the Type will be windows; then just select the series (Sales, Inventory, etc.), and the system will list out everything that the Task is granting permission to.
You could make changes to these tasks, but that is generally a bad idea. Any time you do an upgrade, any customizations you do to these built-in tasks and roles may
be reset back to the default version that shipped with Microsoft Dynamics GP. The better way is to create your own Tasks and Roles and then customize those. It’s easy to copy a default Task or Role into your own version, and then simply make the changes you’d like and start assigning Users to the new role. That is, of course, after you test it in your test company, right?
