A Matter of Degrees? Activity Tracking and Dynamics GP

More and more, it seems like the answer to most Dynamics GP questions is "well, it depends."  It might depend on how much money you want to spend on services and/or software, or how much you care about a particular piece of functionality.  And, lately, it seems like I am getting a lot of questions related to tracking changes within Microsoft Dynamics GP.  Sometimes this is due to "damage control", or because a prior system had the capability, and in most cases I completely understand the concern and the request.  And, like I have suggested, the answer is not a simple one.  There are several options available to you, depending on how much time/effort/money you want to spend.

At the very basic level, GP offers a few inherent tracking tools, for example:

• Many transactions table provide tracking of the user who posted the transaction (not who entered it, but who posted it).  These fields are visible in Smartlist (Microsoft Dynamics GP menu-Smartlist), for Financial-Account Transactions the field is called User Who Posted and for Purchasing-Payables Transactions it is called Posted User ID.  Some records also provide a modified date, although it does not show who (Purchasing-Vendors, for example).
• With the Human Resources module, tracking is enabled in the form of a "reason for change" on pay and position changes.  This enables reporting of who, what, and why on the changes.  Although it does not track the before/after values (which could be inferred to some degree based on the change)  Depending on your configuration in Microsoft Dynamics GP menu-Tools-Setup-System-HR Preferences, entering a "reason for change" may not be required. 
• There are controls available for batch approval and posting permissions through posting setup (Microsoft Dynamics GP menu-Tools-Setup-Posting-Posting) and security setup (Microsoft Dynamics GP menu-Tools-Setup-System-User Security) to control who can post transactions.  This is less tracking, but does help with the "damage control" requirement as security can also be used to limit access to master records, utilities, etc.

These are often some of the first options I look at, but GP also offers a couple additional options depending on your needs. One is included with GP, the other is an additional purchase:

• Activity Tracking- Tracks a number of tasks in GP, with basic information related to who, what and when.  This is included in core Dynamics GP.
• Audit Trails- This is an additional module that tracks the who, what, and when in detail including the before and after values of the field.  Audit Trails actually creates a separate database to track the audit information, and is configured to track changes based on your specific needs.  For more information, refer to this Microsoft Dynamics site on compliance, which includes a link to a fact sheet on the Audit Trails and Electronic Signatures modules.

We are going to take a look at the capability provided by the Activity Tracking feature included in core Dynamics GP.  First, let's look at the setup:

Activity Tracking Setup window

Microsoft Dynamics GP-Tools-Setup-System-Activity Tracking



Use this window to configure Activity Tracking, but be careful to only activate those items that you actually think will be useful (as this can add ALOT of records to your database very quickly).  There are five different types of activities you can track:

• Login/Logout Tracking- Tracks unsuccessful and successful attempts to log in to Dynamics GP
• Access Tracking- Tracks unsuccessful and successful attemps to access a file, window, report, or the Modifer and Report Writer tools
• File Tracking- Tracks additions, deletions, and modifications to Setup, Master, and Transaction files
• Process Tracking- Tracks use of File Maintenance, Utililties, and Routines
• Posting Tracking- Tracks posting by window/transaction origin

Select the Activity Type you wish to track, and select the User and Company to track.  Then mark the specific activities you want to include in the tracking, taking care only to select those items that you feel will be useful as noted above.  Repeat for additional activities, users, and companies as needed. Click OK when complete.

The results of the activity tracking can be viewed easily:

Activity Tracking Inquiry window

Inquiry-System-Activity Tracking

Note that the activities can be filtered by company, user, activity type, and activity.  The information available includes the company, user ID, date, time, and description of the change.  The description includes the record that was affected, but does not include any details of the specific change (this is the major difference between activity tracking and the Audit Trails module-- the level of detail about the change available).  You can also report on this information through Reports-System-General-Activity Tracking Detail.

If you choose to use activity tracking, make sure you set up a recurring task for yourself to remind you to remove the detail on a regular basis.  Keeping the activity detail in your database indefinitely can increase your database size quickly depending on the types and number of activites being tracked.  To remove activity detail:

Remove Activity Tracking Detail window

Microsoft Dynamics GP menu-Tools-Utilities-System-Activity Detail

Use this window to remove the activity detail based on parameters you specify, including activity type, activity, and ranges by date, user, and company. Generally, you would run this process after a full backup of your databases.  Select and insert the necessary ranges (don't forget to mark the activities to remove, and to mark the "Remove Records" and "Print Report" checkboxes), and then click Process to remove the records.

Although activity tracking may not necessarily meet all tracking and audit needs, it can be a useful tool with minimal investment of time and/or money to see results immediately.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

Dynamics GP Activity Tracking

My blog has moved!  Please visit the new blog at:  https://blog.steveendow.com/

I will no longer be posting to Dynamics GP Land, and all new posts will be at https://blog.steveendow.com

Thanks!



By Steve Endow

Several times I've received an inquiry along the lines of:

"Can you tell me how to view the Dynamics GP security and access logs? We need to know who logged on and when they logged on."

When clients ask this question, it is typically because they want to review the historical logs to research an issue. Unfortunately, by default, GP does not log security events or user activity, so the answer is usually that such data does not exist.

However, for those clients (and diligent consultants) who are aware of the possible need for such logs, now is the time to consider the Dynamics GP Activity Tracking feature to determine if it should be enabled.

Dynamics GP Activity Tracking has three windows:

1) Activity Tracking Setup
2) Activity Tracking Inquiry
3) Remove Activity Tracking Detail

Before I discuss the details, let's discuss what Dynamics GP Activity Tracking can, and cannot, provide.

Activity Tracking can provide basic logging of basic Dynamics GP security events. A user logged in successfully, or unsuccessfully. A user opened a window. A user logged off.

It can also track when a window was successfully opened, or when a user failed to open a window. And also when a user creates, modifies, or deletes a master record or transaction, or even when a user prints a report. And finally, the tracking can tell you when a user posted a specific type of batch.

On the surface, this sounds pretty nice, and sounds fairly comprehensive. However, before you go and turn on all sorts of Activity Tracking, you will want to ask yourself a few questions.

1) Why do you want to turn on activity tracking? Do you have a specific reason or scenario that the tracking will help address?

2) If you enable tracking, does the data collected specifically answer the questions that you will have?

3) How much effort are you willing to dedicate to managing and analyzing the tracking information?


I mention these because of a client request that I received several years ago. "Steve, we want to know when Sally came into work, how long she worked, what she did, and whether she was goofing off at work."

Dynamics GP will NOT answer any of these questions. If Sally came into work at 8am but did not login to GP until 10am, the login event won't necessarily be meaningful. If she entered some transactions but then had phone calls and meetings and paperwork outside of GP for several hours, the lack of activity in GP isn't meaningful either. And finally, even if you could see a log of everything she did in GP during the day, are you really going to sift through hundreds or thousands of records to understand what work or how much work she did during the day?

My recommendation is that you should use the GP Activity Tracking feature as a supplementary security audit log, or potentially as a diagnostic tool. The Tracking feature is not a replacement for a supervisor or manager that manages and monitors employee activity throughout the day, and in my experience, it is not very useful for HR related issues.

So with that long winded aside complete, let's look at the Dynamics GP Activity Tracking windows.

The Activity Tracking Setup window (Tools -> Setup -> System -> Activity Tracking) has four components.

It allows you to configure the types of activity that you would like logged, the users you would like to track, and the company databases where this tracking should be enabled.



The Activity Type drop down box provides a list of 5 different categories of activities that can be tracked. Once you select an activity type, the Activity list will be updated with specific Dynamics GP events that can be tracked.

After you choose the specific activities, you will select a user that you wish to track. Once the user is selected, the Company list will be updated with companies that the user can access. You can then select the specific companies where you want that user's activity tracked.

In the screen shot above, I chose to track all login events for the sa user in the Fabrikam company.

And here I am tracking when the sa user creates, updates, or deletes master files and transactions.



Now that we have enabled some tracking, let's take a look at the data provided by the events. The Activity Tracking Inquiry window (Inquiry -> System -> Activity Tracking) allows you to review all of the activity records, and provides basic filtering and sorting.



You can filter by company and user, as well as the activity type and specific activity.

If the inquiry window doesn't meet your analysis needs, you can access the activity data directly by querying or exporting the SY05000 table in the Dynamics database. You can then filter by date and time, and even search for specific data in the event description.



Last, but by no means the least, is the Remove Activity Tracking Detail. Once you enable tracking, you will likely notice that the number of records in the SY05000 table can grow very quickly. If you are tracking alot of events for all of your users (which I generally don't recommend), you can have tens of thousands of records build up.

To help manage this data, the Remove Activity Tracking Detail lets you selectively delete the activity records. You can remove specific types of activity records, for specific companies, users, and date ranges.




Given all of this functionality, here are my recommendations for using Activity Tracking.

1) Before enabling tracking, write up a few paragraphs about what events you think you would like to track, and why you want to track those events. This will help you determine how you will configure and use the tracking feature.

2) Enable as few events as necessary. Many people are inclined to track everything, but that produces alot of useless records, making it difficult to find meaningful events in the data and causing the logging table to grow unnecessarily. For example, instead of tracking inserts, updates, and deletes, you can use a SQL log viewer to review transaction logs if necessary. If you are already using Full Recovery Model for your GP databases and performing transaction log backups, rely on those for detailed data tracking instead.

3) After enabling tracking, try testing the data to confirm that it meets your requirements. Are you able to see the events that you needed? Does the data provide you with the detail required to answer the questions you had in mind when you wrote your requirements?

4) Don't be surprised if the tracking data does not answer some questions if an issue arises. Even though you enable tracking, there may be events that occur that raise questions that the logging data simply can't answer. As I mentioned previously, these are often HR related questions, and not necessarily security questions.

Enjoy!

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com