Best Practices and Recommendations

Depending on the organization of your data and user security, you may have specific requirements for configuring your Primavera Cloud environment. This topic provides a variety of best practices and recommendations for setting up the Primavera Cloud data described in the Functional Differences section. It does not cover the full configuration process. For that information, see Oracle Primavera Cloud Help.

The information below is divided into three main categories: When, Where, and How. Most objects in Primavera Cloud can be configured at any time, at any workspace level, and in the manner preferred by your organization. However, it may be easier or more beneficial to configure some objects in the beginning of your setup, in a specific location, or in a specific manner. The three categories are presented as common questions you should consider when configuring your data. Responses to each question are grouped by the type of data.

When should I configure my data?

Administration: Administrative-level data such as application settings, companies, users, user groups, and integrations can be configured at any time. You should create all necessary global permission sets before adding users so that they are available to be assigned to new users.
Workspaces: You should set up your workspace hierarchy before manually entering or migrating your data so that the data can be placed at the appropriate workspace level. As time goes on, you may need to add new workspace branches and levels to your hierarchy. A new workspace cannot be placed between two existing workspaces. If you believe you may one day need to add a workspace level between existing workspaces, you should add a placeholder workspace that can be used later.
Shared Data: Most shared data can be configured at any time. However, after shared data is assigned to an object, you will not be able to delete it. You must delete any shared data assignments before you can delete the shared data.
Security: User security can be configured at any time. Permission sets and workspace user groups are automatically available to child workspaces and projects, even if the workspace or project is created later. Individual users and user groups do not receive access until they are assigned to a workspace or project.
Projects: Ensure that the workspace hierarchy is adequately built before adding projects to the appropriate workspace. Projects can be manually created or imported at any time. Users with appropriate privileges can move a project from one workspace to another, if required. Moving a project to a different workspace can affect shared data. Some inherited shared data may have to be promoted to the designated workspace before you can move the project. Project-level data can be configured at any time, although there are a few requirements. To migrate project data using integration, the source project in P6 and the destination project in Primavera Cloud must have the same project ID, and the project in P6 must be associated with the correct workspace location from Primavera Cloud. You cannot change the project currency after costs are created in the project.

Where should I configure my data?

Administration: Administrative-level data is configured in the Global Admin app. User groups can be managed in the Global Admin app or at the workspace and project levels. Object permission sets can be managed in the Global Admin app or at the workspace level.
Workspaces: The root, or Company, workspace contains two child workspaces, Production and Non-Production. All other workspaces must be children of Production and Non-Production. Workspace-level configuration data consists of shared data and user security. Both of these are discussed below.
Shared Data: Dictionaries and object defaults should be added at the workspace level where the data needs to be available. All shared data objects have a Sharing Method setting. Shared data set to Automatic will be automatically pushed down to child workspaces. Data that does not need to be automatically pushed down to child workspaces should use the default Manual sharing method. You can later assign manually shared data objects in the child workspaces that need them. Data that is required for the entire organization should be created in the root workspace and use an Automatic sharing method so it is pushed down to all child workspaces. Data only needed by specific branches of the workspace hierarchy or individual workspaces should be created at that particular workspace level. If you are using a placeholder workspace, shared data set to Automatic will be automatically pushed down into the placeholder's child workspaces.
Shared data owned at a higher level reduces the number of places where data needs to be maintained, including renaming, modifying, and deleting. Changes to shared data can only be made in the owning workspace. Changes are automatically pushed down to lower-level workspaces, regardless of the Sharing Method setting. However, higher-level ownership may reduce the specificity of shared data so that it can be used by as many objects as possible. For example, codes owned at a higher level might need to have more generic names and values so they can be available for assignment to a variety of objects. Codes owned at a lower lever can be more specific to the workspaces and projects where they are available, such as a particular industry or departmental workspace or a particular project. Lower-level data ownership may increase an administrator's maintenance responsibilities and lead to an abundance of shared data that is too specific. Consider maintaining shared data that is broader in scope and more applicable to a large section of your hierarchy in higher-level workspaces and shared data that is narrower in scope and specific to a particular section of your hierarchy in lower-level workspaces. If a shared data object should be made available to more workspaces and projects, you can change its ownership to a higher-level workspace. You cannot change an object's owning workspace to a lower level.
Security: It is recommended that workspace user groups and permission sets are created as high in the workspace hierarchy as possible so that they are available to be assigned in all child workspaces and their projects. User groups must be assigned to a particular workspace or project to grant users in the group access to that object. Users should be assigned, directly or to user groups, at the workspace or project where they should gain access. Permission sets that need to be available to more workspaces can be moved to a higher owning workspace. User group ownership cannot be moved.
Resources/Roles: As with shared data, the ownership of resources and roles should be determined by their required availability and areas of applicability. Resource and role ownership in a higher-level workspace dictionary is recommended for resources and roles that will frequently be used and monitored across multiple workspaces and projects, such as high-level managers, placeholder roles, equipment, and materials. However, resources or roles available to too many workspaces or projects could become overallocated, assigned to projects that are inaccessible, or assigned to projects that are inapplicable. For example, a resource may be assigned to more projects than they can realistically work, projects that are outside of their geographic location, or projects that are not related to their area of expertise. To avoid these types of issues, consider constraining the ownership of resources and roles to the lowest workspace level possible. Lower-level ownership ensures resources and roles are more applicable to the workspace where they are located. Consider creating project-level resources and roles if there are people or roles hired for work on a specific project that should not be available for assignment to other projects. However, this approach can lead to more maintenance and resources or roles that are not available to enough areas. If resources and roles should be made more available, you can promote them to a higher-level workspace dictionary. Promoting a resource or role changes its ownership. You cannot move resource or role ownership to a lower level.
If you do not see a particular resource or role at the level you expect, there could be a few reasons. When assigning resources or roles in a higher level to a workspace or project dictionary, you can only choose from resources or roles that are available in the parent workspace. You must assign your desired resource or role to the parent level before you can assign it to your current workspace or project. If a resource or role is at a lower level, promote it to the workspace where it is required. If you are trying to assign a resource or role to an activity, you can only choose from resources or roles that are available in the project dictionary or parent workspace dictionary. If a workspace resource has not been assigned to the project level, assigning it to an activity will make it and any associated roles available at the project level.
Projects: Projects should be added under the appropriate workspace determined by the hierarchical structure. Projects inherit various object defaults and auto numbering settings from the parent workspace, but these settings can be modified per project.

How should I configure my data?

Administration: Configure application settings, companies, and users in the manner preferred by your organization. It is recommended that you assign the Application Administrator user type sparingly, as this provides full access to all application data.
Workspaces: Create a workspace hierarchy that best represents your preferred organization of projects, shared data, and user security. It is recommended that you plan your hierarchy carefully and keep it as simple as possible. This will make it easier to add and maintain your data at the appropriate workspace levels. It is not recommended that you reproduce the Enterprise Project Structure (EPS) from your P6 environment. You may want to structure your workspace hierarchy based on geographic locations, industries, or departments. Choose a model that makes sense for your organization and the projects you will be working on. Consider how shared data and security will be organized in the hierarchy. Some organizations might find it beneficial to organize the workspace hierarchy based on security access. Since security and permissions can be 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.
The Non-Production workspace can be used as a test area before transferring data to Production. This enables you to test different configurations of data to determine which best suits your needs. For example, use Non-Production to test the migration of data from P6 to Primavera Cloud. As sibling workspaces, shared data in Non-Production does not affect shared data in Production. If you do not need a test area in the application, you can rename and repurpose the Production and Non-Production workspace.
Shared Data: The configuration of shared data is mainly dependent on the level of the hierarchy where the data should be available. If certain shared data only applies to specific industries or departments, it should be owned at a workspace level that does not include other industries or departments. If there are currencies, locations, or units of measure that are location-dependent, you may want them owned at a specific geographic workspace level. Remember to set each shared data object's Sharing Method based on whether it should be automatically shared down the workspace hierarchy or manually assigned to specific child workspaces. Proper shared data ownership ensures shared data is only available at the appropriate workspace levels.
Security: It is quicker and more efficient to set up user groups rather than assign users individually, especially if your organization uses the same job roles across projects. When planning user groups, think about the types of users who will all require the same level of access. This might be separate user groups for project managers, schedulers, superintendents, or field workers. Place them at the level of the workspace hierarchy where they should be available. One best practice is to add empty user groups to the root workspace with the permission sets that each group's users will require. Assign the user groups to the workspaces and projects where users will need access, and then add to the group only the users who will be working in that particular workspace or project. This way, all users in a user group will have the same permissions for an object type, but their access is restricted to the specific objects to which they were assigned. A user's assigned permissions are combined, so if a user requires additional privileges not granted by their user group, you can assign the user to the same object that the group is assigned to with the additional privileges they require. You could also add them to another user group that is assigned to the object and offers the required privileges. When planning permissions, consider creating object permission sets that are specific to different user groups. For example, a user group of managers should have privileges to add and delete data while a user group of field workers might only need privileges to add and edit data.
Resources/Roles: If your workspace hierarchy is organized by geographic location, ensure that the resources or roles available in a particular workspace can be physically present to perform their work. If the hierarchy is organized by industry, consider keeping one industry's roles, such as aviation engineers, separate from another industry's roles, such as nuclear engineers. If there are roles that should be available to both industries, create or promote them to a workspace level that will encompass both. Create resources and roles at the project level if they will only work on that project. Associated resources and roles must be owned by the same workspace. Promoting a resource to the parent workspace will automatically promote its associated roles. Before promoting, ensure all of the associated resources and roles should be owned at the higher level.
Projects: Projects should be created to achieve a specific objective. They should be organized according to the structure of your workspace hierarchy. Project-level data is specific to each project, so how you configure the data depends on the project's budget, scope, and timeline.

Last Published Tuesday, May 21, 2024