Profiles allow the site and organization administrator to dynamically control which actions are visible to a user, group of users, or users in an organization by associating that information with a profile. A profile represents a typical category of user within a company and is based on the roles and privileges associated with that particular user category. Profiles are not an access control mechanism; they are a user interface control mechanism.

By defining a profile that exposes only the necessary functionality and information needed by a user, it creates a focused and simplified user interface, reducing confusion by eliminating areas of the user interface that could be distracting. This capability allows customers to ensure that a supplier, customer, or group of users is presented with a streamlined and focused set of information and actions.

The profiles that are associated with a user, group, or an organization control which actions and areas of the user interface are visible by those users. A user could have permission to edit an object based on an object domain-based policy, but not have visibility to that edit action for the object because this action is not included in the user’s profile.

The primary goal in defining profiles is simply to hide the user interface elements (for example, actions, tabs, and attributes) that a user has no need for, or interest in the functionality. If a user does not have rights to an object or an action through access control rules, a profile will not add visibility to actions or information that is restricted by underlying access control policies. That is, you cannot grant a user visibility through a profile to an action or an area of the user interface for which that user does not already have access control rights. For example, a user could have access control permissions to the New Part action in the system, but through a profile, that action can be hidden from the user and not visible in the user interface. On the other hand, if the user does not have access control permissions to the New Part action, that action cannot be made visible to the user via a profile. It is the combination of a user being granted permission to an object or action via access control policies, and the profile granting visibility to those actions and objects, that will enable a user to see and perform an action.

Each user or group can be associated with one or more profiles. If the profiles are the same type, then the least restrictive settings for visibility are assumed. For example, if a user is associated with two standard profiles where one standard profile hides an action, but the other standard profile allows visibility of that action, then the user will see the action in the user interface. If one standard profile allows read only visibility to an attribute, but another standard profile gives full rights to that same attribute, then the user will have full rights to the attribute. However, if the user is a member of a standard profile and a license profile and one grants visibility to an action while the other does not, then the action is not visible. If the user is a member of a standard profile and a license profile and both grant visibility to an action, then the user will be able to see that action.

Changes that are made to profiles take effect after the user subsequently logs into the system.

When a profile is associated or disassociated from a user or group, no change in access permissions is implied or enforced.

For more information about profiles, see the following topics: