You assign users to a role on a design part in order to allow those users to work on all objects associated with that design part. In this way, roles promote ownership and responsibility for different functional areas of a product.
Joe and Jane are in the Maintenance group. They need control of the design part called Pensions. Jim and Mary, in the Development group, need control of the Bonus design part. You can assign the role of DEVELOPER to both groups, each on their own design part. If the privilege rule for Update Item Content is set as "user has the DEVELOPER role on the design part", Joe and Jane are able to update the items for Pensions, and Jim and Mary can update items for Bonus.
If, in addition, the lifecycle for request type CR has the DEVELOPER role assigned to the ALLOCATED state, the request will go to Joe and Jane’s inboxes for Pensions, and Jim and Mary’s inboxes for Bonus.
When a user has a role on a design part, that user also inherits the role on all subordinate design parts in the design structure, unless a different user is assigned to the same role on a lower design part. In that case, the latter user assumes responsibility for that design part and any design parts below it.
John holds the AUTHOR role for design part e. In this case, John is responsible for e and its subordinate design parts, f and g. Note that only the hierarchical (breakdown) structure of the design parts determines role assignments. Therefore, John does not inherit a role on design part d, which is in a usage relationship with design part f. If someone else gets assigned the AUTHOR role for design part f, then John's responsibility would be limited to e and g. John may also create items on these design parts if AUTHOR is specified as the initial role in the lifecycle for the item types.
Related Topics