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