Skip to main content
B
BrianToussaint19-Tanzanite
19-Tanzanite
August 26, 2025
Question

Profiles and Configure Actions

  • August 26, 2025
  • 3 replies
  • 681 views
I am using Windchill PDMLink Release 12.1 and Datecode with CPS 12.1.2.8

Is it better to use Profiles or configure actions for roles to hide actions? What are the advantages or disadvantages to each? What is the bare minimum that needs to be on in a profile to see Products and Libraries? Is there any way to get rid of some of the OOTB tabs?

    3 replies

    avillanueva
    23-Emerald I
    avillanueva23-Emerald I
    23-Emerald I
    August 26, 2025

    I think you have two distinct questions there. As far as hiding actions, profiles would be the easiest to do if you can pigeonhole your users to distinct profiles. While it can make sense, I find that users are not static, sometimes they morph to want to do functions that are now prohibited by profile and this is were its gets complicated. Were you talking about modifying the action model to hide actions or creating your own filter logic as an option other than profiles? Unless you have some unqiue business logic or 100% no need for the action, I suggest avoiding that level of customization. 

     

    As far as tabs, I am sure there is a way to get rid of a tab. Which ones did you have in mind?

    B
    BrianToussaint19-TanzaniteAuthor
    19-Tanzanite
    August 26, 2025

    I was wanting to just hide actions like Reassign Tasks, Accept Tasks, Decline Tasks or items in the action menu like Supersede or other stuff that really is just for admins at my company for example.

     

    For the tabs, let's say I have a user from accounting doing a task in our Change Notice process.  I don't mind them seeing the object and generalities, but I don't want all these tabs:

     

    BrianToussaint_0-1756233673504.png

     

    C
    cgautier18-Opal
    18-Opal
    September 9, 2025

    Hello BrianToussaint,

    Do you observe there are admin specific actions available to normal users ?

    KR,

    Charles.

    B
    BrianToussaint19-TanzaniteAuthor
    19-Tanzanite
    September 9, 2025

    Hello Charles,

    No, there are not admin specific actions.  There are two reasons for looking into this.

     

    1. Users can go into a Change Process and change the user in a role that doesn't belong, bypassing the ability to control it in the Set Up Participant tab.
    2. I want to make a cleaner look for non-engineering users that we are bringing in for our CN process.

    Thanks,

    Brian

    C
    cgautier18-Opal
    18-Opal
    September 22, 2025

    Hello Brian, did you check https://www.ptc.com/en/support/article/CS356528 ?

    joe_morton
    18-Opal
    joe_morton18-Opal
    18-Opal
    September 22, 2025

    I don't like either option. We've used both, with limited scope. 

     

    As avillanueva said, Profiles become problematic when a user has 1 role in one workstream, but then a different role some place else. Profiles hide functions, so we've had it come up quite often when a user now needs a function that was hidden, and the Profile assigned to them no longer works for them.

     

    Configure Actions for Roles works better in that it's context-specific. I don't like it because it's very hard to track and maintain. When a user doesn't have access to something they need, you have to remember to check this also (in addition to licensing and Profiles). 

     

    I've kind of given up on simplifying user UI for now. 

      P
      plmcore14-Alexandrite
      14-Alexandrite
      September 22, 2025

      I completely agree with you. The current implementation is very confusing and we also faced the issue

       

      If you are an admin and if they add you to certain group and you indirectly become a member of certain role, your admin actions will disappear. It is very hard to identify the issue

       

      Configure actions for Role is specific to context and it is a hard to track and maintain if you do not have good business administration in place

      Terms & ConditionsCookie settingsAccessibility statement