In general the less complicated the department structure, the better. Try to keep the department look up table to one level and try to keep the number of departments small. To understand why, let’s take a moment to consider what makes the department field different from other fields.
The main thing that makes the department field different is that it drives certain associations, including the following:
- When creating projects, users can only see Enterprise Project Types with no department or with the same department as that associated with the user.
- A project Enterprise Custom Field that has a department associated with it will only be visible (both in PDPs and in the “Project Information” dialog in Project Professional) for projects associated with that department.
This means that if you have a lot of possible values for the department, each time an enterprise project type (EPT) is created, you need to consider a lot of possible departments to associate the new EPT with. If a new EPT is missing a department value that it should have, then people who should be able to see that EPT when creating projects will not be able to see it. Conversely, if a new EPT includes a value a department that it should not have, then people who should not be able to see that EPT when creating projects will be able to see it.
Also, higher levels in a department look-up table do not inherit the visibility of the lower levels. So if you have a user whose department is “IT.Apps”, he or she will not be able to see EPT associated the “IT.Apps.Support” department.
If there is an anticipated need to capture a hierarchical department structure for reporting purposes, a custom field associated with a lookup table that contains that structure is probably a good idea. If the anticipated need is security based, the RBS field and associated lookup table might be the appropriate mechanism to leverage.