In our most recent webinar, we took a look at Controls & Security in Microsoft Dynamics GP. In this webinar, we covered how you can improve controls and security in Microsoft Dynamics GP using a mix of standard ad third party functionality. If you want to catch up on this, or any other, webinar, you can do so here.
- Posting Controls
- Workflow Approvals
- Security Setup
- Field Level Security
- Report Security
- Single Sign-on
As always in this type of webinar, I try to use standard functionality as far as possible, but this is not always possible as not all of the areas being covered are included as standard. This was a deliberate design decision from the very creation of Microsoft Dynamics GP where they decided that supporting third parties would allow many more developers to work on modules for the system and encourage competition and improved standards from those third parties (known as Independent Software Vendors or ISVs for short).
There are three key areas where I am recommending third party modules and I will try to be clear when I am doing this.
The first area where you can apply additional controls and security is the use of the standard posting controls. These are ways that posting of transactions in Dynamics GP can be controlled to reduce the risk of errors or people doing thigs they should not be doing.
The first of these posting controls is the use of the Allow Account Entry option in the Account Maintenance window () which allows you to stop users posting transactions to an account on which this checkbox is unmarked. This is the recommended configuration for control accounts (like you Trade Creditors or trade Debtors accounts as well as the Bank Control accounts).
The account will be defaulted by Dynamics GP, but the user cannot annually select the account; this ensures only transactions which should post to the account, can post to the account.
Account Level Security is a standard module which needs to be configured and enabled before use, but which allows you to limit which users can see and use which accounts in the chart of accounts. This is useful for example, if you have multiple departments or divisions with their own accounts and who should not be able to post to codes belonging to other divisions or departments.
There is a lot of setup required for this module as users can only see accounts to which they have been given access. Any new account won't be visible until it is added to users so there is also ongoing maintenance required.
Posting Setup () allows you to enable options making control totals mandatory on batches; you can configure this per batch type so you can enable it for Payables Transactions, but not Computer Cheques as an example. When the options for Verify Number of Trn and Verify Batch Amounts are marked users need to enter the number and value of transactions which will be in the batch. If the entered transactions don't match, then the batch cannot be posted.
Marking these options for a transaction type will mean you also want to unmark the Allow Transaction Posting option so users must use batches.
Posting Setup (workflow approvals which allow you to build routings which send batches to different people depending on the data in the batch.) also has an option for Require Batch Approval and associated password, which adds a checkbox to the Batch window; until this checkbox on a batch is marked the transaction cannot be posted. A better option that this would be to use
Modules such as Payables and Receivables Management allow passwords to be set for certain actions such as exceeding credit holds or write-offs. The passwords are usually configured via the module setup windows, but are stored in plain text so any users with access to these windows will be able to see the passwords.
hen a password is set the password must be entered before the action can proceed.
One of the things I recommend to clients using either Purchase or Sales Order Processing is the use of "standard items"; this is a list of products which they buy and sell, even if they are not tracking stock levels. Non-stock items can still be set up in Dynamics GP as Service items.
When items are setup default accounts to use for posting can be set, which means users entering orders do not need to make any decisions about which GL account to select which for narrative items they would need to do.
One key control which can be used is workflows for approvals; the use of approval workflows means that transactions can quickly and easily be approved by the relevant approver, distributions can be checked and corrected and people who enter the transaction cannot also approve it, thereby forcing segregation of duties. Dynamics GP has a number of workflow approvals available, with new versions having been added regularly.
The below diagram shows the workflows available and when they were introduced:
Automation in Dynamics GP was covered in detail in the February webinar, but it is worth noting that automation can help with controls by taking data entry and other actions out of the hands of users, thereby minimising the risk of errors.
Security in Microsoft Dynamics GP is multi-layered with the basic security model being a pessimistic one where users only have access to the functions which they have explicitly been given access to. On top of this are other security features which can be enabled.
The core security of Dynamics GP is the security role and task model. At the top level is the security role which is assigned to users; this security role contains many security tasks which themselves contain many security operations. A security operation is a window or report or other item which can have access granted.
Because there are so many features in Dynamics GP, there are many thousands of security operations in Dynamics GP, but these are contained within security tasks which are clearly named so you can easily tell at a glance what a security task will allow you to do. There are also some security roles grouping these tasks together, but it is reasonably straightforward to create new security roles.
Users can have different roles assigned to them in different companies, giving a great deal of flexibility over their access.
There are some standard reports available to review security in Microsoft Dynamics GP but they aren't very flexible. A few years ago I created a series of SQL views which can be used in SmartList Designer. SmartList Builder or other reporting tools.
Pretty much every client I have spoken to over the last few years would benefit from a security review to make sure that their security roles and tasks are suitable for their current requirements and users don't have access to functions they do not need and which could cause series damage including catastrophic data loss, should they be misused either through accident or maliciousness.
This spreadsheet contains one page for each module and then across the top are all of the tasks listed; you can use this as the basis for designing new security roles before creating them into Dynamics GP.
I mentioned earlier that workflow approvals can be used for segregation of duties as you can prevent the same person entering and approving a document. You can also configure your security roles to avoid giving the same person security tasks which would allow them to, for example, create and pay an invoice. The Security Informer add-on, one of the GP Elementz from ISC Software, includes a function called Segregation of Duties which allows you to flag roles which cannot be assigned to a user together; when you try to save the User Security Setup window ( ) an error is displayed with a report which shows the conflicts. These conflicts need to be resolved before the save can be performed.
Security Informer also includes three other functions which can aid with security:
- Identify missing security
- Safely auto-logout users after idle timeout
- Change the colour of windows in each company
Security Informer is a paid add-on for Dynamics GP, not a standard module; if you're interested in purchasing or seeing a demo, use the contact form at the bottom of the post to get in touch with me at ISC Software.
Field Level Security is a standard module which gives another layer to the security. this window allows you to change the behaviour of windows in Dynamics GP by disable, locking, hiding or password protecting specific fields; different users can have different restrictions applied. Using this function you can give users access to a window but stop them setting or changing data in some fields. In the webinar I password protected the Creditor Account field on Creditor Maintenance ().
Depending on the type of report, there are several ways security can be used to restrict access.
SmartLists and navigation lists, like the standard reports, have access controlled through the standard security roles and tasks.
Management Reporter allows users to be created with one of four licence types:
- Administrator which gives them access to everything including security configuration.
- Designer which gives them access to design, generate and view reports.
- Generator which allows them to generate and view reports.
- Viewer which only allows them to view reports.
Administrators can maintain security for other users as well as build a folder structure into which reports can be generated; the folder structure can have permissions applied to control which users can view, generate or delete reports in those folders.
This allows you, to for example, have a folder structure for each company which only users from that company can access.
Other reporting tools, such as SSRS, refreshable Excel reports, Jet Reports and so on will have some of their own permissions built-in, but can also be restricted further with database roles which can limit from which databases or tables data can be selected.
Dynamics GP has the option to remember user and password which can go some way to easing access to Dynamics GP; however, users do need to know their password if the system is setup to require passwords to be reset periodically. There is an alternative which allows for single sign-on access to Dynamics GP.
The Config AD add-on from Fastpath integrates Dynamics GP and allows users to log on using their Windows password. This removes a password from the list which users need to remember. I've sold this module to a few clients who have all been very happy with it.
A key area of concern around Dynamics GP which is increasing raised by auditors is an audit trail of changes made to data.
The nearest Dynamics GP comes to audit is the Activity Tracking module which allows you to see when users logged in or logged out and when they changed a record; however, it does not show what they changed, just that they changed something. If you want audit, then additional functionality is needed.
A few times over the years I have created a simple audit using a custom table and SQL triggers for clients who needed a small amount of auditing performed. I recently posted the simple audit on Address Electronic Funds Transfer Master (SY06000) as an example of how this can be done.
However, if you have a lot of data to audit then you'd be better using a full audit solution.
Audit Trails allows you to create triggers on tables, easily replicate them between companies and has an Azure hosted web portal which allows you to run reports on the audited data.
As you can see from the above, there are many facets to controls and security in Dynamics GP, but it is a very flexible solution so you can pick the elements which will work for your organisation. Things like segregation of duties works for larger organisations, but not smaller ones as they tend not to have sufficient people to separate the person creating creditors from entering and posting invoices. Generally they'll have an approval process around payment runs, but little else.
If you have any questions about any of the above, please use the contact form to get in touch.