Profiles
Tabs shown (Default On, Default Off, Hidden)
IP restrictions (Enterprise+)
Object-level security
Field-level security
Login hours
Apex/VF pages accessible
Console layout
Selectable applications (sales, call center, etc.)
Administrative & General User permissions (modify all data, run apex, approve contracts, etc.)
A profile is a group/collection of settings and permissions that define what a user can do in salesforce. A profile controls “Object permissions, Field permissions, User permissions, Tab settings, App settings, Apex class access, Visualforce page access, Page layouts, Record Types, Login hours & Login IP ranges.
You can define profiles by user’s job function. For example: System Administrator, Developer, Sales Representative.
A profile can be assigned to many users, but user can be assigned single profile at a time.
Types of profiles in salesforce
1. Standard profiles: By default salesforce provide below standard profiles. We cannot delete standard profiles.
Read Only, Standard User, Marketing User, Contract Manager, Solution Manager & System Administrator.
Each of these standard one includes a default set of permissions for all of the standard objects available on the platform.
2. Custom Profiles: Custom profiles defined by us. They can be deleted if there are no users assigned with that particular one.
Permission Sets
Permission set is also very similar to profile. Whatever you can manage at profiles (Like Object permissions, Field Permissions, User permissions, Tab settings, App settings, Apex class permission, and visualforce permission) the same you can manage here also. But the main difference between these two is that user can have only one profile and can have multiple permission sets at time.
So we can define profiles to grant minimum permissions and settings that every type of user needs, then we can use permission set to grant additional access.
Examples:
1. We have many users in our organization with some fundamental job functions. We can assign all of them with one profile that grants them all access to do their job. But some set of people are working on special apps or some special functionality, for this type of special users we can create permission sets and can be assigned to them.
2. Some users need some temporary access to specific set of fields and objects we can create permission set with those object & field access and we can assign that specific users.
Roles
Roles are a principal element in sharing rules. Users should be grouped into roles based upon their need for access to data- how they fit into the role hierarchy. Creating a role for each title is not required. Roles are accessed throughout the application, and are particularly important for reporting. For instance, if you have two groups “Outside Sales” and “Inside Sales” you can run comparative reports to both roles.
Build a Role Hierarchy
Manage Users –> Roles
Roles report to another role. It is a one-to-many hierarchical relationship.
Role Hierarchies
A role hierarchy controls level of visibility that users have to an organization data. By defining role hierarchies we can share access to records. Users assigned to roles near the top of hierarchies like (CEO, executives and other higher level roles) get to access the data of all users who fall directly below them in hierarchy.
Role hierarchies enable following behaviors.
A manager will always have access to the same data as his or her employees, regardless of the org-wide default settings. For custom objects, you can override this behavior by deselecting the Grant Access Using Hierarchies check box. However, we want our role hierarchy to apply to all of our custom objects, so leave the check boxes selected.
Users who tend to need access to the same types of records can be grouped together—we’ll use these groups later when we talk about sharing rules.
What is the difference between Public Groups and Queues?
Queue and groups are both are same, which will hold the group of users, but in working environment according to functionality we need to decide which one to use.
Suppose in the case of Lead Assignment, scenario like “Each user should be assigned to at least one lead and also each should be assigned to equal number of leads.”
This means that user needs to handle assigned lead individually and all users in organization should be assigned with the same number of leads. In this case we can define users in organization as a Queue and assign the users one by one to Queue and assign users in the Queue in same number using round robin lead assignment. Thus we can achieve the above scenario.
Suppose you need to Share some of the information in your organization among some users, then we can define a Group, assign users to it and then we can share information or we assign some work to the group. Here this is Group effort.
Queue is a feature available to salesforce.com users that allows you to integrate prospect assignments with your current salesforce.com workflow. Rather than assigning to a specific user, you can choose to assign leads to a salesforce.com queue and then use your CRM workflow or manual method of distributing leads to sales representatives.
Profiles are primarily used to control the permissions for a user. Manage permission and settings for users.
Tabs shown (Default On, Default Off, Hidden)
IP restrictions (Enterprise+)
Object-level security
Field-level security
Login hours
Apex/VF pages accessible
Console layout
Selectable applications (sales, call center, etc.)
Administrative & General User permissions (modify all data, run apex, approve contracts, etc.)
A profile is a group/collection of settings and permissions that define what a user can do in salesforce. A profile controls “Object permissions, Field permissions, User permissions, Tab settings, App settings, Apex class access, Visualforce page access, Page layouts, Record Types, Login hours & Login IP ranges.
You can define profiles by user’s job function. For example: System Administrator, Developer, Sales Representative.
A profile can be assigned to many users, but user can be assigned single profile at a time.
Types of profiles in salesforce
1. Standard profiles: By default salesforce provide below standard profiles. We cannot delete standard profiles.
Read Only, Standard User, Marketing User, Contract Manager, Solution Manager & System Administrator.
Each of these standard one includes a default set of permissions for all of the standard objects available on the platform.
2. Custom Profiles: Custom profiles defined by us. They can be deleted if there are no users assigned with that particular one.
Permission Sets
Permission set is also very similar to profile. Whatever you can manage at profiles (Like Object permissions, Field Permissions, User permissions, Tab settings, App settings, Apex class permission, and visualforce permission) the same you can manage here also. But the main difference between these two is that user can have only one profile and can have multiple permission sets at time.
So we can define profiles to grant minimum permissions and settings that every type of user needs, then we can use permission set to grant additional access.
Examples:
1. We have many users in our organization with some fundamental job functions. We can assign all of them with one profile that grants them all access to do their job. But some set of people are working on special apps or some special functionality, for this type of special users we can create permission sets and can be assigned to them.
2. Some users need some temporary access to specific set of fields and objects we can create permission set with those object & field access and we can assign that specific users.
Roles
Roles are a principal element in sharing rules. Users should be grouped into roles based upon their need for access to data- how they fit into the role hierarchy. Creating a role for each title is not required. Roles are accessed throughout the application, and are particularly important for reporting. For instance, if you have two groups “Outside Sales” and “Inside Sales” you can run comparative reports to both roles.
Build a Role Hierarchy
Manage Users –> Roles
Roles report to another role. It is a one-to-many hierarchical relationship.
Role Hierarchies
A role hierarchy controls level of visibility that users have to an organization data. By defining role hierarchies we can share access to records. Users assigned to roles near the top of hierarchies like (CEO, executives and other higher level roles) get to access the data of all users who fall directly below them in hierarchy.
Role hierarchies enable following behaviors.
A manager will always have access to the same data as his or her employees, regardless of the org-wide default settings. For custom objects, you can override this behavior by deselecting the Grant Access Using Hierarchies check box. However, we want our role hierarchy to apply to all of our custom objects, so leave the check boxes selected.
Users who tend to need access to the same types of records can be grouped together—we’ll use these groups later when we talk about sharing rules.
What is the difference between Public Groups and Queues?
Queue and groups are both are same, which will hold the group of users, but in working environment according to functionality we need to decide which one to use.
Suppose in the case of Lead Assignment, scenario like “Each user should be assigned to at least one lead and also each should be assigned to equal number of leads.”
This means that user needs to handle assigned lead individually and all users in organization should be assigned with the same number of leads. In this case we can define users in organization as a Queue and assign the users one by one to Queue and assign users in the Queue in same number using round robin lead assignment. Thus we can achieve the above scenario.
Suppose you need to Share some of the information in your organization among some users, then we can define a Group, assign users to it and then we can share information or we assign some work to the group. Here this is Group effort.
Queue is a feature available to salesforce.com users that allows you to integrate prospect assignments with your current salesforce.com workflow. Rather than assigning to a specific user, you can choose to assign leads to a salesforce.com queue and then use your CRM workflow or manual method of distributing leads to sales representatives.
No comments:
Post a Comment