Background: User Management: Groups
Effective group design is important to the overall administration of SD Elements. Ensure you read the background on the Groups feature to understand how it works first. You should understand the group design before a large deployment of SD Elements.
In general, most organizations already have some sort of organizational hierarchy reflected in existing systems, such as Active Directory (AD) or a different Lightweight Directory Access Protocol (LDAP) repository. In these cases, you likely want to emulate the same sort of design in SD Elements. Keep in mind that SD Elements does not currently support LDAP group synchronization, so you will have to manually create these groups in the system and maintain group membership.
In order to understand group design, consider the fictional example Acme Corp. Acme has lines of business (LoBs): Retail, Commercial, and Industrial. Each LoB has anywhere between 2 and 10 divisions. Each division is made up one or more groups, and software development is usually done by individual groups.
So the hierarchy is follows: Acme -> LoB -> Division -> Group
For each of the levels in the hierarchy, you will want to create an administrative group. At the lowest level, you will have all the members of the team:
- Acme Admins: Can view and edit all projects
- Retail Admins: Can view and edit all retail projects, can’t view other LoB projects
- Retail Division 1 Admins: Can view and edit all retail division 1 projects, can’t view other LoB or division projects
- Retail Division 1 Group 1: Can view and edit all retail division 1 group 1 projects (i.e. the entire development team of Group 1), can’t view other Lob, division, or group projects
SD Elements supports group nesting, so in order to ensure that the Acme Admins can view all projects, the Acme Admin group should be included as a member of the Retail Admins, Commercial Admins, and Industrial Admins group. Likewise, “Retail Admins” should be part of the “Retail Division 1 Admins” group and so on. In this way, Acme Admins will be implicitly be part of every group.
The key point to remember in group design is that as you go down the organizational hierarchy, you have fewer permissions. So, for example, there is no “Acme” group that everybody in the company can view. Instead, the top level “Acme Admin” group can access anything.
Once you have designed the groups hierarchy, you should consider which roles and permissions each group needs by default.
The final step is to actually add members to each group. You should first understand which users will actually use SD Elements. If there isn't an organization-wide mandate to use the product then you may not have permission to add certain people to the system. You may wish to pre-populate the group membership with all people you expect to be users. Alternatively, you may wait until you start on-boarding projects and add members to groups just before their first use.
- Is there an existing organizational structure modeled in Active Directory or another directory system in the organization?
- If no such structure exists, is there an organizational chart available from which to model the hierarchy?