People Goal 7 - Part 2: Identify roles

Document created by Kedar on Feb 2, 2015Last modified by mark_baum on May 12, 2015
Version 8Show Document
  • View in full screen mode



In the introduction we emphasized the importance of creating unique accounts for each user, but designing and implementing robust security goes well beyond login credentials. In order to protect against accidental damage by users, you need to control who can change specific data and under what conditions. Furthermore, if some of the information in your solution is sensitive, you need to decide who is permitted to interact with it and who is not.

Generally, these decisions can be applied to groups of people rather than individuals. The groups are identified by looking at the sorts of tasks each user performs in the system. Those people with similar responsibilities are all assigned the same role.

Your organizational chart can help too. People with similar positions are likely to perform similar tasks in your solution, and people at different levels in the organizational hierarchy are likely to have different levels of access.

In this section, you’ll identify the roles relevant to your solution. Here are the roles that we identified for the example solution:

  • The developer, who needs to create and maintain the solution, including adding and deleting tables,  fields, and relationships.

  • The sales team manager, who needs to run reports and export data from the solution, and who also needs to view, edit, and delete records in the main (Contacts) and secondary (Activities) tables.

  • The salespeople, who need to view and edit contact data, but who don’t need access to reports. They also might cause accidental damage if they were permitted to delete contact records.

  • The sales director, who wants weekly updates on the sales team’s performance.

To simplify the initial development effort, you may decide that some roles will have no interaction with the solution at all. In the case of the example solution, we decided that the sales director would get his updates from the sales team manager, at least during the initial period when the solution went into production. After we had collected enough updates to analyze, we would look for patterns in them and decide what aspects might be automated.


Identify the roles that users will take when using your solution. For the purposes of this training, try to limit yourself to three or four roles at the most.


  1. Review the hierarchy of positions in your organization.

  2. Identify the different people who are going to use your solution and their position within that hierarchy.

  3. For each of those people, describe what they need to do in the solution.

  4. Think about what data they should be able to access (view, edit, create, or delete records).

  5. Think about the specific actions they should be permitted to perform (such as printing, exporting data, or writing their own scripts).

  6. Look for patterns within at your descriptions.

  7. For those people who need to do the same things, group them together into a single role.