M2M Permissions. Please Provide Some Input

In my free time, I’ve been working on the permission problem I wrote about a few weeks ago. I’ve managed to get the permissions to output correctly and created a system to report from them in Integration and Reporting Services (more on that in a later article).

I’d like your input on it before it’s finished. In the past, when I’ve audited a company’s permissions, I took a look for the following security concerns.

  1. How many users have Root access? Do all of them need it?
  2. I encourage the decision maker to restrict how many people have deletion and change status permissions most modules. M2M’s auditing options are poor and life is easier when you know that only 2 people in the building can delete certain records.
  3. I encourage the decision maker to restrict permissions higher than view to people who do not need them. In other words, Sales People should not be able to add/edit/Delete Purchase Orders.

I’m not suggesting the permission reporting system would block you from doing anything you wanted, but it would raise a red flag that Bob in Sales can delete anything in Invoicing, Item Master, etc.

The problem has always been that M2M does not have user designations integrated into it. With the exception of Form Customizer Groups, nowhere in M2M does it say that Sally works in accounting. I’m exploring ways to fix that. For now though, I need to come up with a system of classifying employees that is neither too restrictive nor permissive. In other words, I don’t want to have 25 different employee groups, but I also don’t want to have 2 groups which divide up M2M in half either. I want a user role system that suits a majority of M2M companies.

To that end, I have created the following groups. Most of them will include two levels of permissions. The Base type would represent your worker bees while the Manager type has more permissions such as Change Status and Delete.

Here are my groups, along with a brief description of their access permissions.

  • Admin – Root Access (Business Owners would be Admins as well).
  • Sales – Has add+ permissions to Sales, Quotes, and Prospects.
  • Accounting – Add+ permissions to AP, AR, and Customer set up. The Manager would have access to GL.
  • Purchasing – Add+ permissions to purchasing.
  • Shipping/Receiving – Add+ permissions to those areas.
  • Production – Includes Inventory, Serial Numbers.
  • Operations – Includes everything but Admin and Accounting.

What do you folks think? Do you have a better idea of how these groups should be defined? Try not to think of just your particular employer, but rather as M2M companies as a whole.

2 comments to M2M Permissions. Please Provide Some Input

  • Dave

    Our company is pretty small which means some of us wear many hats. In addition we are looking at our process flow which means employees responsibilities may change but their department location will remain the same (the responsibilities may traverse departments). Additionally management tier level may not have higher rights in M2M for us. We also find that the form customizer groups can be a double edged blade working against us at times.

    My guess is we are the exception to the rule but I thought you might find the information interesting none the less.

    I think granular groups might be a plus or group behavior similar to or honoring MS AD or maybe similarities to Share permissions.

    Just food for thought.

  • Forrest Williams

    The last place I worked had shipping and receiving split into two separate groups. Also, there were only two people that could perform all the inventory transactions.

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>