Entity Separation & Named Resource Visibility

Great questions — this is a scenario we’ve implemented successfully using standard Planview configuration. Here’s how we’ve approached it:

1. Have you implemented cross‑entity project ownership while masking named resources?

Yes. This is achievable, but it does require intentional setup. In Planview, assignments and requirements naturally display the resource name, so masking needs to be done directly at the resource level.

A common approach is to use a non‑descriptive resource name (for example, a numeric ID or employee number) as the display name. The user account remains correctly associated in the background for time entry and processing, but project users only see the masked identifier.

For resources without user licenses, we’ve used a secure resource attribute to store the actual name. That attribute is restricted by role so only Resource Managers or Administrators can see it, while Project Managers and other users cannot.

2. How do you handle actuals posting where PMs can see effort and cost, but only at the role level?

This works well when resource masking is combined with role‑based rates. With masked resource names and financial rates defined at the role level (rather than the individual level), PMs can view effort and cost rolled up by role without visibility into specific people.

Time is still entered by the actual user, but cost and effort reporting reflects the role‑based configuration. This allows PMs to manage budgets and delivery without needing access to named resources.

3. What Planview configurations or patterns did you use?

We relied entirely on out‑of‑the‑box Planview capabilities, including:

• Resource name masking at the attribute level
• Role‑based rate schedules
• Aggregated capacity and demand views at the role level
• Role‑based security to control access to sensitive resource and financial attributes

No custom development was required — the key was aligning resource data, financial configuration, and security roles consistently.

4. Were there trade‑offs or limitations, especially for PM roles or approvals?

There are some considerations. With masking in place, PMs should not have access to attributes that expose real resource identities, which means attribute‑level security needs to be carefully managed.

This model works best when Resource Managers approve allocations or assignments, while PMs plan and manage work at the role level. If PMs are also responsible for assigning work based on individual availability, they may require additional access, which can reduce the effectiveness of masking.

That said, the overall impact to PMs is usually minimal — it’s primarily a shift from managing by name to managing by role and capacity.

In summary: This approach is fully achievable with standard Planview functionality. Success depends on consistent resource masking, role‑based financial configuration, and disciplined role design. The trade‑off is reduced reliance on named resources, which is often an acceptable and manageable change.

• Hope this helps — happy to go deeper on any part of the setup if useful