A change of administrator can coincide with changes to the People team, the organisational structure or the performance processes themselves. Use this checklist to confirm what is current, identify what needs attention, and take ownership of Performance Leader.
You can work through this with your Customer Success Manager and the outgoing Super Admin.
Write down the reasoning, not just the answer
The thing most often lost between administrators isn’t the configuration (you can see that on screen), but the reasoning behind decisions: why the review was designed this way, or why that question is asked at that step. This matters because some of those reasons may no longer apply — and this may be an opportunity to simplify and improve the review experience.
Performance Leader supports documentation with description fields for each review and a private documents area for storing changes, but it can be difficult to do this comprehensively and keep up with ongoing updates.
This is the single most valuable thing you can do in your first few weeks, while the people who remember are still available.
1. Confirm ownership
Confirm the primary super admin and a backup. One administrator with no backup is the most common single point of failure.
Identify the internal business owner who approves significant platform and process changes.
Confirm who owns employee data, communications and day-to-day administration.
Identify the appropriate internal contacts for decisions and escalations.
Confirm who will manage the relationship with Performance Leader.
2. Review administrator access
Confirm that every current super admin still requires full access.
Review restricted admins and confirm their scope is still correct. See Manage permissions (Super and Restricted admins).
Remove or update access for people who have left or changed responsibilities.
Distinguish between people who need administrative access and those who only need a leadership view. See Create and set leadership views.
Confirm that administrators have appropriate multi-factor authentication arrangements.
Record why: if someone has broader access than their role suggests, find out whether that was deliberate.
3. Check your people and organisational data
Confirm that departments, teams, locations, roles and reporting relationships reflect the organisation today. See Create, update or delete core attributes (roles, departments, location).
Identify structures that have been created, merged, renamed or disbanded.
Check recent starters, leavers, promotions, transfers and returning employees.
Confirm how dual-role employees, contractors and other exceptional users should be classified.
Confirm the authoritative source of employee data and who is responsible for correcting it. See Import employee data and run HRIS sync.
Record why: unusual designations are often deliberate — a team named for a legacy structure, a role profile that exists to drive a particular review path. Establish which oddities are intentional before you tidy them up.
4. Review active processes and configuration
Identify active and upcoming reviews, check-ins, objective-setting and feedback processes.
Confirm the participants, workflow steps, dates and purpose of each process.
Check what employees, managers, contributors and administrators can see — including feedback, private notes and final reports. Proxy login is the reliable way to check this rather than inferring it from settings. See Act as a user within a review.
Review the associated forms, frameworks, rating scales, reports, emails and reminders.
Identify draft, duplicated, obsolete or customised configurations that need review before they are reused.
For each active process, record what you can establish about why it was designed this way — and flag anything nobody can explain.
This section is where context is most often lost, and where losing it costs most. A review form is a series of decisions about what the firm wants to measure. If those decisions are undocumented, the next person to edit the form will unpick them without realising.
5. Confirm decisions and the operating calendar
Record the major upcoming process dates, preparation lead times and approval deadlines.
Confirm who approves workflow design, access, communications, ratings and report release.
Assign an owner to data updates, testing, launch, reminders, moderation and cycle closure.
Record unresolved decisions, known issues and workarounds, each with an owner and a due date.
Schedule regular access reviews, data checks and a post-cycle review.
Record why: workarounds in particular deserve a note. A workaround with no recorded reason tends to become permanent.
You have completed the stocktake when you can explain
Who owns the platform and its major decisions
Who has access, and why
Whether the people and organisational data are current
Which processes are active or upcoming
Why the platform is configured the way it is — and where that reasoning has been lost
What needs to change, who will change it, and by when
What to do next
Once you know what you have inherited, get hands on. Practise common administrative tasks lists the tasks worth working through on test users and a test cycle.
Keep whatever you produce from this checklist. It becomes the handover document that did not exist when you arrived — and the next administrator will thank you for it.