Windchill Profiles best practices and Documentation

[LawrenceS]

I am fairly new to customized company Standard Profiles (and license profiles), but have been learning how important they are, and how many issues arise, esp. in WC12.  

• Does anyone know if and where there is the documentation for the different categories that are listed?
  • Some of them are self-explanatory, while others are not, especially if I am not familiar with newer functionality, or the extent of the things it can affect, or if it is just ambiguous. 
  • E.g. "Remove" (which remove?), "Use Creo Data Management & Visualization WGMs", "Move Choice", "Windchill PDF Collaboration", "override name", etc
  • Note I did look in the WC Help, searched some of the terms (with and without quotes) and didn't find documentation on these categories.
    Move Choice
• Based on your experience and knowledge, what are some best practices working with Profiles in WC?  Brainstorming some examples
  • Do you give full access when in doubt then remove as necessary?
  • Profile conflicts?
  • By what do you group profiles (job function, department, functionality, etc)?
  • Permissions control (Profiles, groups, teams, team admin, UAC/Policy Admin, etc)?

[PravinShinde]

Hi @LawrenceS ,

Please refer below windchill help center link topics which help you to understand the use of Standard and License profiles and information about each profile:

1. Out-of-the-Box Profiles
2. Managing Standard Profiles
3. knowledge base Article: CS297225  This article helps to check the Action visibility and required license profile.
4. Licensing Hub

The above link helps you to understand licensing in more detail.

Hope this helps you.

Thanks,

Pravin Shinde

[LawrenceS]

Thanks for your response and the references.  Which questions do these posts answer?  Even the terms that I mentioned don't appear to be in any of the documentation that you sent?

I'm also still hoping someone can help with best/good practices for working with the different methods of controlling permissions.

[TomU · Accepted solution]

A few comments.

1.)  As a general rule, standard profiles turn off visibility for actions the user already has rights to perform.

• Standard profiles do not prevent actions from being completed, they just prevent the button and/or command from being displayed in the user interface.
• If a user has a link or shortcut to some particular action, removing that command from their standard profile will not prevent them from completing that action.
• Standard profiles will not turn on an action (make the command/button visible) if something else is preventing it (either a license profile or a custom rule in policy administration.)

2.)  To figure out which actions control which buttons, it's helpful to create a couple of test profiles - one with everything turned on and another with everything turned off.  You will quickly discover that there are many commands and buttons not controlled by the standard profiles at all (they are always visible.)

3.)  As mentioned in one of the linked help pages, profiles add together.  If you don't want someone to have access to something, then *all* of the profiles they are associated with must have that thing turned off.  For this reason I tend to build profiles that only turn on the things I want each group of users to have.  If a user is in more than one group, then they are allowed to access the sum of all associated profiles.

4.)  License profiles override standard profiles.  If a license profile does not allow display of a certain action, adding that action to a standard profile won't turn it on.

5.)  Probably not relevant to what you're doing, but both license profiles and standard profiles draw from the same list of command and actions.  This is super annoying if you want to add extra actions to the standard profiles because the same actions instantly become limited to the license profiles as well, even if licensing isn't supposed to have anything to do with your custom actions.

6.)  As far as how to assign them, I've chosen to associate each license profile with certain ORG and site level groups.  Anyone who is associated with any of those groups is automatically associated with the corresponding profile(s).  I never manually assign a profile to someone.  This same approach is used for both license profiles and standard profiles.

[LawrenceS]

Thank you for the detail loaded and helpful reply!

6.) I like the idea of the groups, and I chose to do the License profiles this way by creating specific license groups.  However, it sounds like you have gone a step further and associated multiple profiles with groups.  At least with the License groups we were cautioned against not assigning more than one of the same type of License group (e.g. View&Print and Base) to the same person because then it would reserve/pull licenses for both.  Is this what you are doing, or do you only do that for the custom profiles where you add more and more functionality depending on their role?

[TomU]

No, only one profile per license group.  I add each user to multiple ORG level groups in order to grant them access to different roles, but their top level Active Directory group is only ever associated with one license group, one license profile, and one standard profile.  Any other limitations to their functionality are role and context specific ,and handled by the access control rules for each context.

Obviously larger organizations are going to have more complex licensing requirements, but this is what we have:

[LawrenceS]

I'm going to have to think about this some more.  Thanks for the additional explanation and the helpful picture!