How to Restrict Users of Career Hub of their ability to Search other employees and view their personal details

Hi ​@arulsubra, excuse me. It looks like my complete message was not added. 

To restrict Career Hub users in a sandbox from searching other employees and viewing personal profile details, configure it in two layers:
 

1) Restrict People Search access

In Admin Console:

Talent Management → Home, Feeds, Career Hub Features → Advanced → access_check

Add or update the people_search access check. The internal guidance says feature access is controlled through career_hub_base_config > access_check, and people_search is one of the supported feature keys for Career Hub restrictions.
 

If People Search should be disabled for everyone

"people_search": {
  "default_access": false,
  "rule_list": []
}

If People Search should be enabled only for a subset

Example: allow only employees where a custom ATS/employee field says they are eligible:
 

"people_search": {
  "default_access": true,
  "rule_list": [
    {
      "rule_id": "people_search_allowed_population",
      "assert_value": true,
      "precondition": "current_user.get_employee_info()",
      "condition": "{{ ((current_user.current_user.get_employee_info('custom_info') or {}).get('talent_profile') in ['Yes']) }}"
    }
  ]
}

The same access-check pattern is documented for restricting Career Hub features by profile attributes such as employee type, hiring company, or location. If the rule syntax is new or complex, internal guidance recommends involving Career Hub Engineering for the rule_list because malformed conditions can fail silently or hide the feature from everyone.
 

2) Hide People Search from Career Hub navigation

Disabling access alone may not always remove the navigation item unless the top nav is also wired to the access check. Update:

Talent Management → Home, Feeds, Career Hub Features → Advanced → top_nav

For the People link, add the People Search permission/access mapping. Example:

{
  "type": "route",
  "id": "peopleSearch",
  "display": "People",
  "required_perms": [
    "peopleSearch"
  ],
  "perms": {
    "inclusion_perm": "peopleSearch"
  }
}

This pattern was recommended internally so the People Search link is added/removed from the navbar based on the people_search access check evaluation. Some newer configs use required_feature_flags instead; the Manila restriction example maps the People route to people_search using required_feature_flags after enabling the top-nav simplification gate.
 

3) Restrict what users can see on another employee’s profile

People Search restriction prevents discovery/search, but users may still reach a profile from another route or a direct URL. To limit personal details on profile pages, configure the Other Profile / Public View.

Admin Console:

Talent Management → Profile and People Search → Advanced → career_hub_profile_config

Career Hub profile config supports separate views for:
 

• ownProfile
• otherProfile
• managerViewProfile
• hrbpViewProfile

The documentation confirms that otherProfile controls what a user sees when viewing another employee’s profile. Remove sensitive sections from otherProfile layout/props or use visibility overrides.

Common sections to remove/restrict include:

ProfileInfoContact
ProfileSkills
ProfileOrgChart
WorkExperience
ProjectExperience
CoursesExperience
EducationExperience
AwardsExperience
PatentsExperience
PublicationsExperience
ProfileHighlights
SimilarPeopleFeed
SkillsProficiency
ProfileCustomFields

These profile-section keys are documented as supported exclusion/visibility values.

If you need conditional profile visibility by population, use the documented permission_roles + permission_rules + visibility_rules_override approach:

1. Define the role in career_hub_base_config > permission_roles
2. Define the matching rule in career_hub_profile_config > employee_engagement > permission_rules
3. Apply it in display_config_v2 > profile > visibility_rules_override

Example pattern:

"display_config_v2": {
  "profile": {
    "visibility_rules_override": {
      "profileSkills": "is_talent_profile",
      "profileExperienceCourses": "is_talent_profile",
      "profileExperienceProjects": "is_talent_profile"
    }
  }
}

4) Important caveat: direct URL / API behavior

There was a prior issue where people_search was disabled and the nav was removed, but users could still open the People page directly by URL. Engineering later added a fix so direct navigation to the People Search page respects the access check; however, the note also says that if the requirement is to fully restrict profile search entity access across the broader platform/API, you may need global entity filters, not just the people_search access check.

So for a strict sandbox validation, test all three paths:

1. People link is hidden from Career Hub nav.
2. /careerhub/search/people?... or /careerhub/people/search does not load for restricted users.
3. Direct profile links show only the intended reduced otherProfile fields.

Recommended sandbox implementation sequence

1. Identify the restricted population field, e.g. location_country, employee_type, custom_info.talent_profile, business unit, etc.
2. Configure career_hub_base_config > access_check > people_search.
3. Wire top_nav People route to peopleSearch / people_search.
4. Configure career_hub_profile_config otherProfile to hide personal-detail sections.
5. Test with:
   • an allowed employee
   • a restricted employee
   • direct People Search URL
   • direct employee profile URL

If the goal is no employee discovery at all, use people_search: default_access: false, remove/hide the nav item, and strip down otherProfile to only the minimum fields required by the customer’s policy.