공유 팀은 역할과 이 역할에 추가된 멤버의 세트로 구성됩니다(컨텍스트 팀에서와 동일함). 공유 팀은 조직 컨텍스트에서 작성되며, 조직 컨텍스트에서 작성되는 여러 응용 프로그램 컨텍스트에 대한 컨텍스트 팀으로 사용될 수 있습니다. 예를 들어 자전거 회사 조직 컨텍스트에서 제품 시연 팀이라는 공유 팀을 작성한 경우, 사용자가 자전거 회사 조직 컨텍스트에서 작업할 때 응용 프로그램 컨텍스트(예: 제품 및 프로젝트)를 작성하면 이 공유 팀을 선택할 수 있습니다. 응용 프로그램 컨텍스트를 작성 중인 사용자가 다른 조직 컨텍스트 멤버인 경우에는 제품 시연 팀을 사용할 수 없습니다. 자세한 내용은 컨텍스트 정보를 참조하십시오.

공유 팀을 작성할 때, 해당 공유 팀을 사용하는 응용 프로그램 컨텍스트 작성 시 공유 팀의 로컬 확장을 허용할지 여부를 설정할 수 있습니다. 공유 팀을 선택한 모든 컨텍스트 팀이 해당 공유 팀만 사용하도록 제한하려면 연관된 응용 프로그램 컨텍스트에서 팀이 로컬로 확장되도록 허용합니다 옵션이 설정되어 있지 않아야 합니다.

응용 프로그램 컨텍스트를 작성할 때 사용 가능한 공유 팀이 없는 경우에는 응용 프로그램 컨텍스트 작성자에게 공유 팀 필드가 표시되지 않으며 작성되는 팀은 로컬 팀입니다. 응용 프로그램 컨텍스트가 작성된 후에는 공유 팀을 추가할 수 없습니다.

공유 팀에 변경 사항이 발생하면 해당 공유 팀을 사용하는 모든 컨텍스트 팀에 변경 내용이 적용됩니다. 예를 들어 공유 팀을 변경한 후에 공유 팀을 사용하는 컨텍스트 팀의 팀 페이지를 새로 고치면 공유 팀에 적용된 변경 사항이 표시됩니다.

다음 단원에서는 공유 팀 역할을 소개하고 시스템 그룹 및 도메인을 사용하여 공유 팀을 관리하는 방법을 설명합니다. 시스템 그룹에 대한 자세한 내용은 "공유 팀에서 참여자 관리" 단원을 참조하고, 도메인에 대한 자세한 내용은 "공유 팀 도메인 관리" 단원을 참조하십시오.

공유 팀에 구성된 초기 역할 설정은 다음과 같습니다.

역할 및 멤버를 로컬 팀에 추가하거나 제거하는 것과 동일한 방법으로 공유 팀에 추가하거나 제거할 수 있습니다. 자세한 내용은 다음 항목을 참조하십시오.

컨텍스트 팀에 공유 팀과 로컬 팀 모두가 포함된 경우, 시스템에서는 컨텍스트 매니저에 대한 시스템 그룹에 공유 팀 관리자 그룹을 멤버로 추가합니다. 공유 팀 관리자 멤버를 식별할 수 있도록 하기 위해서, 컨텍스트 팀이 로컬에서 확장될 때 공유 팀 관리자 역할 및 컨텍스트 매니저 역할이 멤버 테이블에 별개로 유지됩니다.

예를 들어, 자전거 설계 프로젝트에 일반 설계라는 공유 팀이 포함된 컨텍스트 팀이 있다고 가정해 보십시오. Chris Taylor는 일반 설계 공유 팀 관리자 역할의 멤버입니다. Chris Taylor는 자전거 설계 프로젝트에 대한 멤버 테이블에서 공유 팀 관리자 역할 아래에 나타납니다. 하지만 공유 팀 관리자 그룹이 프로젝트 관리자 그룹에 멤버로 추가되어 있으므로 Chris Taylor는 로컬 팀의 프로젝트 관리자 역할에 속한 다른 멤버와 함께 자전거 설계 프로젝트에 대한 프로젝트 관리자 역할을 맡습니다.

위와 비슷한 방식으로, 공유 팀 멤버 및 게스트 역할에 속한 참여자는 로컬 팀 멤버 및 게스트 역할의 멤버도 됩니다. 공유 팀 멤버 및 게스트 그룹은 로컬 팀 멤버 및 게스트 그룹에 멤버로 추가됩니다. 마찬가지로, 로컬 팀에도 소속된 다른 역할을 공유 팀에 추가하면 동일한 이름의 역할에 있는 참여자는 동일한 역할에 속한 것으로 간주됩니다. 로컬 팀 멤버 테이블에는 역할별 멤버 보기에서 특정 역할 아래에 표시되며 공유 팀과 로컬 팀 모두에 속하는 멤버들에 대해 역할이 하나만 표시됩니다.

Windchill PDMLink에서 로컬 팀 컨텍스트 매니저, 조직 관리자, 사이트 관리자, 팀 수정 작업 권한을 부여받은 사용자는 로컬 팀 및 공유 팀 모두의 역할이나 멤버가 포함된 보기를 볼 때 멤버 테이블에 표시되는 소속 열에서 정보를 확인하여 공유 팀에 속하는 역할 및 멤버를 결정할 수 있습니다. 예를 들어, 공유 팀의 설계자 역할에 두 명의 참여자가 지정되고 로컬 팀의 설계자 역할에 한 명의 참여자가 지정된 경우 이 세 참여자는 컨텍스트 팀에서 모두 설계자입니다. 세 참여자는 모두 역할별 멤버 보기의 멤버 테이블에서 설계자 역할 아래에 표시됩니다. 테이블의 소속 열을 보면 공유 팀 소속 멤버와 로컬 팀 소속 멤버를 구분할 수 있습니다.

Pro/INTRALINK에서 로컬 팀 컨텍스트 매니저, 조직 관리자 또는 사이트 관리자는 보기에 로컬 팀 및 공유 팀 모두의 역할이나 멤버가 포함되어 있을 때 멤버 테이블에 표시되는 소속 열에서 정보를 확인하여 공유 팀에 속하는 역할 및 멤버를 결정할 수 있습니다. 예를 들어, 공유 팀의 설계자 역할에 두 명의 참여자가 지정되고 로컬 팀의 설계자 역할에 한 명의 참여자가 지정된 경우 이 세 참여자는 컨텍스트 팀에서 모두 설계자입니다. 세 참여자는 모두 역할별 멤버 보기의 멤버 테이블에서 설계자 역할 아래에 표시됩니다. 테이블의 소속 열을 보면 공유 팀 소속 멤버와 로컬 팀 소속 멤버를 구분할 수 있습니다.

공유 팀만 있고 로컬 팀이 없는 경우에는 멤버 테이블에 추가로 표시되는 역할이 없습니다. 또한 컨텍스트 매니저 역할은 팀에서 설정되지 않습니다. 대신 공유 팀 관리자 역할이 컨텍스트에 대한 컨텍스트 매니저로 사용됩니다. 공유 팀 관리자 역할에 설정된 액세스 제어 정책 규칙은 컨텍스트의 모든 객체에 대한 전체 제어(모두) 권한을 역할의 참여자에게 제공합니다.

공유 팀이 작성되면 이와 이름이 동일한 관리 도메인이 생성됩니다. 이 공유 팀 도메인의 상위 도메인은 공유 팀을 작성한 조직 컨텍스트의 Default 도메인입니다. 예를 들어 자전거 회사 조직 컨텍스트에서 제품 시연 팀이라는 공유 팀을 작성한 경우, 정책 관리 유틸리티에서 사용할 수 있는 도메인 구조는 다음과 같습니다.

공유 팀을 사용하는 응용 프로그램 컨텍스트가 작성되면 응용 프로그램 컨텍스트의 Default 도메인이 공유 팀 도메인 아래에 작성됩니다. 자세한 내용은 컨텍스트 및 도메인 계층 개요를 참조하십시오.

예를 들어, 제품 시연 팀을 사용하는 고성능 자전거 제품 컨텍스트가 작성되는 경우, 정책 관리 유틸리티에서 사용할 수 있는 도메인 구조는 다음과 같습니다.

이 도메인 구조를 활용하여 공유 팀 도메인에 고유한 정책 액세스 제어 규칙 세트를 작성할 수 있습니다. 그러면 이 규칙 세트는 해당 공유 팀을 사용하는 모든 응용 프로그램 컨텍스트에 의해 상속됩니다.