Difference between revisions of "Access Control FAQs"
imported>Aeric |
imported>Aeric m (Text replace - 'â' to '"') Â |
||
| (One intermediate revision by the same user not shown) | |||
| Line 5: | Line 5: | ||
=== Why not give everyone administrator rights? === | === Why not give everyone administrator rights? === | ||
You can if trust that the team you're working with needs to see, edit, or delete all sensitive data and you want them to establish passwords and setup new users whenever they want for everyone on the team. In most cases, however, it is best to give one or two members of your team administration rights. You can always change roles of a team to allow greater permission. However, it's a good practice to limit them initially and then selectively expose more features later when you start having | You can if trust that the team you're working with needs to see, edit, or delete all sensitive data and you want them to establish passwords and setup new users whenever they want for everyone on the team. In most cases, however, it is best to give one or two members of your team administration rights. You can always change roles of a team to allow greater permission. However, it's a good practice to limit them initially and then selectively expose more features later when you start having "power users" who need more control. This lowers your risk in people wanting to change too much too soon and adversely affecting others' operations. | ||
=== Why can't I delete a user? === | === Why can't I delete a user? === | ||
| Line 13: | Line 13: | ||
=== What if I have multiple roles? === | === What if I have multiple roles? === | ||
When a person is assigned multiple roles, they have a super-set of both. In other words, you have the | When a person is assigned multiple roles, they have a super-set of both. In other words, you have the "best of both worlds." This additive nature of role permissions is important to factor when adding roles to individual users. | ||
=== Who should decide teams, roles, and rights? === | === Who should decide teams, roles, and rights? === | ||
Latest revision as of 19:46, 31 July 2013
Why not just assign rights by user?
Assigning rights by each individual may work for some organizations, particularly if they are small or highly focused. But in slightly larger organizations, change can be more prevalent. What if that person leaves? You would have to re-assign new individual rights to that person. Or what if you have two or more people who need access to the same level of information? You would have to assign rights one at a time. Roles provide a fast and predictable way to create permission policies.
Why not give everyone administrator rights?
You can if trust that the team you're working with needs to see, edit, or delete all sensitive data and you want them to establish passwords and setup new users whenever they want for everyone on the team. In most cases, however, it is best to give one or two members of your team administration rights. You can always change roles of a team to allow greater permission. However, it's a good practice to limit them initially and then selectively expose more features later when you start having "power users" who need more control. This lowers your risk in people wanting to change too much too soon and adversely affecting others' operations.
Why can't I delete a user?
Because the application is so integrated with the idea of a person owning or acting on data, the concept of deleting a user completely would unravel the fabric of activities around data. Instead, you can make a user inactive from the User option in Setup, thus preserving the history of a user's activities, but making it impossible for that user to do anything ever again. You can perform mass updates to data (for example, changing ownership), but past activities associated with a user remain in tact.
What if I have multiple roles?
When a person is assigned multiple roles, they have a super-set of both. In other words, you have the "best of both worlds." This additive nature of role permissions is important to factor when adding roles to individual users.
Who should decide teams, roles, and rights?
In many cases, organizations are reluctant to create teams, roles, and rights. Often times, they leave it to their IT department to sort out. Or if they don't have one, it's a free-for-all. It's important to take an hour to work out who needs certain information. Or you can use the built-in roles to start and tweak them as you need to. The most successful implementation of access controls is almost always that which comes from the management's determination.