Project Structure - Best practices?

#1

Hi,

We are in the early stages in getting Dundas up and running for our organization. I’m wondering how best to use projects to best address our organizational structure. We have three different agencies under our organization. Two are smaller and the third has the bulk of our departments. Example

  • Agency1
    *program1
    *program2
    *program3

  • Agency2
    *program4

  • Agency3
    *dept1
    *subdept
    *program4
    *dept2
    *subdept
    *program5
    *dept3
    *subdept
    *program6

Should we add projects on the agency, department or program level? In most cases we don’t want programs to be able to access other program data, but we would want to have a way for our exec team to view all departments.

Does the project structure need to match our organizational chart, or should we just make a project for each program?

#2

I’ve seen multiple solutions out there and can’t say there is only way to organize your projects but I would recommend to following:

  • There is no need to match your organization chart but you should try and follow a structure that will not only be easy for you to manage but most importantly will be easy for the users to understand and follow in order to find their content. Now since you do have the option to hide elements from users in case they don’t have permissions to those elements that will greatly simplify their experience so I would recommend hiding projects and objects that users shouldn’t access unless you want them to know about this object and ask for permission to access it (that can be the goal at times). There are multiple tips about how to manage your users navigation under this blog.

  • From the administration point of view, it’s usually easier to manage permission at the project level so if users from a certain program shouldn’t access other programs I would recommend having a project per program. Note that doesn’t mean that you need to duplicate objects. For example, if multiple programs relay on the same database, I would create a single data connector for all of those programs and place it under the “Global” project so it can be accessed in all projects under the shared folder.

You can also refer to this documentation to better understand the administration options around managing projects.

2 Likes
Multi-tenancy (Dashboard selection from accounts & users)
#3

Thank you! This makes sense. I think I will move forward using program level.

Thanks again!

#4

If you are going to have the same dashboard for all programs but you want to make it so that they only see their data use Security Hierarchies.

I have a dashboard that is used by many different groups with in the company. I have just the one dashboard but in the data set is who that data belongs to and there is a security Hierarchy on it.
Then the different people from the different groups all get permission to that set of data when they view that dashboard.

This way you do not have to make the same dashboard for each group (filtering for just their data) over and over.

I have my projects set up not by company division, but by usage/Types of dashboards (HR, Financial, Budget, and so on).

https://www.dundas.com/Support/learning/videos-tutorials/hierarchies-time-dimensions/creating-custom-categorical-hierarchies

https://www.dundas.com/Support/learning/documentation/analyze-data/how-to/how-to-create-a-custom-user-hierarchy

https://www.dundas.com/support/support-center/support-articles/administration/set-security-hierarchy-using-the-hierarchy-filter

Let me know if that makes sense and/or helps.