You use access management to control what your users can see and edit in the software. All access is controlled at the role level except for access privileges. You can assign access privileges at the role and/or user level.
The following options are available in access management from the most general access control to the most specific access control:
System Features
System features are the large areas of functionality you are licensed to and includes the screens, sections/tabs, actions and fields related to that area. You can choose to make some system features inactive so the related screens, sections/tabs, actions and fields are not available to any of your roles and users, including administrators, in the software.
For example, your license includes Fulfillment Orders as part of a larger license purchase but your organization does not use them. You can make the Fulfillment Orders system feature inactive so it is not assigned to any roles and no one has access to the sections/tabs, screens, actions and fields related to fulfillment orders.
To view and update system features:
- Click the System Features link from the Main Menu. The System Features page opens.
- Uncheck the Active box for any feature you do not want available. You cannot make features inactive that have a gray check box. These features are required for use of the software.
- Click the Save button.
Features
Features are the same as system features but you can assign access on the role level. When you add a new role, all the active system features are automatically assigned to the role so the role has access to everything in the software. You can then remove any of the system features you do not want the role to access.
For example, your Sales Department needs access to Customer Relationship Management to manage their accounts but does not manage any accounts receivable tasks like adding payments and invoicing. You can assign the Customer Relationship Management feature to your Sales Department role to give them access to account and contact functionality. You can not assign them to the Accounts Receivable feature so they do not have access to payment and invoicing functionality.
See Assign Features to Roles for more information.
Access Exceptions
After you assign features to your role, you can further manage access using access exceptions. Access exceptions apply to sections/tabs, columns/fields and actions.
You can use access exceptions to:
- Deny access to a section/tab, column/field or action within a feature assigned to a role.
- Grant access to a section/tab, column/field or action that is part of a feature you have not assigned to a role.
Any time you deny access to a section/tab, column/field or action, it overrides any other setting that may grant a user access. If you deny access to an action, you deny access to that action everywhere in the software. See the next section, Action Restrictions, for more information on hiding an action for a specific area.
For example, your Sales Department does not manage any accounts receivable tasks but they do need to see the AR Balance for their accounts. In this case, you do not want to assign the Accounts Receivable feature to the Sales Department role as that would give them too much access. Instead, you can use access exceptions to give them access to only the AR Balance field.
See Access Exceptions for more information.
Action Restrictions
When you create an access exception for an action, it is applied throughout the software. However, you may have times where you want to hide an action for a particular page or window. In those cases, you can use action restrictions.
For example, the Add Note action is available from a lot of screens in the software. If you use access exceptions to deny the Add Note action, it is denied everywhere. If you use action restrictions to deny the Add Note action for the Events page, you can restrict access to that action from only the Events page while keeping the Add Note action available on all other pages.
If a user is assigned to more than one role and one role has an action restriction to hide an action and another role has an access exception to grant the action, the software uses the least restrictive access and gives the user access to the action.
See Action Restrictions for more information.
Field Restrictions
You use field restrictions to require, protect and/or hide fields in the software. Field restrictions are set on the role level so they are used regardless of which theme you use.
See Field Restrictions for more information.
Access Privileges
You use access privileges to further refine what users can do in the software. For example, which users can edit events beyond a certain status or which users can delete notes with certain note sensitivities. There are two types of access privileges: System Access Privileges and Access Privileges.
System access privileges apply to all organizations if you use multiple organizations. Examples of system access privileges include editing dictionary phrases and add/editing roles and users.
Access privileges apply only to the organization you configure them in. Examples of access privileges include editing events up to a certain status and deleting documents up to a certain sensitivity.
You can assign access privileges at the role and/or user level.
See Access Privileges for more information.
Comments
7 comments
Hi! I'm trying to understand the difference between Access Exceptions and Access Privileges in 20.8, and I'm having trouble finding an explanation in the support center on Access Privileges. From reading the few articles that mention it, my understanding is that Access Privileges were something used in v19 that is still respected in v20, and it sounds like they overlap in purpose with Access Exceptions. Is this accurate? Are there any distinctions between Access Exceptions and Access Privileges in v20?
1 upvotes
Hi Alex,
You are correct that access privileges were used in v19 in order to control access to different processes and areas within the software (along with menus). Access privileges are still respected in v20 and can still be used.
Access Exceptions are the same principle as Access Privileges but it allows more finite control on an action by action or field by field basis as well as "hiding" the processes a user can't perform.
A simple example is there is an access privilege that prevents users from editing multiple accounts. If the user doesn't have that access privilege, the user still sees the Edit Multiple option but when they go to use it, they receive a message that they don't have access. If you used access exceptions to control the access to Edit Multiple on the Accounts screen, you can remove the Edit Multiple option from the users right-click menu so the user never even sees the option.
There will still always be a need for access privileges - such as limiting access to edit an event by coordinator or status, which access exceptions aren't built to manage (at least they aren't today). So there are some cases where the access privileges and access exceptions don't overlap.
Please don't hesitate to let me know if you have any additional questions.
Thanks,
Maggie
0 upvotes
Thanks, Maggie, this is very helpful. I'll let you know if any other questions arise!
0 upvotes
Hi! I want to affect the field restriction on a field that doesn't have the same field restriction icon in Edit Layout that other fields do. Is it possible that not all fields are eligible for field restrictions? Specifically I am trying to grant access to edit the Document Description (MM446_DOC_DESC). Is it unavailable in Field Restrictions?
0 upvotes
At this time, the Document Properties window does not have Field Privileges enabled for any of the fields in this window, including Description. As we continue our development within the software, this idea will continue to be explored. Thank you for your suggestion, Laura.
0 upvotes
Thanks Ken. That's helpful.
0 upvotes
Indeed it would be very handy to have this feature globally. The other day I needed to make the Management Report Code mandatory on the Issue Invoice window but similarly I could not.
0 upvotes
Please sign in to leave a comment.