Direct Answer: What Are Private Plans in OnePlan?

A private plan in OnePlan is a plan whose information is available only to the users and teams included in the plan’s Shared With access. Users who are not granted access generally cannot find or view the plan or its underlying information. Some features, such as resource planning, work assignments, timesheets, reporting, and integrations, must still interact with private plans, so in those areas access may be restricted or identifying information may be masked.

What This Article Covers: Private Plans

This article explains how private plans behave throughout OnePlan, which scenarios require extra consideration, and what to review before using private plans for sensitive information.

What you will understand After reading this article, you will understand how private plan access works, how it affects features across OnePlan, and where information can still be exposed outside the plan’s direct access controls.

Who This Article Is For: Private Plans

This article is intended for:

Plan Owners who need to restrict access to sensitive plan information.
Administrators who decide which plan types support private plans and who manage integrations and external reports built on OnePlan data.
Portfolio Managers and Resource Managers who need to understand why some plans appear masked or are missing from their views.
New OnePlan users looking to understand private plans at a high level.

This article explains concepts and context. For step-by-step instructions, see the related How-To articles in the What to Do Next: Private Plans section below.

Why This Matters: Private Plans

Private plans provide an additional level of access control for sensitive plan information, such as confidential initiatives, restructuring, or executive projects. Understanding where private plans are enforced, masked, or not enforced helps you protect sensitive information and avoid unexpected exposure.

Overview

Private Plans provide an additional level of access control for sensitive plan information.

When a plan is private, most plan information is only available to users and teams included in the plan’s Shared With access. Users who are not granted access generally cannot find or view the plan or its underlying information.

Some features must continue to interact with Private Plans to support processes such as resource planning, work assignments, timesheets, reporting, and integrations. In these cases, access may be restricted or identifying information may be masked.

The following sections describe how to enable Private Plans, how Private Plans behave throughout the system, and considerations when leveraging private plans.

How To Enable Private Plans

Private Plans are enabled in two steps. The feature must first be enabled for the applicable Plan Type, after which a Plan Owner can make an individual Plan private.

Plan Type level enablement

Private Plans can be enabled for any Plan Type through its Security settings.

Once Private Plans are enabled for a Plan Type, the option to make a Plan private becomes available within Shared With for Plans of that type.

Enabling the feature at the Plan Type level does not automatically make existing Plans private. It makes the option available for Plan Owners to manage on individual Plans. —

Enable Private for a Specific Plan

For a Plan Type where Private Plans are enabled, a Plan Owner can make an individual Plan private from Shared With.

When the Plan Owner enables the Private Plan option, they are prompted to confirm the change. Once confirmed, the Plan becomes private and access is restricted according to the Private Plan behaviors described in this article.
*Note that users with access to a private plan that have Global Edit All Plans will not have permissions limited through Plan level access. This means that if a Global Edit All Plans user is on a Private Plan Team, they have Owner access by default to any plan they have access to.

Users who should retain access to the Plan should be included in the Plan’s Shared With access.

How Private Plans Affect System Features

General System-Level Access

Private Plan access takes precedence over general system permissions.

Permissions such as View All Plans, Edit All Plans, and Administrative access do not necessarily provide access to the contents of a Private Plan.

The behavior may vary depending on the feature being used, as described below.

Resource Plan

Resource Managers can continue to see resource demand associated with a Private Plan when necessary for resource planning.

If the Resource Manager does not have access to the Private Plan:

The plan name and additional plan information are hidden.
The Plan ID is displayed in place of the plan name.
Existing demand can be visible, but cannot be edited or replaced.
New assignments cannot be created for the Private Plan.
The Resource Manager cannot navigate to or access the Plan Details.

Allowing a Resource Manager to contribute

If a Resource Manager needs to actively contribute to resource planning for the plan, add the Resource Manager to the plan’s Shared With access. Their normal plan information and planning capabilities will then be available based on their permissions.

If resource planning is required but even limited visibility into the Private Plan is undesirable, consider using Public/Private resource plan entries where appropriate.

Plans and Plan Relationships

Private Plans may still participate in plan hierarchies and lookup relationships.

When a user does not have access to a related Private Plan:

The Plan ID is displayed instead of the plan name in related plan fields, tables, and applicable rollup cost types.
The relationship does not grant access to the Private Plan.
The Private Plan cannot be found when the user attempts to create a new relationship to a plan they cannot access.

This allows existing relationships to remain intact without exposing the Private Plan’s identifying information.

Inherited Permissions in Plan Hierarchies

Private Plans do not inherit access from parent plans.

When a plan is made private:

Any users who previously received access through inheritance from a parent plan are removed.
Changes to the parent plan’s Shared With access are not inherited by the Private Plan.
Users added to the parent plan’s Shared With access are not automatically granted access to the Private Plan.
Access to the Private Plan must be granted directly through its own Shared With configuration.

If the Private Plan is later made public again, permission inheritance is restored and the plan will once again inherit access through its plan hierarchy.

Plan Reorganize

Private Plans can be reorganized to another Plan Type as long as the destination Plan Type supports Private Plans.

When reorganizing a Private Plan:

If the destination Plan Type supports Private Plans, the Plan Type can be changed and the plan remains private.
If the destination Plan Type does not support Private Plans, the Plan Type cannot be changed while the plan is private.
To reorganize to a Plan Type that does not support Private Plans, the plan must first be made public. The Plan Type can then be changed.

Recommendation: Before reorganizing a Private Plan, confirm that the destination Plan Type supports Private Plans. If it does not, consider the impact of making the plan public before proceeding.

My Work

Users assigned to work items within a Private Plan can continue to see their assignments in My Work when they have Plan My Work Only or higher permissions.

Resource Managers or delegates accessing work on behalf of the assigned user will only see masked information for Private Plans they cannot access.

This prevents the additional plan and work item information from being exposed while still allowing the assigned user’s work to be represented.

Timesheets

Private Plans continue to support normal timesheet processes for users who are assigned work and have access to the plan.

Users can:

Find applicable work.
Add time.
Submit timesheets.
Route timesheets through the configured approval process.

If a timesheet approver does not have access to the Private Plan, the timesheet can still be reviewed, but the underlying information is masked. This includes:

The Plan ID instead of the plan name.
Masked Work Item information.
No additional Plan or Work Item details.

The approver can still approve or reject the timesheet.

For particularly sensitive plans, Plans and Work Items can also be closed to timesheet entry when the standard timesheet process should not be used.

Dashboards

Dashboards respect Private Plan access.

Users who do not have access to a Private Plan will not normally see that plan within dashboard data.

When information about a Private Plan is referenced through relationship or lookup data, identifying information is masked and the Plan ID is displayed instead of the plan name.

Notifications and Automations

Plan and Work Item notifications respect Private Plan access.

Before notifications are sent, Private Plan access is checked. Recipients who do not have access to the Private Plan are excluded from the notification.

This applies to:

System-generated notifications.
Automation-generated notifications.

This helps prevent Plan and Work Item information from being distributed through notifications to users who otherwise cannot access the Private Plan.

Important Considerations

Private Plans restrict access within the application, but some features can distribute or maintain information outside of the Private Plan’s direct access controls.

These scenarios should be considered when working with sensitive plan information.

Automations

Automations continue to run for Private Plans. All applicable automation triggers and actions can operate on a Private Plan, so existing automations should be reviewed when enabling Private Plans.

Depending on how an automation is configured, it may:

Update or edit Plan data.
Update Plan permissions or access.
Create a new Plan based on the Private Plan.
Reorganize the Private Plan.
Trigger configured Power Automate flows.

Recommendation: Review automations that may run against sensitive plans, particularly those that modify permissions, create Plans, reorganize Plans, or initiate external Power Automate flows.

Backup and Restore

Private Plans continue to be included in system backups.

Making a plan private does not exclude its information from backup processes. Private Plan data remains included so that it can be recovered if restoration is required.

This is necessary to maintain complete backups and avoid gaps in an organization’s disaster recovery and data protection processes.

Important: Private Plan access is intended to control access to plan information during normal use. It does not prevent the plan’s data from being captured as part of system backup and recovery processes.

Work Plan and Schedule Connections

Existing schedule relationships require special consideration.

If a plan is made private after its schedule has already been connected to another plan’s schedule or included as a subplan, information from the Private Plan may already exist within the connected schedule.

Changing the plan to private does not automatically remove information that has already been shared through those schedule relationships.

If users within the connected schedules should no longer have access to this information, the applicable schedule connections should be reviewed and removed.

Recommendation: When possible, determine whether a plan should be private when the plan is created, before establishing external schedule or subplan connections.

Plan Team Assignments

Resource Teams can be added to Private Plans in the same way they are added to other plans.

Members of the Resource Team receive access based on the permissions granted through the team assignment.

However, Resource Team membership may be managed outside of the Private Plan. As team membership changes, the users receiving access to the Private Plan may also change.

Recommendation: Use Resource Team assignments carefully for sensitive Private Plans and periodically review the membership of teams that have been granted access.

OData Reporting

Private Plan restrictions do not automatically prevent data from being included in OData datasets.

Depending on the dataset configuration, reporting data may include:

General information about Private Plans.
Data from plan-specific tables.
Other information included in the configured dataset.

Once this information is exposed through reporting, access is determined by the reporting solution and its permissions.

Recommendation: Review OData dataset configurations and exclude Private Plans where the information should not be available through reporting.

External Integrations

Private Plans can continue to exchange information through configured external integrations.

Integrations may send or receive Private Plan information unless filtering or other restrictions are explicitly configured for the integration.

Once information is transferred to an external system, access to that information is controlled by the permissions and security model of the external system.

Recommendation: Review integrations that process sensitive plan information and configure appropriate filters where Private Plans should be excluded.

Microsoft Teams and SharePoint

Microsoft Teams and SharePoint integrations use permissions that can also be managed within those external systems.

Making a plan private does not automatically change permissions that have already been granted to content within Teams or SharePoint.

Once content is available through those systems, access is governed by the permissions configured there.

Recommendation: For sensitive Private Plans, review the associated Teams and SharePoint permissions in addition to the plan’s Shared With access.

Before Using Private Plans

For plans containing sensitive information, consider the following before enabling or configuring the plan:

Plan access: Confirm that the appropriate users and teams are included in Shared With.
Inherited access: Review users who currently receive access through a parent Plan. Inherited access is removed when the Plan becomes private.
Resource planning: Determine whether Resource Managers require full access or should only encounter masked demand.
Timesheets: Consider whether assigned users and approvers need to process time against the plan.
Automations: Review automations that can modify Plan data or permissions, create or reorganize Plans, or trigger Power Automate flows.
Schedule relationships: Review external schedules and subplan connections.
Resource Teams: Understand who manages membership of any Resource Teams receiving access.
OData: Review datasets that could expose Private Plan information.
Integrations: Determine whether external integrations should exclude Private Plans.
Teams and SharePoint: Review access separately within the connected Microsoft environment.

Important: Private Plans are designed to restrict access to plan information within the application. They should not be treated as a mechanism for revoking information that has already been distributed to external systems, reports, connected schedules, or externally managed repositories.

Frequently Asked Questions: Private Plans

Q: What is a private plan in OnePlan? A: In OnePlan, a private plan is a plan whose information is available only to the users and teams included in the plan’s Shared With access. Users who are not granted access generally cannot find or view the plan or its underlying information.

Q: Does View All Plans or Administrative access let me see a private plan in OnePlan? A: In OnePlan, private plan access takes precedence over general system permissions. View All Plans, Edit All Plans, and Administrative access do not necessarily provide access to the contents of a private plan.

Q: What do users without access see for a private plan in OnePlan? A: In OnePlan, users without access generally cannot find or view the plan. Where a feature must still reference the plan, such as resource demand, plan relationships, timesheet approvals, or dashboard lookups, the Plan ID is displayed instead of the plan name and other details are masked.

Q: Can people still submit and approve timesheets for a private plan in OnePlan? A: Yes. In OnePlan, assigned users with access can find work, add time, and submit timesheets. An approver without access can still approve or reject the timesheet, but the plan and work item information is masked.

Q: Are private plans hidden in OData, integrations, Teams, and SharePoint? A: Not automatically. In OnePlan, private plan restrictions apply within the application. OData datasets and integrations can include private plan information unless you configure filters, and permissions in Microsoft Teams and SharePoint are managed in those systems.

Q: What happens if I make a plan private after connecting its schedule to another plan in OnePlan? A: In OnePlan, information that was already shared through schedule connections or subplan relationships is not automatically removed. Review and remove the applicable schedule connections if connected users should no longer have access.

What to Do Next: Private Plans

Get started with step-by-step instructions:

Learn about related topics:

Private Plans in OnePlan - Overview