A closer look at the four pieces of Performance that run independently of a review cycle's own submit/calibrate/finalize flow: goals and OKRs, 360 feedback, performance improvement plans, and the competencies that feed into all of them.
This guide assumes you're already familiar with review cycles: see Performance Reviews, Goals & OKRs for how a cycle is set up and how reviews move through it. What's here goes deeper on the four screens that sit alongside reviews: Goals & OKRs (/performance/goals), 360 Feedback (/performance/feedback-360), PIPs (/performance/pips), and Competencies (/performance/competencies).
Performance uses separate permissions for actions and visibility: submit_review for your own records, view_performance for management read endpoints and manage_performance to create and administer. Company-wide visibility requires view_all_performance (or platform-admin access); otherwise reads are scoped to self and direct reports as applicable.
Goals
A goal is a single tracked commitment, owned by one employee. It can stand alone or be tied to a review cycle.
| Field | Notes |
|---|---|
| Category | individual (default), team, department, company |
| Priority | low, medium (default), high, critical |
| Status | not-started (default), in-progress, at-risk, completed, cancelled, deferred |
| Weight | 0–100, meant as a percentage of the employee's overall goal set |
| Target / current value | A number with a unit, e.g. "5 deals" or "98%" |
| Parent goal | Optional: lets a company or department goal cascade into individual ones |
Managers with manage_performance create goals and assign them; the owning employee (with submit_review) can see and update their own. The Update Progress action opens a slider for the completion percentage plus a short check-in note ("What did you accomplish? Any blockers?"). Moving a goal's status into completed stamps a completion timestamp and fires a goal-completed event; moving it back out clears that timestamp.
Manager and self ratings are the one part of a goal an owner can't set themselves: those, and manager feedback, are stripped from any update that isn't coming from someone with manage_performance. A goal tied to a review cycle rates on that cycle's scale (and locks once the cycle closes, the same as review ratings); an unlinked goal rates on a plain 1–10 scale. Editing an unrelated field on a goal, say, fixing a typo in the title, never triggers the rating checks, only an edit that actually changes a rating value does.
Employees see a trimmed status filter (All, not-started, in-progress, completed); managers see every status, plus summary cards across their team.
OKRs
An OKR is an objective with a set of weighted key results underneath it, tracked on its own tab of the same page.
| Field | Notes |
|---|---|
| Level | individual (default), team, department, company |
| Status | draft (default), active, completed, cancelled |
| Period | Free text, e.g. Q1 2024 |
Each key result has a title, a target value, a current value, a unit, and a weight. Creating an OKR needs manage_performance; the owner (with submit_review) can update it and progress it afterward. Update Progress sets the OKR's overall percentage directly with a slider: it isn't computed automatically from the key results. An OKR can have a parent OKR and a department, letting a company-level objective cascade the same way a goal can. An active OKR can't be deleted; move it to draft, completed, or cancelled first.
360 feedback
A 360 request asks one person (the provider) for feedback about another (the subject), optionally tied to a review cycle.
| Field | Notes |
|---|---|
| Relationship | peer (default), direct-report, manager, cross-functional, external |
| Status | pending (default), in-progress, submitted, declined |
Requesting feedback needs manage_performance; you name the subject and the provider, and a person can't be asked to review themselves. Requests default to anonymous: HR can turn that off per request when creating it. The provider fills in an overall rating (on the linked cycle's scale, or 1–10 if there's no cycle), strengths, areas for improvement, additional comments, and any structured responses the request calls for, then submits (allowed from pending or in-progress) or declines (only from pending).
Anonymity is enforced on the read side, not just the write side: when a request is anonymous, the subject can see that feedback exists and read its content, but not who the provider was, unless the subject holds view_all_performance (or is a platform admin), in which case identity still shows. The provider always sees their own submission. A request can be deleted any time before it's submitted; once submitted, it's kept for the record.
Performance improvement plans (PIPs)
A PIP is the most sensitive record in this module: it's a documented, disciplinary process for an employee who needs to improve, owned by a manager with an optional HR representative alongside them.
| Status | Meaning |
|---|---|
draft | Being prepared. Deletable only at this stage. |
active | In effect. Check-ins can be added. |
extended | Past the original end date, running on an extendedEndDate. Check-ins can still be added. |
completed-success | Closed, expectations were met |
completed-failure | Closed, expectations were not met |
cancelled | Stopped |
A PIP records a title, the reason, a start and end date, a list of expectations (each with a description, a target metric, an optional current metric, and its own status), what support is being provided, and a check-in frequency (daily, weekly, the default, biweekly, or monthly).
Only manage_performance can create or administer a PIP; a reader without company-wide performance access sees only PIPs where they are the subject or named manager. The detail endpoint applies the same scope as the list. Status moves in one direction: draft → active → (extended |completed-success | completed-failure | cancelled), and extended can still close into either completed outcome or cancelled. Closing a PIP into either completed-success or completed-failure requires outcome notes: you can't close one silently. Once a PIP reaches a closed state (either completed outcome, or cancelled) it's immutable; nothing about it can be edited afterward.
Check-ins can only be added while the PIP is active or extended, and each one has to fall within the PIP's own window (its start date through its end date, or its extended end date once it's been extended): a check-in dated outside that range is rejected. A check-in records a date, notes, and an optional progress rating from 1 to 5; leaving the rating blank stores nothing rather than a fabricated "worst possible" score. Only a draft PIP can be deleted.
Competencies
Competencies are the skills and behaviors your company evaluates people against: defined once, then reused across reviews wherever a cycle includes competency scoring. Managing them needs manage_performance.
| Category | |
|---|---|
core (default), leadership, technical, functional, behavioral |
A competency has a name (unique per company), a description, a category, a set of proficiency levels (each with a number, a label, and an optional description: there's no fixed default set, you define what fits), and can be scoped to specific departments or positions. A sort order controls where it appears in lists, and an active/inactive flag lets you retire one without deleting it.
Deleting a competency is blocked while it's still referenced in any review's competency scores: you deactivate it instead. This is the same reasoning as everywhere else sensitive history is protected: removing the competency outright would leave old reviews pointing at a score for something that no longer explains what it meant.
How these fit around a review cycle
Goals and OKRs run continuously: they aren't scoped to a cycle unless you link them, and they keep existing after a cycle closes (only their ratings lock once the parent cycle does). 360 feedback is usually requested to feed into a specific cycle's calibration, but can also be requested standalone. PIPs are entirely independent: they're opened and closed on their own timeline, whenever a manager needs one, with no dependency on any review cycle being open or active. Competencies are the one purely structural piece: they don't have a lifecycle of their own, they're just the vocabulary reviews and their scores are built from.
Frequently asked questions
What's the difference between a goal and an OKR? A goal is a single tracked target with a status, a progress percentage, and an optional metric. An OKR is an objective with several weighted key results underneath it, organized by level and period. Use goals for a discrete commitment, OKRs when the objective naturally breaks into multiple measurable results.
Can I see who gave anonymous 360 feedback about me?
Not through your own access, unless you also hold view_all_performance. The content of the feedback is visible to you as the subject; the provider's identity is redacted unless you have that broader permission or are a platform admin.
Why can't I edit this PIP?
PIPs are immutable once closed: completed-success, completed-failure, or cancelled. Anything short of that (draft, active, extended) stays editable.
Do I need outcome notes to close a PIP?
Yes, for either completed outcome. There's no way to move a PIP into completed-success or completed-failure without recording why.
Can I delete a competency that's in use? No. If any review has scored against it, deletion is refused: deactivate it instead so history stays intact.
Does a goal's rating always use the same scale? Only if it's tied to a review cycle, in which case it follows that cycle's scale and closes when the cycle does. A goal with no cycle attached rates on a plain 1–10 scale that never locks.