User Categories and Hierarchies

Groups, roles, and associations let you identify a set of users who require the same accesses. A person's position in an organization or role hierarchy also controls access.

The baseline behavior uses credentials (the combination of app role, collaborative space (previously referred to as projects), and organizations) to define access. You only need to define or manage user categories if you do not use the baseline behavior, such as when creating custom apps.

This page discusses:

User Categories

The shared accesses defined by user categories can be to certain types of business objects as defined in policies or other administrative objects, such as specific attributes, forms, relationships, or programs as defined in rules.

When you create a group or role, you assign specific users to the category. When you create an association, you assign groups and roles to the association. A user can belong to any number of groups, roles, and associations.

If many users need access to a type of business object, consider creating a user category to represent the set of users. You can include the user category in policy or rule definitions to define access. For example, suppose you create a user category, such as a group, and assign 25 users to the group. Then you assign the group to a state in the policy and grant the group full access. All 25 users within that group will have full access to objects governed by the policy.

This table lists the user categories that can be defined.

Categories Description
Groups A collection of people who work on a common project, have a common history, or share a set of functional skills. In a group, people of many different talents and abilities may act in different jobs or roles. For example, an engineering group might include managerial and clerical personnel who are key to its operation. A documentation group might include a graphic artist and printer/typesetter in addition to writers. While the groups are centered on the functions of engineering or documentation, they include other people who are important for group performance.

For more information, see group Command.

Roles A collection of people who have a common job type: Engineer, Supervisor, Purchasing Agent, Forms Adjuster, and so on. A role can be defined as either a project (collaborative space) or organization. The ability to create projects and organizations is important for applications that use access models based on these user categories. Projects and organizations are still of the type role user category and have the same parameters as roles. Projects and organizations can be used in user access definitions for policy states and rules. A person can be assigned directly to a role, project, or organization.

For more information, see role Command.

Associations A collection of groups, roles, or other associations. The members of the user categories have some of the same access requirements based on a combination of the roles users play in the groups in which they belong. For example, perhaps a notification that an object has reached a certain state should be sent to all Managers in an Engineering department.

For more information, see association Command.

Groups, roles, and associations can be used in these ways to identify a set of users:

  • As recipients of IconMail sent manually or automatically via notification or routing of an object as defined in its policy.
  • As the designated signature signers in the lifecycle of an object.
  • In the user access definitions in the states of a policy.
  • As object owners, through reassign.

There are just a few differences between the three categories:

  • Users can grant their accesses to objects to persons and groups, but not to roles and associations.
  • Persons can be assigned directly to groups and roles. Groups and roles make up associations. So a person belongs to an association by virtue of belonging to a group or role that is assigned to the association.
  • Groups and roles can be hierarchical. A group or role can have multiple parents and multiple child groups/roles. A role defined as a project or organization can only have ancestors of the same role definition: a role defined as project or a role defined as an organization respectively. Associations are not hierarchical.

Answer these questions to determine who should be in which group:

  • Does the user require access to the business objects?
  • How much access is required for the user to do their job?
  • When is access needed?

For example, suppose that a company is manufacturing a new product called product ABC. Depending on where the project is in its lifecycle, different people will work on the project, require access for different tasks, or use information related to it:

Lifecycle User Category Description
Planning ABC Product Manager association An association made up of persons who belong to the Product Manager role and the Product ABC group. The Product Managers create the schedule and project plan and write specifications.
Product ABC group All persons involved with the product. This group will view the schedules and plans prepared by the Product Managers.
Review Quality Assurance role Persons who test products for the company. These people view the specifications and write test plans.
Product ABC group Review the specifications prepared by the Product Managers.
ABC Product Manager association Review and update items as needed.
Release Implementation group Engineers, clerical help, a financial manager, and a supervisor help implement the product after it is sold. This group includes some individuals from the user categories assigned to the first two states. For these individuals, you can change the amount of access they have to reflect their changing tasks.
ABC Marketing association Persons who belong to both the Marketing Manager role and to the Product ABC group. Advertise the product and manage order processing.

Group Hierarchy

You can define a hierarchy of groups so that access privileges available to a higher group (parent group) are available to all of the groups below it (subgroups or child groups).

In this example, the Field Service group is the parent of the Field Support, Technical Documentation Services, and In-House Customer Support groups. The Technical Documentation Services group is also a parent of the Documentation and Training groups.

Role Hierarchy

Roles can also be hierarchical. In this example, the Assembly Manager role is the parent of the Apprentices and Master Assembler roles. The Master Assembler parent of the Component Assembler and Subassembly Assembler roles.

A child group or role can have more than one parent. Child groups and roles with more than on parent inherit privileges from each of the parents.

Baseline Roles and Product Structure Design Policies

Prior to the V6R2013 release, the baseline roles VPLMViewer, VPLMCreator, and VPLMProjectLeader roles were not hierarchically structured, even though the associated access rights were cumulative. In other words, the VPLMCreator role had the same access rights as the VPLMViewer role, plus some more, and the VPLMProjectLeader role had the same access rights as the VPLMCreator role (and thus VPLMView), plus some more.

This resulted in a significant redundancy in policy and rule access definitions, as can be seen in the following example: 

policy "VPLM_SMB"
   state "IN_WORK"
      user "VPLMViewer"
         read,show,checkout
         filter "(organization.ancestor match
                    context.user.assignment[$CHECKEDUSTER].org) &&
                 (project ==
                    context.user.assignment[$CHECKEDUSER.project"
      user "VPLMCreator"
         read,show,create,delete,modify,promote,demote,grant,revoke,
         changename,changeowner,changetype,checkin,checkout,lock,
         unlock,fromconnect,fromdisconnect,toconnect,todisconnect
         filter "(organization.ancestor match
                    context.user.assignment[$CHECKEDUSER].org) &&
                 (project ==
					               context.user.assignment[$CHECKEDUSER].project)"
      user "VPLMProjectLeader"
         read,show,create,delete,modify,promote,demote,grant,revoke,
         changename,changeowner,changetype,checkin,checkout,lock,
         unlock,fromconnect,fromdisconnect,toconnect,todisconnect
         filter "(organization.ancestor match
                    context.user.assignment[$CHECKEDUSER].org) &&
                 (project ==
                    context.user.assignment[$CHECKEDUSER].project)"

In V6R2013 release, these roles were reorganized hierarchically to leverage the native inheritance role mechanism of the 3DEXPERIENCE Platform so only those accesses that are specific to each role need to be specified: 

policy "VPLM_SMB"
   state "IN_WORK"
      user "VPLMViewer"
         read,show,checkout
         filter "(organization.ancestor match
                    context.user.assignment[$CHECKEDUSTER].org) &&
                 (project ==
                    context.user.assignment[$CHECKEDUSER.project"
      user "VPLMCreator"
         delete,modify,promote,demote,grant,revoke,changename,
         changeowner,changetype,checkin,checkout,lock,unlock,
         fromconnect,fromdisconnect,toconnect,todisconnect
         filter "(organization.ancestor match
                    context.user.assignment[$CHECKEDUSER].org) &&
                 (project ==
					               context.user.assignment[$CHECKEDUSER].project)"

The read,show, and checkout accesses are no longer specified in the access definition of the VPLMCreator role since they are inherited from VPLMViewer. The access definition of the VPLMProjectLeader role was completely removed, as it was exactly the same as VPLMCreator.