LabKey Server can be structured in a wide variety of ways to suit individual research needs. This topic will help you decide how to structure your site using the available tools and functional building blocks. For background information on how a LabKey Server site is structured, see Project and Folder Basics.

Things to Consider When Setting Up a Project

Consider the following factors when deciding how to provision your work into projects and folders.

Projects and Folders

Should I structure my work inside of one project, or many?

• Single Project Strategy. In most cases, one project, with one layer of subfolders underneath is sufficient. Using this pattern, you configure permissions on the subfolders, granting focused access to the outside audience/group using them, while granting broader access to the project as a whole for admins and your team. If you plan to build views that look across data stored in different folders, it is generally best to keep this data in folders under the same project. The "folder filter" option for grid views (see Query Scope: Filter by Folder) lets you show data from child folders as long as they are stored in the same project.
• Multiple Project Strategy. Alternatively, you can set up separate projects for each outside group (for example, a lab, an institution, or a specific consortia). This keeps resources more cleanly partitioned between groups, but you will not be able to query data across all of the projects as easily, since it is generally more convenient to query data when it is all in the same project. That said, you can create queries that span multiple projects using custom SQL queries that pull data from each of the projects you want to include (for details see Cross-Folder Queries). Or you can use linked schemas to query data in another project (see Linked Schemas and Tables).

User Interface

• If you wish different areas of your site to have distinct looks (colors, logos, etc.), make these areas separate projects. Folders do not have independent settings for look-and-feel.
• Avoid using separate folders just for navigation or presenting multiple user pages. Use tabs or wiki pages within one folder if you don't need the folder's security features.

Shared Resources and Inheritance

• Many resources (such as assay designs and database schema) located at the project level are available by inheritance in that project's subfolders, reducing duplication and promoting data standardization.
• Use the "Shared" project, a project created by default on all sites, for global, site-wide resources.

Flexibility

• Site structure is not written in stone. You can relocate any folder, moving it to a new location in the folder hierarchy, either to another folder or another project. Note that you cannot convert a project in a folder or a folder into a project using the drag-and-drop functionality; but you can use export and re-import to promote a folder into a project or demote a project into a folder.
• Use caution when moving folders to a different project, as the some important aspects of the folder are generally not carried across projects. For example, security configuration and assay data dependent on project-level assay designs are not carried over when moving across projects.
• LabKey Server lets you create subfolders of arbitrary depth and complexity. But deep folder hierarchies tend to be harder to understand and maintain than shallow ones. One or two levels of folders below the project is sufficient for most applications.

Security and Permissions

• As a general rule, you should structure permissions around groups, not individual users. This helps ensure that you have consistent and clear security policies. Granting roles (= access levels) to individual users one at a time, makes it difficult to get a general picture of which sorts of users have which sorts of access, and makes it difficult to implement larger scale changes to your security policies. Before going live, design and test security configurations by impersonating groups, instead of individual users. Impersonation lets you see LabKey Server through the eyes of different groups, giving you a preview of your security configurations. See the security tutorial for details on impersonation.
• You should decide which groups have which levels of access before you populate those groups with individual users. Working with unpopulated groups gives you a safe way to test your permissions before you go live with your data.
• Make as few groups as possible to achieve your security goals. The more groups you have, the more complex your policies will be, which often results in confusing and counter-intuitive results.
• By default, folders are configured to inherit the security settings of their parent project. You can override this inheritance to control access to particular content using finer-grained permissions settings for folders within the project. For example, you may set up relatively restrictive security settings on a project as a whole, but selected folders within it may be configured to have less restrictive settings, or vice versa, the project may have relatively open access, but folders within it may be relatively closed and restricted.
• Configure LDAP authentication to link with your institutional directory server. Contact LabKey If if you need help configuring LDAP or importing users from an existing LDAP system.
• Take advantage of nested groups. Individual users can populate groups, and so can other groups. Use the overarching group to provide shallow, general access; use the child groups to provide deeper, specific access.

Related Topics

• Project and Folder Basics
• Tutorial: Security - Security basics.
• Look and Feel Settings - Select look and feel options for your site and projects.
• Linked Schemas and Tables - Provide access to selected data (schemas), without providing access to the entire folder.
• LabKey URLs - URLs in LabKey Server reflect paths/locations in the container hierarchy.