What are Roles and Secured Actions?

A role determines what functionality a user can access in the Web Client. Roles use secured actions to control access to user interface elements such as pages, menus, menu items, toolbars, and buttons. When you control access to individual user interface elements, you can control access to actions such as editing, deleting, or printing. Current secured elements are all user interface elements giving access to accounts, contacts, and opportunities.

You secure a user interface element by assigning a secured action to its Applied Security property in the Application Architect. Once a secured action is applied to a user interface element, only users who are assigned a role that includes the secured action can see and use the element. For example, Entities/Account/Edit is the secured action assigned to the Applied Security property for the Save button action on the Account Detail view. When the button loads at runtime, the display value changes depending on whether the user has permission to perform the action.

A user interface element in the Web Client that is secured restricts access from all users until a role is assigned which gives access to the user. To secure elements in the Web Client using roles you must add secured actions to elements, add the secured action to a role, and assign users to the role. The following section provides more information:

Elements are secured in the Application Architect by assigning a secured action to them, or applying security. The value of the Applied Security property is the secured action name. To secure an element in the UI and allow users access to that element you must:

  1. Determine what secured action you want to use to secure the element. If necessary, you can create a new secured action in the Web Client.
  2. Add a secured action to the Applied Security property for the element in the Application Architect. See the 'Understanding Secured Actions' topic in the Application Architect Help for more information.
  3. Add the secured action for that element to a role in the Web Client.
  4. Assign users to the role.

Default Roles

By default, users created in the Web Client are assigned the Standard User role. This allows access to all non-administrative functions in the Web Client. If you remove a user from this role, the user is not able to access any items that are secured, unless you assign a new role.

The default roles are:

  • Administrator: Allows add, edit, and delete permissions to administration functions such as users, teams, departments, pick lists, products, packages, Check for Duplicates, Process Duplicates, and Check for Duplicates History. Also gives edit permission for quick forms in the Web Form Designer.
  • Data Quality Manager: Allows add, edit, and delete permissions to Check for Duplicates, Process Duplicates, and Check for Duplicates History.
  • Standard User: Allows view, add, edit, and delete permissions to Web Client non-administrative entities such as accounts, contacts, opportunities, sales orders, leads, contracts, defects, and tickets. Also allows view permissions for products and packages. If you have existing users or create new users in the Administrator, you must assign users to the Standard User role.
  • Order and Quote Processor: Allows add and view permissions to contacts and accounts and add, edit, and delete permissions to sales orders.
  • Integration: Allows add, edit, delete, and view permissions for integrations.
    Note: This role is not recommended for standard users. The ability to view Sync History is part of the Standard User role. If users require access to other Integrations actions, for example the ability to authorize an integration, Infor CRM SLX recommends adding those actions to the Standard User role or creating a new role that includes those actions.
  • BackOffice: Allows add, edit, delete, and view permissions for back office integrations.
Note: 
  • Security in the Network Client is defined using feature security, function security, and administrative roles. Web security combines all Network elements into one security model - a role. You cannot use the Network security model for a user who is logged into the Web Client or the Web security model for a user who is logged into the Network Client.
  • The admin login can access all user interface elements, regardless of secured actions.

Using Roles and Secured Actions you can: