Permission Set Creation (anyone have predefined to share?)

I’ve been assigned the task of establishing permissions and developing role-based permission sets for our organization. The roles are straightforward. Here’s what’s needed:

  • Inventory Manager: Needs access to items, vendors, and ordering processes.
  • Accounts Payable: Responsible for vendor payments, processing one-time purchase invoices, and managing vendor relationships.
  • Accounts Receivable: Handles customers, customer invoices, and receipt processing.
  • Additionally, a comprehensive set for all accounting functions is required.

The initial three roles should be restricted from accessing the chart of accounts and viewing the financial details associated with each account. Although I’ve adjusted menus and roles, this hasn’t stopped users from using the “tell me” feature to access restricted areas. Utilizing the recording feature in permission sets often inadvertently grants full read access to the general ledger accounts, which is not our intention.

The recording adds numerous permissions, many of which are unclear, leading to confusion. There’s also uncertainty about whether the settings are correct, especially since table 15 is granted full read access—raising concerns about other unintended permissions being set.

The first three roles do need posting capabilities, and I’ve discovered that this can be accomplished through adding two permission sets. One with read permissions set to yes and limiting to entry zero. the other with read permissions set to indirect.
Is it really as simple as setting the primary tables to indirect if they show up in the recordings and the user shouldn’t have permission to get to the card page for that table?

Does anyone have “starter” permissions sets that are easily built off of?

DM me through my blog Cynthiapriebe.com. I have permission sets that provide the restriction you are asking for to G/L entries. After adding you need to check that nothing else is overriding by using Effective Permissions.

Permissions are intended to be table based, not page based. If you limit permissions by page, there is nothing stopping the user from access via a different page.

While permissions is meant to be table based, I’ve been successful at the page based solution.
The key is that the permission set must have the excluded pages in the top section and then any included permission sets in the lower left.
This way the default system permissions can be used and then pages can be excluded in the main section to prevent the user from even having the page listed in searches.
Yes there can be other ways to get to the data via the table but we have found this can work.
It does have issues in that some pages are used list pages and need to be accessible in other areas so testing is required.
I’ve tried the two permission sets to limit access to the GL details that Cynthia Priebe promotes. I got it to sort of work. I had to change the default permissions provided by the system and if the user went to the chart of accounts, no numbers were listed however when they tried to preview a posting, it would indicate a permission setting wasn’t correct.
We will tackle this again at somepoint but the page exclusion is doing the job for the moment.
There are a lot of setup tables we don’t want touched and would like to restrict access to but that’s all for another day.