Lorsqu'un contexte d'application est créé, vous pouvez choisir d'inclure une équipe partagée et, dans ce cas, le rôle de responsable d'équipe partagée a une signification particulière dans l'équipe associée au contexte. Par défaut, les membres du rôle de responsable d'équipe partagée bénéficient de la permission Contrôle total (tout) sur tous les objets, tous états confondus, qui se trouvent dans le contexte dans lequel l'équipe partagée est utilisée.

Les équipes locales utilisent le rôle de gestionnaire d'équipe associée au contexte correspondant (tel que le rôle de chef de projet ou le rôle de gestionnaire des structures produit) pour les membres qui gèrent le contexte par la suite. Si l'équipe partagée peut être étendue localement, l'équipe locale a toujours un rôle de gestionnaire d'équipe associée au contexte correspondant. Par exemple, le tableau Membres d'un contexte de projet avec une équipe locale occupe le rôle de Chef de projet et ce rôle détermine qui gère le contexte. Le groupe système du rôle de Responsable d'équipe partagée est ajouté en tant que membre du groupe système de gestionnaires d'équipe associée au contexte qui a été créé. Cela signifie que les membres du rôle de Responsable d'équipe partagée héritent des règles de contrôle d'accès définies pour le gestionnaire de l'équipe associée au contexte, et ce, même si elles sont conservées séparément dans le tableau Membres de l'équipe associée au contexte.

S'il n'existe aucune équipe locale (ce qui signifie que l'équipe partagée sélectionnée n'a pas été étendue localement lors de la création du contexte), il n'y a aucun gestionnaire pour l'équipe locale associée au contexte. Par exemple, le tableau Membres d'un contexte de projet sans équipe locale n'occupe pas le rôle de Chef de projet. Par conséquent, les membres du rôle de Responsable d'équipe partagée sont, par défaut, les membres gestionnaires du contexte.