COINS ERP+ uses a layered permissions model to control which functions each user can access. This article explains how function access is evaluated, how to check and grant access, and how to resolve common access errors.
Check whether a user has access to a function
Before granting access, confirm whether the user already has it and where the permission is coming from.
Go to System Setup, then Users.
Click the link in the User ID column for the relevant user.
Select the User Function Access tab.
Filter on the function code you want to check.
Review the Allowed column — a tick means the user has access. The Access, Group and Role columns show where the permission is coming from.
📌Note: If you know the function code (for example, %WDM9200CDOC), enter it directly in the filter. If you do not know the code, navigate to the relevant screen in COINS ERP+ and note the function reference shown in the browser address bar or page header.
Grant access to a function
You can grant function access at the user level or the group level. Granting access at the group level is recommended when several users need the same permission.
Grant access to an individual user
Go to System Setup, then Users.
Click the link in the User ID column for the relevant user.
Select the User Function Access tab.
Filter on the function code.
Change the Access column value from G (Group) to Y (Allow).
Save your changes.
Grant access via a group
Go to System Setup, then Groups.
Open the relevant group record.
Select the Group Function Access tab.
Filter on the function code.
Set the Access column to Y (Allow).
Save your changes.
Confirm the user is a member of this group on their user record.
⚠️Important: Only system administrators should grant or change function access permissions. Granting access to the wrong function or group can affect security and data integrity across your system.
Resolve common access errors
User cannot access a function or menu item
Check the User Function Access tab to confirm whether access is explicitly denied (N) at the user level — a user-level denial overrides all group and role permissions.
If the user-level permission is G (Group), check whether any of their groups deny access to the function. Remember that group order matters — a denial in an earlier group overrides an allowance in a later group.
If access is not explicitly denied anywhere, check whether the function is included in the can-do allow list for at least one of the user's groups or roles.
If the function requires a specific role and your licence includes role-based access, confirm the role is assigned to the user.
If you are using Menu Item Security, confirm the user has access to the parent menu function, as well as the child function.
Newly created user cannot access anything
New user records are created with all permissions set to G (Group) by default. If the user's Prime Group has no explicit permissions configured, they will not have access to any functions.
Confirm the user is assigned to a group that has the appropriate function access configured.
Check that the Prime Group is set correctly on the user record — COINS ERP+ evaluates groups in order, starting with the Prime Group.
If no suitable group exists, either configure permissions on an existing group or create a new group with the required access.
Access appears correct but the user still cannot open the function
Ask the user to log out and log back in — permission changes do not always apply to active sessions.
Confirm the function code you are checking matches the one the user is being denied. Some screens have multiple function codes for different access types (for example, read-only versus edit).
Check whether a deny is applied at the user level, as this overrides group and role allowances.
If the issue persists after confirming permissions, raise a support ticket with the username, function code and a screenshot of the User Function Access tab.
When a user attempts to access a function:
Coins ERP+ checks the access permissions for the user (as set up in User Function Access). If the user has explicitly been allowed or denied access, this overrides any group permissions that may have been set up.
If you are using Menu Item Security, Coins ERP+ checks the parent function, which is an item on the Coins ERP+ menu, to see whether the user has access and the function is of the correct access type.
If the user has access to the parent, they have access to the child function by default, unless the permission has been explicitly overridden.
If the function is a menu, container or tab function, and the user has access to a function on that menu, container or tab, then the menu, container or tab is available.
If the user's permission is G-Group access (the default), Coins ERP+ checks the permissions for each group that the user belongs to, in the order the groups are defined on the user record, beginning with the Prime Group.
Coins ERP+ checks the can-do lists of functions and role types that are allowed or denied on the group. If the function is included in any of these lists, the user is allowed or denied access accordingly. (Within the same group, deny takes priority over allow.)
Coins ERP+ then looks at the permissions for specific functions set up on the group record. If the group is allowed or denied access then that is the result.
If you are using Menu Item Security, Coins ERP+ then checks the group access for the parent function; if the group is allowed access to the parent and the access type of the parent is the correct type, then the user is allowed access.
If the group record indicates G-Group access, Coins ERP+ checks the next group.
Because Coins ERP+ evaluates the permissions on each group in turn, the sequence of the groups on a user's record is important. If a group denies access to a function, the user will not be able to access the function, even if a later group would allow access.
Finally, if you have role-based licensing and your licence includes roles that are appropriate, you can use these to grant access to users. If the user is not a "named role" user Coins ERP+ checks any roles assigned to the user:
If the function is included in the "Allow" can-do lists of functions or role types on any of the roles, the user is allowed access unless explicitly denied by user or group access permissions.
If the function is denied by the role, Coins ERP+ continues by checking the user and group permissions. The user may still have access if allowed by user or group access permissions.
If the user is a "named role" user, they will ONLY be able to access functions allowed by their roles.
If none of the groups or roles explicitly allows access then the user is not allowed access.
When you create a new user record, all the permissions for that user are set to G-Group, so they only have access to those procedures and menus permitted for their group, until you explicitly change their access permission. Similarly, when you create a new group, all the permissions are G-Group. This means that, if you were to create a new group, and assign users to that group, without explicitly granting access permissions for either the group or the users, the users in that group would not be allowed access to anything.
Coins ERP+ always has a user called "SYSAdmin" and a group called "root". The SYSAdmin user has permission to do anything, as does any user who is in the root group who is not explicitly denied access.
How function access is evaluated
You can enquire on what access a user has to a function:
In Users, click the link in the User ID column.
Click the User Function Access tab.
Filter on the function you want to enquire about.
The Allowed column is ticked if the user has access to the function. The Access, Group and Role columns show whether the access or denial comes from the user function permissions, from a group, or from a role.
The following illustration shows how group access permissions affect the access of individual users. For a particular function, group A allows access, group B denies access, and group C specifies group access:
| User Function Access | First Group | Second Group | Role | Does the user have access? |
User 1 | N | Group A (Y) | Group C (G) |
| No |
User 2 | G | Group A (Y) | Group B (N) |
| Yes |
User 3 | G | Group B (N) | Group A (Y) |
| No |
User 4 | G | Group C (G) |
|
| No |
User 5 | G | Group C (G) |
| Role R (Y) | Yes |
If you are using Menu Item Security:
If a function is a menu, the user may be allowed access because they have been given access to a menu item on that menu.
If the function is a child, the user may be allowed access because they have been given access to the parent function.