People Review — redesign configuration guide
Nextgen — platform-team reference
Activation and permissions
The legacy shell definition app/config/neobrain/company/definitions.yml maps the redesigned People Review menu to smr_people_review_access and read-people-review-campaign. Backend operation permissions remain independent. Configure roles and associated visibility groups through the authorized platform process; do not assume a visible menu proves all operations are permitted.
| Operation | Permission key verified in nextgen routes |
|---|---|
| Read campaign/list | read-people-review-campaign |
| Create / update / delete campaign | create-people-review-campaign / update-people-review-campaign / delete-people-review-campaign |
| Add / remove reviewed user | add-user-to-people-review-campaign / remove-user-from-people-review-campaign |
| Read individual review, answers, calibration, Talent Card source information | read-people-review |
| Write assessment answers, comment, flag, submit | update-people-review |
| Delegate evaluator | delegate-people-review |
| Export | export-people-review-campaign, plus campaign owner/creator or privileged check |
Permissions alone are insufficient. Campaign access, assigned evaluator/committee membership and phase checks still apply. Campaign ownership alone does not satisfy individual answer-read checks. Committee membership is a campaign-wide data-access decision.
Dependencies
Prepare company evaluation criteria before selecting them in a campaign. Establish valid reporting relationships for evaluator assignment. User/group/talent-pool and hierarchy updates use publishers/consumers; confirm operational processing before interpreting delayed assignment as a role problem. Local source inspection establishes these dependencies, not their runtime health.
No AIHub People Review dependency was identified by a targeted search of aihub/src; this is not a claim that no other integration exists. No infrastructure changes are part of this guide's execution.
Nextgen — customer-administrator procedure
Campaign preparation and defaults
Open the nextgen People Review creation wizard. The current frontend defines Basic information, Evaluation criteria, Matrix settings, Review assignment, Collective review, Talent Card, then Campaign summary. The September 2026 playbook describes five steps; current code has six configuration steps plus summary.
| Step / setting | Values and initial state verified in code | Scope and effect |
|---|---|---|
| Name / description / dates | Text starts empty; start, end and calibration dates start null in the creation store | Identify the campaign and schedule. Do not infer every backend requirement from empty defaults; resolve validation errors before launch. |
| Performance / potential | Initially true in the frontend creation store | Enables selected company criteria for this campaign; required underlying question configuration must exist. |
| Risk / impact of loss | Initially false | Enables additional criteria when configured. Treat population access as applying to these sensitive criteria too. |
| Mobility wish | Initially false in the frontend | Exact end-to-end behavior was not traced; do not assume it exposes profile data automatically. |
| Custom assessment fields | Initially empty; text or scale types | Campaign-specific questions, separate from reusable Review Campaign forms. |
| Matrices | Initially empty | Configure axes, cells and eligible criteria. Supported criterion enum includes performance, potential, risk, impact and custom scale. |
| Hierarchy level | Initial value 1; enum values 1, 2, 3 | Assign evaluator from N+1, N+2 or N+3 reporting relationships. Backend hierarchy updates fall back to a nearer available manager. |
| Reviewed population | Users, user groups, talent pools | Creates campaign reviews via the relevant assignment process. Check overlaps and resulting assignments rather than assuming a simple static snapshot. |
| Collective reviewers | Explicit campaign members | Allows campaign-wide individual/answer reads and committee-phase work when operation permissions also allow it. |
| Owners | Explicit campaign owners, with creator also recognized | Campaign management/list scope; does not itself confer evaluator/committee answer access. |
| Talent Card selection | Initially no source campaigns or questions | Controls which prior Review Campaign questions can be retrieved for each reviewed employee. |
Frontend initial values are not server-wide defaults or proof of persisted values for an existing campaign. No automatic inheritance from the legacy questionnaire is established.
Configure forms and answer visibility deliberately
For campaign-specific text questions, define the question and expected response. For scale questions, define options/values and display consistently with intended matrix use. Backend scale entities initialize their display format to percentage; the actual UI choice/default must be confirmed in the deployed builder. Answer types outside text/scale are not supported by the inspected custom-assessment validator.
For the Talent Card, select the source Review Campaign and the exact questions required. The read provider returns existing answers for the reviewed employee, separated into self/main-evaluator/second-evaluator slots; supported nested choice answers are included. Review the source data sensitivity before enabling it for a committee. Legacy PDF hiding does not establish any restriction on this nextgen endpoint. A general per-question nextgen People Review audience control equivalent to legacy PDF visibility was Not verified.
If an owner must also read and calibrate individual assessments, configure the appropriate committee membership and operation rights deliberately. Adding an owner only is insufficient. If a manager should see only their assignments, do not add that person to a campaign-wide committee merely to make a button available.
Lifecycle, changes and validation
The campaign enum defines draft, not started, phase 1, standby, phase 2, done and archived. Its editable-preparation predicate is true only for draft/not started; immutable-field validators enforce restrictions for structure and custom assessment fields. Do not treat an edit button as proof every field is mutable after launch. Population attachments have their own validators and asynchronous consequences.
Phase 1 allows the assigned evaluator's assessment writes. Standby and phase 2 are committee-writing phases in the current backend validator. Draft, not started, done and archived are rejected by that assessment-write validator. Reading answers is a separate evaluator/committee check without a phase condition in that validator.
Before rollout, use a sample campaign with fictional employees and test:
| Persona | Expected check |
|---|---|
| Evaluator assigned employee A only | A's detail/answers accessible; unrelated B's detail denied; phase-1 write permitted with action rights. |
| Committee member | A and B readable; phase-1 write rejected; standby/phase-2 write permitted with action rights. |
| Owner only | Broad campaign review list; no individual-answer access from ownership alone; export requires export permission. |
| Reviewed employee only | No automatic People Review self-access. |
| Unrelated user | No access solely because the user has an HR/manager job title. |
Also test filters, matrix-cell population, configured Talent Card questions and source-answer slots, export contents, and final-state write rejection. This table is a proposed acceptance check, not a record of tests executed on production.
For a misconfiguration, correct it through the authorized administrator workflow after reviewing the current phase and stored answers. No verified automatic migration/rollback between legacy and nextgen is documented; changing implementation generation is not equivalent to changing a display option.
Troubleshooting and evidence
A missing menu points first to shell activation/rights; a visible menu followed by denial points to operation permissions and campaign access. An empty population can reflect relationship data, evaluator assignment, asynchronous processing or active filters. A visible campaign with denied individual answers can be the expected owner-only case. An empty Talent Card can reflect no configured questions or no existing answers.
Reviewed 15 October 2026 — Verified in code: legacy UsersRelationsReview, DefaultController, ReviewAssessmentController, ReviewPDFController and Resources/views/pdf/pdf.html.twig; nextgen src/Http/Api/Routing/V2/people_review*.yaml, PeopleReviewCampaignAccessChecker, PeopleReviewValidationService, PeopleReviewRepository, HierarchyLevel, CampaignStatus, custom-assessment entities/validators and frontend store/createPeopleReview.store.ts. Repository paths and symbols are expanded in the technical guide.
Documented in Confluence: the three linked legacy sources and redesign playbook, v3, modified 24 September 2026. PS Delivery Philosophy & Project Methodology, v7, and Onboarding/learning and partner certification, v9, were read as context; they do not establish feature permissions or defaults. KBCT 2136702980 is the FAQ folder, not a feature page.
Not verified: exact tenant values, deployed form labels/defaults, administrator availability, full source-form sharing parity, complete legacy endpoint authorization parity and automatic migration. Screenshot gaps include both languages' administrator role setup, relationship configuration, campaign wizard, custom fields, Talent Card configuration and PDF visibility. No business settings or answers were edited. The legacy creation link unexpectedly persisted one blank draft before any Save action; this behavior is recorded above.
Last updated on 3 November 2026