Summary

Add support for multiple Functional Communities.

The main requirement here is that the recruitement/HR teams for different functional communities have independent access to their own processes and pools of talent. That means:

• Every Pool belongs to a single Community
• Every talent request is directed to a single community, depending on what kind of talent the seeker is looking for
• roles which create posters, publish posters, and evaluate applications, should be limited to posters within their communities.
• roles which respond to requests and head-hunt talent should only see requests and talent approved within their communities
• of course, one user could have the same role in multiple communities

Additionally, since this will require changes to our existing roles an permissions, we plan to make some other updates to the Process Operator role at the same time. Team-based roles have not proven very useful to the DCM Recruitment Team, so we will make the Process Operator a process-specific role instead of a team-specific one.

Details

Changes to Models

• addition of a Community model. For now, will hold little-to-no metadata.
• Processes associated with a Community instead of a Team
• removal of Team model
• Talent Requests must be associated with a Community

Changes to Roles

Platform Admin

• can create and edit Functional Communities
• can assign Community Manager Leads (and other roles)

Community Admin (formerly Community Manager)

• specific to a Community
• can publish Processes in their Community
• can amend published posters in their community
• can designate Recruiters
• has Recruiter permissions

Community Recruiter (formerly Request Responder)

• specific to a Community
• can create posters
• can add Process Operators to posters
• can view and respond to talent requests to their Community
• can view all published pools in their community, along with all applicants to those pools and their assessments
• can asses and place candidates in those pools

Process Operator (formerly Pool Operator)

• specific to a Process
• can update Process details and assessment plan until publishing time
• can view all applications and assess them and make final decision on qualification
• can place applicants as well, after qualification

Changes required for UI

• Removal of Teams pages on admin UI
• Addition of Communities pages on admin UI
• Update admin dashboard and navigation so everyone can only see stuff they can work with (Hiring Managers and Process Operators especially)
• A way to view Operators assigned to a Process, and add/remove people (if user has correct permissions)
• selection of Functional Community when creating a Job Poster
• selection of Functional Community when submitting a talent request / searching talent

Other proposed/requested Roles

DCM Recruitment Team has mentioned a few times there could be space for more Process-related roles. They need not be prioritized now, but we should make sure the system is built in a way they would be easy to add. From a user perspective, these are like sharing view/edit/comment permissions on a Job Poster or ongoing Process:

Process Auditor

• specific to a Process
• can view details of a draft process & assessment plan but not edit it
• can view applicants but not assess them (or maybe this was meant to be separate?)
• intended to be shared with HR officials

Process Assessor

• specific to a Process
• can not update the process itself but can help assess candidates
• can add assessment results but not make the final decision on qualification

Other thoughts

If we end up with a proliferation of different roles which grant the same accesses to specific resources, does it make more sense for the frontend to check for permissions instead of roles, like the policies do?

https://www.figma.com/file/Z5zy0VxJAqq7FBg548DwKp/One-diagram-to-rule-them-all?type=whiteboard&node-id=0-1