Best Practice for Restricting Role-Based ACLs to Specific Lifecycle States

[Santosh_B]

Hello PTC Community,

I’ve configured Role A at the organization level to allow users to read and download content only in release-equivalent lifecycle states. However, I’ve encountered an issue where Role A is inheriting the out-of-the-box (OOTB) ACLs assigned to the Team Member role, which inadvertently grants users access (read and download) to objects in all lifecycle states.

What is the best practice for configuring ACLs so that Role A can only access objects in release-equivalent lifecycle states, even when users are also assigned the Team Member role? Any advice on managing role-based permissions effectively in this scenario would be greatly appreciated.

Thank you in advance!

Best regards,
Santosh 

[tarik.wifak.p]

Note: This is not a customization question!

In order to achieve your use case, we should understand how access control works in Windchill, it is through access control calculation.

Generally speaking, the strong rule will apply.

Please let us know what do you mean by "release-equivalent lifecycle states".

You can start with the following documentation: Article - CS364768 - Access Control Calculation in Windchill PLM (ptc.com)

[Santosh_B]

Thank you for the clarification!

By "release-equivalent lifecycle states," I mean lifecycle states such as Released, Approved, or any custom states that represent a state where the object is considered finalized or ready for general use, as opposed to states like In Work or Under Review where the object is still being developed or validated.

I will review the article you suggested on access control calculation (CS364768) to better understand how ACLs are applied.

My goal is to ensure that users in Role A can only access objects in release-equivalent states. However, the Team Member role seems to override the ACL, granting broader OOTB permissions.

I’d appreciate any specific recommendations or best practices on how to override or fine-tune these permissions so that Role A can have restricted access.

Thanks again for the guidance.

Best regards,

Santosh

[tarik.wifak.p]

@Santosh_B Try to set an absolute deny policy to this role A on the type of object in question for every state no "release-equivalent states".

[Santosh_B]

Thank you for the suggestion!

Before implementing, I wanted to confirm if setting an absolute deny policy for Role A on all non-release-equivalent states is a recommended approach by PTC. Additionally, I want to clarify that Role A should only be able to access Parts, Documents, and CAD Documents, and not any other objects.

Are there any potential implications or considerations I should be aware of when using this method?

Thanks again for your guidance.

Best regards,

Santosh

[tarik.wifak.p]

Try first with only one state and see if it does work.

Absolute deny is a standard access control configuration, and it's used in many use cases.

The forbidden settings in access control are touching unmodifiable domains

What remains is up to your design and approach, the better approach is to think of general access control architecture based on your current implementation and PTC best practices.

see: Article - CS381802 - Best Practices of Access Control Architecture in Windchill PLM (ptc.com) and Article - CS406353 - Optimization of Access Control Architecture in Windchill PDMLink (ptc.com)

[Santosh_B]

Thank you for your suggestions.

I tested the deny and absolute deny configuration, and it works as expected for restricting Role A to only view released objects. However, I also need Role A to access only Parts, Documents, and CAD Documents. Currently, they can still see other objects like Change Tasks and Promotion Requests. While I could manually deny access to these objects, this approach seems tedious and error-prone.

I reviewed the articles provided, but they didn’t offer a clear solution for this specific scenario. Is there a more efficient way to limit access to only certain object types without having to manually configure denies for each additional object? Any guidance on how to streamline this would be greatly appreciated.

Best regards,

Santosh 

[HelesicPetr]

Hi @Santosh_B 

First, ACL knowledge  is really needed, because you can case many troubles to end users.

I would say, use different context template where the team member ACLs are not defined.

or rearrange all ACLs to achieve your needs. Yes it takes a time 😄 

Check what ACL are defined on the TeamMembers pseudo role and deny this rules on your RoleA

or remove the existing ACLs for the pseudo team role add this rules to individual roles that needs that rights. 

It is very complex area how to keep the ACLs rules in the best condition.

PetrH