User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:adminmanual:securityguide:rbsbasics-ch001 [2019/04/17 22:56] joebordes |
en:adminmanual:securityguide:rbsbasics-ch001 [2019/04/17 23:07] (current) joebordes |
||
|---|---|---|---|
| Line 51: | Line 51: | ||
| * exercise CRUD operations\\ | * exercise CRUD operations\\ | ||
| - | At Figure: [[en:adminmanual:securityguide:rbsbasics-ch001#saf|Special Admin Function]] you see the edit view of a users data provided by the CRM user management function. With marking the Admin check box any user might get administration privileges and become an administrator user.\\ | + | At <wrap em>Figure: Special Admin Function</wrap> you see the edit view of a users data provided by the CRM user management function. With marking the Admin check box any user might get administration privileges and become an administrator user.\\ |
| Figure 1.1. Special Admin Function | Figure 1.1. Special Admin Function | ||
| Line 57: | Line 57: | ||
| {{ :en:adminmanual:securityguide:adminfunction.png?nolink |}} | {{ :en:adminmanual:securityguide:adminfunction.png?nolink |}} | ||
| - | Note: Administrator users have all privileges in the organization. | + | <WRAP center round info 60%> |
| + | Administrator users have all privileges in the organization. | ||
| + | </WRAP> | ||
| === Roles === | === Roles === | ||
| Line 81: | Line 83: | ||
| Profiles are used to define privileges for executing CRM system operations. From a functional perspective, role-based securities central notion is that of profiles representing actions associated with roles and users that are appropriately made members of roles.\\ | Profiles are used to define privileges for executing CRM system operations. From a functional perspective, role-based securities central notion is that of profiles representing actions associated with roles and users that are appropriately made members of roles.\\ | ||
| - | The relationships between users, roles, and profiles are depicted in [[en:adminmanual:securityguide:ecurityguide:rbsbasics-ch001|Figure: User, Role and Profile Relations]] as a many-to-many relationship. For example, a single standard user can be associated with one or more roles by different user names, and a single role can have one or more user members. Roles can be created for various job positions in an organization. For example, a role can include sales representative or assistant in a company. The profiles that are associated with roles constrain members of the role to a specified set of actions. For example, within a sales organization the role of the sales representative can include operations to create, edit, and delete the own accounts; the role of an assistant can be limited to browse existing information of a particular sales rep; and the role of the head of sales may be to review all sales data.\\ | + | The relationships between users, roles, and profiles are depicted in <wrap em>Figure: User, Role and Profile Relations</wrap> as a many-to-many relationship. For example, a single standard user can be associated with one or more roles by different user names, and a single role can have one or more user members. Roles can be created for various job positions in an organization. For example, a role can include sales representative or assistant in a company. The profiles that are associated with roles constrain members of the role to a specified set of actions. For example, within a sales organization the role of the sales representative can include operations to create, edit, and delete the own accounts; the role of an assistant can be limited to browse existing information of a particular sales rep; and the role of the head of sales may be to review all sales data.\\ |
| **Figure 1.2. User, Role and Profile Relations** | **Figure 1.2. User, Role and Profile Relations** | ||
| Line 160: | Line 162: | ||
| === Group of users === | === Group of users === | ||
| - | Users can be collected in groups. Let us assume we would like to build a small group of sales representatives, called Team A as shown in [[en:adminmanual:securityguide:ecurityguide:rbsbasics-ch001|Figure: Group of Users Example.]] \\ | + | Users can be collected in groups. Let us assume we would like to build a small group of sales representatives, called Team A as shown in <wrap em>Figure: Group of Users Example.</wrap> |
| **Figure 1.3. Group of Users Example** \\ | **Figure 1.3. Group of Users Example** \\ | ||
| {{ :en:adminmanual:securityguide:sampleusergroup1.png?nolink |}} \\ | {{ :en:adminmanual:securityguide:sampleusergroup1.png?nolink |}} \\ | ||
| - | Person 1 and Person 2 suppose to be the members of this group, so we build a group of users. Each of these Persons is assigned to a role that defines the security settings for the individual user. You may now assign data sets to this group, as shown as an example in [[en:adminmanual:securityguide:ecurityguide:rbsbasics-ch001|Figure: Activity assigned to Group]]. The assignment to this group means, that all members of this group are the owner of this entry.\\ | + | Person 1 and Person 2 suppose to be the members of this group, so we build a group of users. Each of these Persons is assigned to a role that defines the security settings for the individual user. You may now assign data sets to this group, as shown as an example in <wrap em>Figure: Activity assigned to Group</wrap>. The assignment to this group means, that all members of this group are the owner of this entry.\\ |
| **Figure 1.4. Activity assigned to Group** | **Figure 1.4. Activity assigned to Group** | ||
| Line 182: | Line 184: | ||
| === Group of roles === | === Group of roles === | ||
| - | You can also build groups that are based on roles. That might be a helpful function if you do not know the individual users and their task within your company. An example is shown in [[en:adminmanual:securityguide:ecurityguide:rbsbasics-ch001|Figure: Group of Roles Example]].\\ | + | You can also build groups that are based on roles. That might be a helpful function if you do not know the individual users and their task within your company. An example is shown in <wrap em>Figure: Group of Roles Example</wrap> |
| **Figure 1.5. Group of Roles Example** | **Figure 1.5. Group of Roles Example** | ||
| {{ :en:adminmanual:securityguide:sampleusergroup3.png?nolink |}} | {{ :en:adminmanual:securityguide:sampleusergroup3.png?nolink |}} | ||
| - | At this group, all users that have the role "Sales" or "Marketing" are members of this group. If you assign a data entry at the CRM system to this group, all members become the owner of this entry. In [[en:adminmanual:securityguide:ecurityguide:rbsbasics-ch001|Figure: Lead assigned to Group]] you see an example for a lead entry.\\ | + | At this group, all users that have the role "Sales" or "Marketing" are members of this group. If you assign a data entry at the CRM system to this group, all members become the owner of this entry. In <wrap em>Figure: Lead assigned to Group</wrap> you see an example for a lead entry.\\ |
| **Figure 1.6. Lead assigned to Group** | **Figure 1.6. Lead assigned to Group** | ||
| Line 208: | Line 211: | ||
| === Group of roles with subordinates === | === Group of roles with subordinates === | ||
| - | In addition to simple role based groups you may also build groups that include subordinates. That means the users who are assigned to roles which are below a selected role will be included. The following figures illustrate that. Let's assume your company has set up a hierarchical order as shown in [[en:adminmanual:securityguide:ecurityguide:rbsbasics-ch001|Firgure: Hierarchy Example]]. \\ | + | In addition to simple role based groups you may also build groups that include subordinates. That means the users who are assigned to roles which are below a selected role will be included. The following figures illustrate that. Let's assume your company has set up a hierarchical order as shown in <wrap em>Firgure: Hierarchy Example</wrap> |
| **Figure 1.7. Hierarchy Example** | **Figure 1.7. Hierarchy Example** | ||
| {{ :en:adminmanual:securityguide:hierarchiesample.png?nolink |}} \\ | {{ :en:adminmanual:securityguide:hierarchiesample.png?nolink |}} \\ | ||
| - | In this figure, the role "Sales" has a subordinated role "Sales Assistant" and the role "Marketing" is the master of the role "Marketing Assistant". If you create a user group as shown in [[en:adminmanual:securityguide:ecurityguide:rbsbasics-ch001|Figure: Group of Roles with Subordinates]] all users with sales and marketing related roles, including the assistants will become members of this group.\\ | + | In this figure, the role "Sales" has a subordinated role "Sales Assistant" and the role "Marketing" is the master of the role "Marketing Assistant". If you create a user group as shown in <wrap em>Figure: Group of Roles with Subordinates</wrap> all users with sales and marketing related roles, including the assistants will become members of this group.\\ |
| - | ** | + | |
| - | Figure 1.8. Group of Roles with Subordinates Example** | + | **Figure 1.8. Group of Roles with Subordinates Example** |
| {{ :en:adminmanual:securityguide:sampleusergroup4.png?nolink |}} | {{ :en:adminmanual:securityguide:sampleusergroup4.png?nolink |}} | ||
| - | If you assign a CRM data entry to this group all users who are a member of this group will become the owner. Related to the example shown in [[en:adminmanual:securityguide:ecurityguide:rbsbasics-ch001|Figure: Potential assigned to Group]] that means:\\ | + | If you assign a CRM data entry to this group all users who are a member of this group will become the owner. Related to the example shown in <wrap em>Figure: Potential assigned to Group</wrap> that means:\\ |
| * All members of this group are allowed to browse, modify or to delete this entry \\ | * All members of this group are allowed to browse, modify or to delete this entry \\ | ||
| + | |||
| **Figure 1.9. Potential assigned to Group** \\ | **Figure 1.9. Potential assigned to Group** \\ | ||
| Line 244: | Line 249: | ||
| </WRAP> | </WRAP> | ||
| - | === Organisation Wide Sharing Privileges === \\ | + | === Organisation Wide Sharing Privileges === |
| The CRM system allows you to set default privileges that are valid organization-wide. It is the purpose of these privileges to give an administrator tool that allows a fast overall security setting.\\ | The CRM system allows you to set default privileges that are valid organization-wide. It is the purpose of these privileges to give an administrator tool that allows a fast overall security setting.\\ | ||
| - | === Default Organisation Sharing Privileges === \\ | + | === Default Organization Sharing Privileges === |
| Default Organization Sharing Access controls data sharing at the organization level. Global, as well as Custom Access Privileges, are offered. \\ | Default Organization Sharing Access controls data sharing at the organization level. Global, as well as Custom Access Privileges, are offered. \\ | ||
| Line 256: | Line 261: | ||
| </WRAP> | </WRAP> | ||
| - | === Global Access Privileges === \\ | + | === Global Access Privileges === |
| The CRM system comes with default global organization sharing privileges for the most important CRM modules as shown in Figure: Default Global Privilege Settings for Organization. Default Organization Sharing Access controls data sharing at the organization level. \\ | The CRM system comes with default global organization sharing privileges for the most important CRM modules as shown in Figure: Default Global Privilege Settings for Organization. Default Organization Sharing Access controls data sharing at the organization level. \\ | ||
| Line 368: | Line 373: | ||
| {{ :en:adminmanual:securityguide:ofpriviledges.png?nolink |}} \\ | {{ :en:adminmanual:securityguide:ofpriviledges.png?nolink |}} \\ | ||
| - | **Tip** | + | <WRAP center round info 60%> |
| - | Default field access settings include custom fields you may have created before. \\ | + | Default field access settings include custom fields you may have created before. |
| + | </WRAP> | ||
| Default Organization Field Privileges can be defined for the following modules: Leads, Accounts, Contacts, Potentials, Activities, Trouble Tickets, FAQ, Price Books, Purchase Order, Invoice, Notes, Emails, Products, Vendors, Quotes, and Sales Orders. \\ | Default Organization Field Privileges can be defined for the following modules: Leads, Accounts, Contacts, Potentials, Activities, Trouble Tickets, FAQ, Price Books, Purchase Order, Invoice, Notes, Emails, Products, Vendors, Quotes, and Sales Orders. \\ | ||
