FAQ: 지원자의 세그먼트화된 시큐리티

제약조건이 있는 지원자는 Workday에서 조직과 연결된 지원자입니다.

채용된 경우: 채용된 조직과 연결됩니다.
퇴직시: Workday는 이들을 채용된 조직과 연결합니다.
채용 진행중: Workday가 이들을 채용 대상 조직과 연결합니다.
진행 중인 채용 오퍼/고용계약: Workday가 이를 채용에 사용된 인력충원요청의 조직과 연결합니다.

제약조건이 없는 지원자는 Workday에서 조직과 연결되지 않은 지원자입니다. 예: 승인된 사용자가 지원자

생성 태스크를 사용하여 생성하는 지원자

지원자에 대한 접근 권한이 있는 인증된 사용자는 제약조건이 없는 모든 지원자를 표시할 수 있습니다.

제약조건이 없는 시큐리티 역할을 가진 근무자(예: 회사 전체에서 근무하는 HR 관리자)는 개선사항을 옵트인한 후에 지원자에 대한 접근 권한이 변경되지 않습니다. 제약조건이 없는 시큐리티 역할을 통해 제약조건이 있는 지원자(조직과 관계없음)와 제약조건이 없는 지원자를 모두 조회할 수 있습니다.

이전에는 제약조건이 있는 시큐리티 그룹(예: 조직 내에서 근무하는 매니저)이 있는 근무자가 접근 권한이 있는 조직 내 지원자와 제약조건이 없는 지원자만 조회할 수 있었습니다. 이제 고객은 Workday에서 제약조건이 없는 지원자에 액세스할 수 있는 근무자를 구성할 수 있습니다.

Workday 어플리케이션 전반에서 이 개선된 지원자 시큐리티 로직에 대한 몇 가지 예외가 있을 수 있으며, 비즈니스 로직에는 이러한 개선의 이점이 없습니다. 예:

백그라운드 체크

,

임시고용직 계약

,

직원 입사발령

,

오퍼

.

이러한 경우, 중복 지원자 프로필 생성을 완화하고 채용 및 채용 프로세스를 효과적으로 지원하려면 인증된 사용자가 테넌트의 모든 지원자(퇴직자 지원자 프로필 포함)에 액세스할 수 있어야 합니다. 이 개선사항으로 인해 잠재적으로 환경이 저하될 수 있습니다. 예: 인증된 사용자가 지원자를 생성할 수 있지만 채용할 수는 없습니다. 이를 방지하기 위해 Workday는 고객이 이 개선사항을 옵트인하는지 여부와 관계없이 태스크에 대한 접근 권한을 제어하는 기존 시큐리티를 유지관리합니다. 사용자에게 태스크 및 Pre-Hire 시큐리티 도메인에 대한 접근 권한이 있는 경우 이러한 태스크 및 프로세스 내에서 제약조건이 있는 지원자와 제약조건이 없는 지원자 모두에 계속 액세스할 수 있습니다.

중복 관리 기능은 새로 생성된 지원자(신규 지원을 통해)가 기존 지원자의 주요 조건과 일치할 때 발생합니다. Workday는 채용 프로세스를 통해 생성된 지원자를 제약조건이 있는 지원자로 간주합니다.

채용담당자에게 제약조건이 있는 시큐리티 권한이 있는 경우 기존 프로세스가 유지관리됩니다. 채용담당자에게 레거시 지원자 프로필(기존 프로세스)의 조직에 대한 적절한 접근 권한이 있으면 중복 관리 기능이 예상대로 작동합니다.
채용담당자에게 제약조건이 있는 시큐리티 권한이 있고 레거시 지원자 프로필의 조직에 대한 접근 권한이 없는 경우 중복 관리 기능이 작동하지 않을 수 있습니다. 그러나 이는 기존 지원자 프로필에 대한 접근 권한과 관련된 기존의 제한사항이 됩니다.
채용담당자에게 제약조건이 없는 시큐리티 권한이 있는 경우 중복 관리에 부정적인 영향이 없다는 가정 하에 모든 조직과 연결된 지원자를 볼 수 있으며 조직은 표시하지 않을 수 있습니다.

권한이 있는 사용자가 이 기능을 옵트인한 후 독립형

지원자 생성

태스크에 액세스하면 아래 나열된 필수 도메인에 액세스할 수 없는 경우 생성한 지원자에 액세스할 수 없게 됩니다.

직원 입사발령

태스크 또는 채용 프로세스를 사용하여 지원자를 채용하려고 하면 평소처럼 프로세스에 액세스하여 완료할 수 있습니다. 사용자가 기존 지원자와 이름 및 국가가 동일한 신규 지원자를 생성하면 Workday는 해당 시큐리티 구성과 관계없이 '지원자가 이미 있음' 예외를 트리거합니다.

권장사항:

제약조건이 있는 기존 시큐리티 액세스 권한이 유지되도록 하려면 원래 시큐리티 그룹을 그대로 유지해야 합니다.
옵트인하면 다음 태스크에서 세그먼트 기반 시큐리티 구성이 동일해야 합니다.
지원자 생성
지원자 편집
지원자 조회

이러한 태스크에서 세그먼트 구성이 불일치하면 예상치 못한 동작이 발생할 수 있습니다. 예: 사용자가 지원자를 생성할 수 있지만 프로필에 대한 편집 권한은 상실됩니다.

이 개선사항을 올바르게 구현하려면 조직의 요구사항에 따라 다음 도메인을 업데이트하는 것이 좋습니다.

Manage: 지원자 경비보고서
지원자 데이터 관리(사용자 기반 그룹만 해당)
지원자 프로세스 관리
지원자 프로세스 관리: 지원자 고려
지원자 프로세스 관리: 지원자 인터뷰 입력
지원자 프로세스 관리: 채용 자격 상태 코멘트
지원자 관리 프로세스: 지원자 관리
지원자 프로세스 관리: 지원자 자격
지원자 프로세스 관리: 지원자 조회
지원자 프로세스 관리: 지원자 인터뷰 조회
지원자 프로세스 관리: 근무자 채용 자격
오퍼/고용계약: 단체협약
오퍼/고용계약: 직원 계약
오퍼/고용계약: 통보기간
오퍼/고용계약: 수습기간
Pre-Hire Data: Employment Agreement
Pre-Hire Data: Business Title
Pre-Hire Data: End Date
지원자 데이터: 예정 주간 근무시간
Pre-Hire Data: Start Date and Location
지원자 데이터: 기간제 근무
지원자 데이터: 이름 및 연락처 정보
지원자 데이터: 이름
지원자 데이터: 연락처 정보
조직별 지원자 통계
지원자 개인 데이터
지원자 개인 데이터: 연령/혼인 상태
지원자 개인 데이터: 인종/장애/종교/출생국
지원자 개인 데이터: 성별
지원자 개인 데이터: ID 정보
지원자 개인 데이터: 건강검진
지원자 개인 데이터: 병역/시민권/정치/국적
지원자 개인 데이터: 개인정보
Pre-Hire Personal Data: Sexual Orientation & Gender Identity
Pre-Hire Personal Data: Social Benefits Locality
지원자 개인 데이터: 세부내용이 있는 웹서비스
지원자 프로세스 개발
지원자 프로세스: 인력충원요청 일괄 액션
지원자: 스킬/근무경험
리포트: 인력충원요청 및 포지션
Reports: Manager(지원자)
리포트: 오픈 포지션
설정: 지원자 프로세스

다음 도메인은 제약조건이 없는 시큐리티 그룹용이며 영향을 받지 않습니다.

지원자 데이터 관리: 지원자 삭제
지원자 데이터 관리: 지원자를 삭제 대상으로 표시
지원자 데이터: 백그라운드 체크 현황
검색: 비공개 이메일 주소로 지원자

예. 이 기능을 옵트인한 경우 비즈니스 프로세스 시큐리티 정책을 업데이트하는 것이 좋습니다.

제약조건이 있는 역할을 사용하여 웹서비스 요청을 제출하는 경우, 위에서 설명한 대로 제약조건이 없는 지원자에 대한 접근 권한이 웹서비스 보안을 설정하는 도메인에서 구성되어야 합니다. 제약조건이 없는 역할을 사용하여 웹서비스를 제출하는 경우에는 업데이트가 필요하지 않습니다.