Difference between revisions of "Roles"

From LongJump Support Wiki
imported>Aeric
imported>Aeric
 
(One intermediate revision by the same user not shown)
Line 9: Line 9:


When role based access permissions are defined, users get streamlined views and reports, access to process-based workflow and the ability to complete their work online, in one place, with no extraneous information to distract from their flow. Roles are intended to control access, but they also add needed structure.  
When role based access permissions are defined, users get streamlined views and reports, access to process-based workflow and the ability to complete their work online, in one place, with no extraneous information to distract from their flow. Roles are intended to control access, but they also add needed structure.  
;Roles, Users, and Teams:
:* Each [[User]] in an application is assigned one or more Roles.
:* Users select which Role is active, at any given time.
:* Users can have different active roles in different browser windows.


;Considerations:
;Considerations:
:Each role can include a combination of any of the following permissions:
:* Each role can include a combination of any of the following permissions:
::*Create or Delete records for each Object in the application
::*Create or Delete records for each Object in the application
::*Update, Delete or View records owned by other Team members  
::*Update, Delete or View records owned by other Team members  

Latest revision as of 01:05, 17 October 2012

Designer > Roles

Roles are categories of users. Permissions can be assigned to a role. Then, as individual users move into and out of those roles, they acquire or drop the associated permissions.

About Roles

Your organization will be more effective when your users can get the information they need, when they need it. Sales representatives use data differently than marketing managers, VPs, CEOs or the folks in accounting. For example, a sales rep making cold calls needs a telesales application with activity logging capability, while a senior manager presenting to staffers may need structured, summary reports to manage overall business goals.

In an organization, employees have authority over information in different areas - they play different roles in each situation. In the platform, parallel roles can be defined to automatically manage access to that data. The information each employee needs to perform a task becomes available, and can be shared with a team of employees.

When role based access permissions are defined, users get streamlined views and reports, access to process-based workflow and the ability to complete their work online, in one place, with no extraneous information to distract from their flow. Roles are intended to control access, but they also add needed structure.

Considerations
  • Each role can include a combination of any of the following permissions:
  • Create or Delete records for each Object in the application
  • Update, Delete or View records owned by other Team members
Learn More

Default Roles

The out-of-the box implementation includes a default role, to get you started.

Role Access Permissions
Manager By default, a manager has full permissions to create and delete records in application objects, and has full access to records owned by other team members.

Learn more: Access to Records Owned by Others Within the Team


Custom Roles

Additional roles can be added and existing roles can be modified as the needs of the organization change. Note that Visibility Controls are an extension of Roles, and also affect the data that is available to users.

For example, a Web Tab can be created that is only available to managers.

Roles and Data Visibility

A user's access to data is determined by a number of factors:

  • The user's Access Profile specifies global access permissions and administrative permissions.
  • The Application Access settings determine which applications the user can run. The Objects available to the user are therefore the combination of
a. Objects that are part of the running application
b. Objects that or are shared from other applications.
  • The user's Role in the application, as specified by the Application Access settings, specifies high-level access rights to individual application objects. (The privileges granted in Access Profiles and Roles are additive. If either the Access Profile or the Role grants permission to perform some operation on an object, then the user has that permission.)
  • The Team the user belongs to, and the access to records owned by other team members, as determined by the user's [{Role]].
  • Custom Access Criteria can be used to specify access rights for individual Records (add, view, update, delete), based on record data, user characteristics, and any other available information.
  • Visibility Controls determine whether records owned by others are visible and optionally, whether they can be modified.
  • Team Data Sharing Policies, which allow to data to be shared across Teams. (These settings override the record-level access permissions specified in the individual's Visibility Controls.)

User, Team and Role Guidelines

In conjunction with Access Profiles, the combination of Team and Role assignments control the user's ability to view and access data.

  • Users
  • Users can be members of multiple Teams
  • When users are given access to an application, they are assigned one or more Roles
  • Roles
  • Roles are defined for applications
  • Roles define the types of data users can access and share with other team members
  • Default Roles are available in the platform
  • Additional roles can be created and the default roles can be modified as needed
  • Teams
  • Each user must be assigned to a Primary Team
  • When a user is assigned to a Primary Team, any previous primary team assignment is replaced

Working with Roles

Roleaccessrights.gif

Application users generally fall into categories, or roles. A person in each role needs permissions to work with some kinds of data (objects), but typically doesn't need to work with (or even see) other kinds data.

It is common for new roles to be added over time, and for existing roles to evolve as the organization grows and business procedures are refined.

Lock-tiny.gif

Users that have the Access Control permission can create teams and roles, add users, assign users to teams, and designate access permission 

Role Management Restrictions

The ability to manage roles is subject to the Permissions Hierarchy restrictions.

Add or Edit a Role

To add or edit a Role:

  1. Click Designer > Roles.
    The currently defined roles are listed.
  2. Click the [New Role] button to add a role;
  3. Optionally, click an existing role to edit the role
  4. Specify the Role Settings (described below)
  5. Click [Save]
Note:
The System Administrator role comes with the platform.

Clone a Role

You can clone a role in order to save time in creating a new role that has similar settings.

To Clone a Role:

  1. Click Designer > Roles
  2. Click the name of the role you want to clone. The detail page for that role opens.
  3. Click the [Clone] button.
    The Add Role page opens, displaying the settings from the Role you cloned.
  4. Specify the Role Settings (described below)
  5. Click [Save]

Delete a Role

To Delete a Role:

  1. Click Designer > Roles
  2. Click the name of the role you want to delete; the detail page for that role opens
  3. Click the [Delete] button at the top of the page.
    A confirmation dialog appears.
  4. Click [OK] to delete the role.

Role Settings

Role Information

Name
The name of the role as it will appear in the platform
Description
Text that describes this role and its settings (permissions)

Role Permissions

Notepad.png

Note: Before changing permission in a role, see these articles for information about how roles affect data access in the platform.

To edit permissions:

  1. Click Designer > Roles > {role}
  2. Click the [Edit] button
  3. Specify the settings for this role

Record Access Permissions

Specify record create and delete permissions for selected objects.

Access to Records Owned by Others Within the Team

Specify update, delete, and view permissions for selected objects. (These permissions apply to records owned by a different member of the team.)

Considerations
Role Update Delete View
Manager Yes Yes Yes
  • For Activities (Tasks and Appointments), users with this permission can also reassign Tasks to a new owner.
Learn more: Assign Task Owner