Working with Workspace Hierarchies
Workspaces in Primavera Cloud are arranged in a hierarchy that allows shared data and security to either be set at a high level and pushed down to child workspaces or configured individually at the workspace or project level. The top level of the workspace hierarchy consists of the root, or Company, workspace, and the root workspace has two child workspaces, Production and Non-Production. Each workspace, except the root workspace, can have additional child workspaces and projects with custom data sets and security. You can customize your workspace hierarchy with as many workspaces as necessary to suit the needs of your organization.
Tips for Creating Workspace Hierarchies
You should always plan ahead when creating your workspace hierarchy. Here are a few things to keep in mind when creating your workspace hierarchy in Primavera Cloud:
- After a workspace is created, it can be moved within the same workspace hierarchy. After shared data is added, you can delete the workspace. When deleting a workspace that contains data, the system will move all content to the parent workspace and workspace currency will be recalculated. For more information on workspace currency, see Workspace Currency Overview.
- Workspaces cannot be added between two workspaces, which means that you cannot add another level to the workspace hierarchy between two already existing levels. For example, if you add "Workspace A" to the "Production" workspace, then you will not be able to add a workspace between them. If you believe that you may one day want to add a level between existing workspaces, then you can add placeholder workspaces to ensure that that level can be utilized later. If you set the sharing method for shared data in the placeholder workspace to Automatic, then all shared data will be automatically pushed down to the child workspace.
- Some organizations might find it beneficial to organize the workspace hierarchy based on security access. Since security and permissions are defined at the workspace level, users who require the same security access should be added to the same workspace. If users from different departments in your organization require the same access to projects, then you should create the workspace hierarchy based on security needs instead of department or industry.
- Users can choose to use the Non-Production workspace as a test area before transferring data to the Production workspace. However, the Production and Non-Production workspaces can also be repurposed and renamed if you do not believe your organization will need a test area in the application.
- Certain shared data, including security data, can be pushed down to child workspaces manually or automatically. Global shared data should be configured as high up in the workspace hierarchy as it will be needed and set it to automatically share to all child workspaces. For example, if your organization has a list of codes that apply to all projects in all workspaces, you should configure those codes in the root workspace so that all workspaces can inherit them.
Workspace Hierarchy Example
The following is an example workspace hierarchy in Primavera Cloud using a placeholder workspace. In this example, the company utilizes the Non-Production workspace and has set up workspaces for Development, Testing, and Integration so that they can figure out the best configuration to suit their organization's needs. For example, they are using the Integration workspace to test integrations with P6 and Microsoft Project. They use these workspaces to make final changes before transferring data to the Production workspaces that users will be working in.
For the workspaces that will live under Production, the company has decided to organize its shared data and security access by location and currently has projects based in New York City and Los Angeles. The company believes that it may one day have projects in other locations, and they would need to differentiate the location further in the workspace hierarchy to better organize shared data. Therefore, when this company was first establishing its workspace hierarchy, it left a placeholder workspace between the Production workspace and the workspaces for the New York City and Los Angeles-based projects. They can now add workspaces at that level as child workspaces to Production.
In this example, the company branches out to Japan and decides to add countries as parent workspaces to cities because each country will have its own unique shared data. Because they created their workspace hierarchy with a placeholder workspace, they are able to add another child workspace to the Production workspace to designate another country (Japan) and change the name of the placeholder workspace to United States. The company is now able to incorporate countries into their workspace hierarchy.
