Difference between revisions of "Roles"
imported>Aeric |
imported>Aeric |
||
(21 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
'''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. | 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. | ||
Line 5: | Line 10: | ||
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. | ||
;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]] | |||
* | :* [[User, Team and Role Guidelines]] | ||
{{:Data Access Permissions}} | |||
{{: | <noinclude> | ||
[[Category:Administration| 17]] | |||
[[Category:Glossary]] | |||
</noinclude> |
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.)
- Role-Based Field Visibility, when used, specifies data visibility at the Field level.
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
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.
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:
- Click Designer > Roles.
The currently defined roles are listed. - Click the [New Role] button to add a role;
- Optionally, click an existing role to edit the role
- Specify the Role Settings (described below)
- Click [Save]
- Note:
The System Administrator role comes with the platform.
- Note:
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:
- Click Designer > Roles
- Click the name of the role you want to clone. The detail page for that role opens.
- Click the [Clone] button.
The Add Role page opens, displaying the settings from the Role you cloned. - Specify the Role Settings (described below)
- Click [Save]
Delete a Role
To Delete a Role:
- Click Designer > Roles
- Click the name of the role you want to delete; the detail page for that role opens
- Click the [Delete] button at the top of the page.
A confirmation dialog appears. - 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
Note: Before changing permission in a role, see these articles for information about how roles affect data access in the platform.
To edit permissions:
- Click Designer > Roles > {role}
- Click the [Edit] button
- 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
- This permission is specified as part of the Role Settings
- The default permissions are set as follows for the Default Roles:
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