Lattice

Lists review cycles across the whole company - every cycle, whether or not the user participates in it - and, with `includeConfiguration: true`, retrieves the setup of each: identity/timing fields, configuration settings, and each review group's assigned template and questions. By default (or with `includeConfiguration: false`), each cycle includes only `id`, `name`, `type`, `state`, `phase`, `createdAt`, `startDate`, `reviewsStartedAt`, `reviewsEndedAt`, `revieweesCount`, and `isRecurring`; configuration settings, review groups, and the top-level `templates`, `questions`, and `rules` maps are omitted. Use this when an admin wants to find a company review cycle (e.g. by name, state, or launch date) or understand how one or more cycles are configured - which groups (self, peer, upward, downward reviews) exist, what template each is using, the questions and rating scales on those templates, and the workflow/visibility/peer-selection/scoring rules chosen for the cycle - rather than any submitted review content or answers. Leave `includeConfiguration` off for listing and discovery; set it to true only when inspecting a single cycle (e.g. one id in `cycleEntityIds`), since full configuration for many cycles is large. Pass `cycleEntityIds` to look up specific cycles; otherwise filter by `name`, `reviewCycleTypes`, `reviewCycleStates`, and/or `dateFrom`/`dateTo` (on launch date), or omit all filters to return every one of the company's review cycles, paginated. With `includeConfiguration: true`, each cycle includes identity/timing fields (name, type, state, phase, start/launch/end/calibration/peer-selection/weighted-scores dates, creator, last-modified time, reviewee count, whether it was created by a recurring rule) plus a `recurringRuleId` when `isRecurring` - look it up in the top-level `rules` map rather than expecting it inline, since many cycles can share the same rule (a rule spawns a new cycle each time it fires); a rule includes its schedule (cadence, timezone, autoActivate, its own status distinct from any cycle's state/phase) and the phase timing/durations it applies to cycles it generates - plus configuration fields covering workflow rules (e.g. whether managers go last, write summaries, or can preview responses early), deliverable visibility (what each review type shows the reviewee, e.g. anonymous vs. named peer reviews), peer selection rules (self-nomination, draft responses during selection, rejecting requests, excluding recent hires from upward reviews), scoring/weighting (whether weighted scores are shared, autocalculated, and their goal/competency weights), calibration/reopen workflow rules, and promotion nomination settings (including `promotionsTemplateId`, the template used for promotion nominations). In configuration mode, each review group carries a `templateId` and a `questionIds` list (the questions actually asked to that group, in form order); a cycle with `promotionsEnabled` carries `promotionsTemplateId` and `promotionsQuestionIds` the same way, for the promotion-nomination form. Look these up in the top-level `templates` and `questions` maps (keyed by id) rather than expecting them inline, since the same template and question definitions are commonly shared across many review groups, cycles, and promotion nominations. A group's `templateId` (or a cycle's `promotionsTemplateId`) is null when no template is assigned, in which case its question id list is empty. Each template includes its name, instructions, and word count limit. Questions are deduplicated by the specific question revision that was asked - if a question's wording is edited, groups still on the old wording and groups on the new wording point to different entries in `questions`; each entry's `questionId` identifies the underlying bank question and stays stable across such edits, while its `id` (the map key) identifies this specific revision. Each question includes its text, whether it's private, whether it's derived from a goal or competency, and its rating scale or multiple-select options if it has one. This tool is restricted to Reviews admins (requires ManageAllReviewsAndCalibration permission) and returns an authorization error for anyone else. Does not return reviewees, reviewers, or any review responses - only cycle summaries or configuration. Pagination is cursor-based: pass the `nextCursor` from the previous response back as `cursor` to fetch the next page, and stop once `nextCursor` is no longer returned.

Searches for employees in the user's company by name, work email, and/or department. Use this when you need to look up a person's identity or resolve a name to an entity ID before calling another tool. Returns employee profiles including their entity ID (UUID), which is the identifier required by other tools that accept employee ID parameters. Omit all filters to list all employees. Does not return org-chart relationships (reports, manager chain) or work artifacts (reviews, feedback, goals). Results reflect what the user is permitted to see.

Retrieves feedback items the user has visibility into. It should be used when the user wants to see what others have said about a specific employee, or what feedback a specific employee has written about others. Each item includes the feedback text, visibility level, creation date, author and target identities (UUID, name, email), and any company values tagged on the feedback. Pass aboutEmployeeId for feedback about a person, or byEmployeeId for feedback authored by them; if both are passed, aboutEmployeeId takes precedence. If neither is set, returns recent feedback for the viewer-expanded accessible target set (self, reports, and relationship-accessible targets) and does not enumerate every company-public/open feedback item. Pass aboutEmployeeId to retrieve feedback about a specific employee, including public/open feedback the viewer can see. Does not return performance reviews, update answers, or 1:1 notes. Results reflect what the user is permitted to see.

Retrieves feedback requests the user has visibility into, newest first. Use this when the user wants to see who has asked them for feedback, which of their requests are still waiting on a response, or what feedback has been requested about an employee - 'do I have any feedback requests?', 'who hasn't answered my request yet?'. Pass targetEmployeeId for requests sent to that person to answer, authorEmployeeId for requests that person sent, and subjectEmployeeId for requests about that person; filters combine, and omitting all of them returns every request the user can see. Each request includes its id, message, status, visibility, when it was sent and answered, and the requester, the person asked, and the employee it is about (UUID, name, email). The id of a pending request sent to the user can be used to answer it with feedback. Declined requests are not returned, and the feedback written in response is not included. Results are paginated; pass nextCursor to fetch the next page. Results reflect what the user is permitted to see.

Finds goal cycles in the user’s company, including draft and activated cycles. Use this to identify the cycle UUIDs and date ranges for goal reporting. Returns each cycle’s ID, name, start date, due date, current-cycle indicator, and activation time. Deleted cycles are excluded, and results are ordered by start date from newest to oldest with cursor pagination.

Lists goals by the department that owns them, company goals, or goals aligned directly under a parent goal. Use this for questions like 'what are the Sales department's goals', 'what are our company goals', or 'what goals roll up to this one'. Department means goals the department owns, not goals of people in the department. Filters combine, and at least one is required. Each goal includes its owners, the goal it is aligned to and the goals aligned beneath it, its level, and who it is shared with. Results reflect what the user is permitted to see.

Use this to list meetings the user participates in, so an agent can pick which meeting's details matter for prep, recall, or follow-up. Returns lightweight metadata for each meeting: title, schedule, cancellation status, and attendees with name, email, and role already resolved. Does not return talking points, notes, action items, or AI summary/coaching — only enough to identify a meeting. Optionally filter to meetings that also include a specific employee (withEmployeeId) and/or a date window. Only returns meetings the user themselves can access. Results reflect what the user is permitted to see.

Use this to surface past, upcoming, or cancelled 1:1 meetings between the user and a specific employee as context for review-drafting, prep for an upcoming 1:1, or recalling what was discussed and committed to. Returns each meeting with its talking points, action items, shared notes, AI summary, and the user's own private note. Participant/creator/assignee identities are returned with name + email already resolved. Filter by dateFrom/dateTo to scope to a review period or other window. Only returns 1:1s the user themselves participated in; does not return meetings between other employees, or meetings the user was not part of. Results reflect what the user is permitted to see.

Use this to get the team beneath an employee — direct reports, or the full subtree down to a given depth — when you need to understand who someone manages, fan out work, or analyze a team. Returns each report's employee profile (entity ID, name, title, email) with their manager's id. Only returns downward reports; does not include the employee themselves, their manager, or peers. Results reflect what the user is permitted to see.

Lists the reviewees of a single review cycle and where each one stands, so an admin can track the cycle from peer selection through writing, calibration and packet sharing. Use it for questions like "how many reviewees still need to select peers?", "whose packets still need to be shared?" or "who still has reviews outstanding?", and for one person, "where does this employee stand?". Works for any cycle that is not a draft, whatever its phase (peer selection, writing, calibration, sharing, ended). Returns the cycle's own details once as `cycle`, then one entry per reviewee. Filters combine with AND; the values within a filter combine with OR. `fullCount` is the size of the filtered set across all pages, so pass a filter with `pageSize: 1` to answer a "how many" question without paging. Each reviewee has: `peerSelection.status` (not-started = the reviewee has not submitted peers; needs-approval = submitted and awaiting the manager; approved = the manager approved the reviewee's picks; nominated = the manager chose the peers because reviewees do not pick their own; admin-overrode = an admin set the peers. The last three are complete) or null when the reviewee has no peer selection step, which should be treated as not applicable and never as blocking. The status records what happened during peer selection and is independent of the later phases of the cycle: once the cycle launches, the reviewee's own picks stand and peer reviews go ahead even if the manager never approved them, so needs-approval or not-started can remain on a reviewee in a cycle that is already writing, calibrating or shared, and does not mean anything is blocked. `peerSelection.selections` is an audit of the peers put forward, independent of review requests: each peer is counted once under whoever selected them first (reviewee, then manager, then admin) and judged against the final list, so total = selectedByReviewee + addedByManager + addedByAdmin = approved + rejected + pending. A manager-added peer can end up rejected if an admin later overrides. `selfNominationsReceived` counts people who volunteered to review this reviewee and `selfNominationsMade` counts people this reviewee volunteered to review; self-nominations are only possible before launch, are not counted as manager or admin additions, and are judged approved or rejected by whether the volunteer's peer review request still exists once the selection is decided. A volunteer the reviewee also picked is counted in both `selections` and the self-nominations, so do not add the two together. `packetStatus` runs receiving-reviews -> in-calibration -> not-shared -> preview-shared -> shared -> acknowledged. receiving-reviews also applies before the cycle's reviews have launched (`cycle.reviewsStartedAt` is null, e.g. during peer selection), when it means writing has not begun rather than that reviews are coming in. preview-shared means a preview was released but the manager remarks were not, not that the whole cycle was shared. not-shared only means the reviewee is done writing and nothing has been shared: it does not by itself mean calibration finished, so read it together with the cycle `state` and calibration fields. For a cycle that is active (still writing) it means the reviewee is finished writing; for an ended cycle it means the reviewee is finished and nothing has been shared. Sharing also waits until calibration (`cycle.calibrationEndedAt`) and weighted scoring (`cycle.weightedScoresEndedAt`, when `cycle.weightedScoresEnabled`) have ended, so check those before saying a packet can be shared. `cycle.packetSharingDisabled` explains why a finished packet cannot be shared. `reviews` has counts per direction (self, peer, upward, downward) of completed, inProgress, notStarted and rejected review requests, where outstanding work is notStarted + inProgress. A direction is omitted when the reviewee has no review requests in it, which means not applicable, not zero. These counts come from review requests only, not from peer selection: peer review requests are created as soon as peers are picked or someone self-nominates, before any approval, and are deleted and recreated if a manager or admin overrides the peers. So during peer selection, peer counts can include peers who are later rejected, and a reviewee with no peers yet has no `peer` key. Pass `includeParticipants` to also get the people behind the counts: `peerSelection.selections.peers` (each selected peer, who selected them first, and whether they ended up approved, rejected or pending), `selfNominationsReceived.nominations` (who volunteered) and `selfNominationsMade.nominations` (who this reviewee volunteered to review), and `reviews.<direction>.reviewers` (each assigned reviewer and the state of their review request). The lists are an assignment roster with no review content, so reviewers are named in every direction, including cycles that deliver peer or upward reviews anonymously to employees; do not use them to attribute anyone's feedback. Each person is given as an id and a name only. Deactivated employees are included; one whose record was permanently deleted is left out of a list but still counted. Page size is capped at 25 when it is set. Does not return review content, ratings or answers, only states, counts and identities. Restricted to Reviews admins; anyone else gets an authorization error. Results are paginated: pass `nextCursor` from the previous response back as `cursor` for the next page, and stop once it is no longer returned.

Retrieves reviews the user is permitted to see, filterable by who the review is about, who wrote it, the cycle, direction, submission/sharing status, and date range. It should be used when the user wants to read or browse reviews - their own self-reviews, reviews they wrote about someone, reviews about an employee, or all reviews in a cycle - including a manager asking about reviews for their direct or indirect reports. Each result includes review metadata (id, cycle, reviewee identity, author identity, direction, state), the questions on the form, and the saved answers (text and ratings). By default only reviews already shared with the reviewee are returned. When the request may involve reviews that are still in progress, such as a manager checking their team or their reports, pass `status` = `all_submitted` to also include submitted reviews that have not yet been shared. A review that has not yet been submitted does not appear under `shared` or `all_submitted`, and `open` returns only drafts authored by the user, so when a review is missing treat it as not having reached the requested stage rather than as the user lacking permission to see it. Set `includeSummaries` to true to also return the manager summary for each review packet in the page, once the packet has been shared and only when the user is permitted to see it - use this when the user asks about a manager summary or an overall rating written in one. A summary is only returned alongside at least one review the user can see from the same packet. Does not return review cycle metadata without review content. Pagination is cursor-based: pass the `nextCursor` from the previous response back as `cursor` to fetch the next page, and stop once `nextCursor` is no longer returned. A total match count is not provided. Results reflect what the user is permitted to see.

Finds launched Engagement, Onboarding, or Exit surveys whose results the current user can view. Returns each survey's ID, name, family, details, launch time, end time, and raw response export eligibility. Draft surveys, Pulse surveys, legacy surveys, and surveys without results access are excluded. Results are ordered by launch date from newest to oldest and support filters plus cursor pagination.

Returns the user's current-period update draft, with the questions on the form, any answers already saved, the period bounds, and the cadence. Use this when the user wants to see, fill out, or edit their update for the current period - 'what's my weekly update look like?', 'show me what I need to fill in for my update', 'start my update for this week.' Returns the draft id (use it to save answers), the questions on the form, the period dates (start/end), the cycle cadence in weeks, the public flag, the saved sentiment, and the saved answers so far. If `draft` is null, no current-period draft exists yet — questions are still returned so the user can preview the template, but answers cannot be saved until a draft is available. Does not return other employees' updates or historical drafts.

Retrieves published Growth Areas for 1-25 specified current direct reports of the user. Use it to review direct reports’ development plans and progress, prepare for 1:1s, or inform coaching conversations. Returns status, title, description, competency, creator, dates, actions, and progress updates. Filter by status, competency, or creation, completion, target, or last-change date. Status defaults to all, meaning active and completed areas; drafts and AI suggestions are excluded. Includes linked feedback the user can read. Growth Areas, actions, progress updates, and linked feedback are independently paginated. Check each list’s fullCount and use its nextCursor to retrieve additional pages. The same actionsCursor, updatesCursor, or feedbackCursor applies uniformly to every Growth Area in the response. Requested employees who are not current direct reports are skipped and listed in skippedEmployeeIds; Growth Areas are still returned for the rest. If feedback cannot be loaded, its status is unavailable and the Growth Areas are still returned. If the user cannot access linked feedback, or this connection has not been granted access to feedback, its status is not_permitted. Results reflect what the user is permitted to see.

Retrieves the open performance review drafts the user is currently authoring. Each draft includes the review cycle metadata, the questions on the form, any answers already saved, and identifying information about the reviewee (UUID, name, email). Each answer has a unique id that identifies the specific answer slot — multiple answer slots can share the same questionRevisionEntityId when a form rates several competencies or goals with the same question, but each slot always has its own id. This tool should be used when the user wants to see, fill out, or edit reviews they've been assigned — including self-reviews and reviews about other people. Does not return submitted or shared reviews, reviews authored by other people, or review cycle metadata without draft content. By default returns all open drafts authored by the user across all review cycles. Results are paginated by review packet (one reviewee in one cycle); a packet can contain multiple draft forms, so a page may contain more drafts than `pageSize`. Both `pageSize` and `fullCount` count packets. Use `nextCursor` to fetch the next page. Results reflect what the user is permitted to see.

Retrieves the sensitive demographic fields on an employee record — ethnicity, gender identity, pronouns, disability status, and birthdate — for equity analysis, group breakdowns, and bias checks. Use this only when the user is specifically analyzing demographic data, not for general profile lookups. Never returns social security number or other government ID data, which lives in a separate, more restricted store. Restricted to admins with company-wide visibility; other callers receive an error. Fields the user isn't permitted to see, or that aren't set, come back null rather than causing an error.

Retrieves a full employee profile — every default and custom field the user is permitted to see for that employee, not just the slim identity fields (name, title, email, department) returned by other lookup tools. Use this when the user asks about a specific profile attribute not covered by those slim fields, such as start date, cost center, or a company-specific custom field like T-shirt size. Returns the same core identity fields as other tools plus an `otherFields` list of every other visible field (default or custom) on the employee's record, each with both the raw `value` and a human-readable `displayValue` for fields backed by a selectable option or a related employee. Does not return org-chart relationships (reports, manager chain) or work artifacts (reviews, feedback, goals). Fields hidden from the user are simply omitted rather than causing an error. Results reflect what the user is permitted to see.

Returns published Growth Areas for 1-25 specified employees with their status, title, description, target date, actions, progress updates, and linked feedback the user can read. For Grow admins reviewing employees’ development work. Use it to review development work or filter by status, competency, or creation, completion, target, or last-change date. Status defaults to all, meaning active and completed areas; drafts and AI suggestions are excluded. For a manager or department question, identify the relevant employees first and pass their UUIDs in batches of up to 25. Each Growth Area’s actions, progress updates, and linked feedback are themselves paginated (independently of the Growth Area list) — check each one’s fullCount against the number of items returned, and use actionsCursor/actionsPageSize, updatesCursor/updatesPageSize, or feedbackCursor/feedbackPageSize to retrieve the rest when a Growth Area has more actions, updates, or feedback than fit in one page. The same cursor applies uniformly to every Growth Area in the response. If feedback cannot be loaded, its status is unavailable and the Growth Areas are still returned. If the user cannot access linked feedback, or this connection has not been granted access to feedback, its status is not_permitted. Results reflect what the user is permitted to see.

Use this to fetch full context for one meeting the user is an attendee of — title, schedule, attendees, notes, talking points, action items, AI summary, and coaching advice for the user — so an agent can prep for an upcoming meeting or recall what was discussed and committed to. Pass the meeting UUID (for example from a prior find-meetings call). Only returns meeting context for meetings the user attends, and does not return meetings the user is not on. Notes include both shared notes and the user's private notes when visible. Coaching insight is scoped to the user and should be treated as advice, not factual claims about others. Results reflect what the user is permitted to see.

Returns the user’s own Growth Areas for self-review and development planning, including descriptions, status, related competency, key dates, actions, and progress updates. Use status to select draft, active, completed, or all areas; the default includes drafts and published active and completed areas. AI suggestions are excluded. Includes linked feedback the user can read. Filter by competency or creation, completion, target, or last-change date. Use cursor and pageSize to page through Growth Areas. Actions, progress updates, and linked feedback are independently paginated within each area; use their nextCursor values with actionsCursor, updatesCursor, or feedbackCursor to retrieve more, with the same cursor applied to every area in the response. The tool always retrieves the user’s own information and does not accept an employee ID. If feedback cannot be loaded, its status is unavailable and the Growth Areas are still returned. If the user cannot access linked feedback, or this connection has not been granted access to feedback, its status is not_permitted. Results reflect what the user is permitted to see.

Retrieves reviewers who still owe one or more outstanding review requests within a single review cycle, along with completion progress totals for that cycle. It should be used when the user wants to know who has not finished their reviews in a cycle, chase down stragglers, or report overall completion. Each reviewer entry includes their identity, the identities of the reviewees still awaiting a review from them, their total review requests in the queried cycle, and a breakdown of that total by status: how many are not started, in progress, already completed (submitted or closed), or rejected (withdrawn, e.g. reassigned to someone else). This breakdown always covers all of a reviewer's requests; only which reviewers appear in the list is affected by the `status` filter. By default (no `status` filter), a reviewer appears if they have any outstanding (not-started or in-progress) request; pass `status` to narrow to reviewers with at least one request in that specific state. Reviewers can be sorted by their not-started or in-progress count via `sortBy` (e.g. to surface reviewers with the most outstanding work first); completed and rejected counts cannot be used to sort. The progress totals cover how many review requests in the queried cycle have not been started, are in progress, are incomplete overall (the sum of the other two), or have already been completed - these totals cover the whole cycle regardless of the `status` filter, which only narrows the `reviewers` list. This tool is restricted to Reviews admins and returns an authorization error for anyone else, rather than partial or empty results. Does not return review content or ratings - only counts and identities. Results are paginated: pass the `nextCursor` from the previous response back as `cursor` to fetch the next page, and stop once `nextCursor` is no longer returned.

Returns the review cycles the user is currently participating in, with their role (reviewee, reviewer, or both) and how many review drafts they owe per cycle. It should be used when the user wants to know which cycles affect them right now - 'what cycles am I in?', 'am I a reviewer or a reviewee in Q1?', 'which cycles am I behind in?'. Returns cycle-level aggregates only (counts), not the draft content itself. Each result includes the cycle id, name, type, state, start/end timestamps, the user's role in that cycle, and counts of open drafts authored by the user and shared reviews about the user. A cycle is considered 'reviewee participation' only once at least one review about the user has been shared - cycles where the user is enrolled as a reviewee but has not yet received a shared review do not appear under that role. Does not return cycles the user is not participating in, the questions on the form, or other reviewees in the cycle. To guard against runaway queries the underlying fetches are capped, so a user with extensive review history may see an incomplete cycle list; the response includes a `truncated` flag when this happens. When `truncated` is true, narrow the window with `dateFrom` / `dateTo` to fetch the missing cycles. Results reflect what the user is permitted to see.

Retrieves review packets (all reviews for each reviewee) from a review cycle. A review packet contains one reviewee, the date the packet was shared with them (if any), the packet's overall lifecycle `status`, an optional overall summary, plus all their reviews (self, downward, upward, peer) that have been submitted or shared. Each review carries a `cycleId` and answers referencing a `questionRevisionEntityId`, and answers may reference a `goalEntityId` or `competencyEntityId`; look these up in the top-level `cycles`, `questions`, `goals` and `competencies` maps (keyed by id) rather than expecting them inline on the review, since the same definitions are shared across many reviews. A goal or competency missing from its map means its name could not be retrieved (for example, the user is not permitted to view it, or it was deleted). Competency names also require Grow competency visibility, so a user who can see the reviews but not company competencies gets none. A packet's `status` is a different concept from a review's `state`: `status` describes where the whole packet sits in the admin sharing/finalization workflow (receiving-reviews, in-calibration, not-shared, preview-shared, shared, or acknowledged - the same wording as the admin "Share Results" screen's status badge), while a review's `state` describes just that one reviewer's form. Use the `status` parameter to filter by packet status and `reviewStatus` to filter by review submission/sharing status - these are independent filters and can both be set. This tool is restricted to Reviews admins (requires ManageAllReviewsAndCalibration permission) and returns an authorization error for anyone else. Weighted scores (`weightedScore` after calibration, `weightedScorePrecalibrated` before) are not returned by default; set `includeWeightedScores` to true to include them on each packet. They can be null when no score exists or the user is not permitted to view it. Use this when an admin wants to view all finished reviews across the company for a given cycle, including questions, answers, and ratings. Results are grouped by reviewee and reflect what the user is permitted to see based on company and product access.

Writes feedback about one or more employees on the user's behalf. Use this when the user wants to give, leave, or write feedback about someone - 'give Priya feedback on the launch', 'leave feedback for my two teammates.' Passing multiple target ids creates a single feedback shared to all of them. The visibility parameter controls who can see it: 'open' is visible to everyone in the company, 'private' to the author and the target, 'only_manager' to the author and the target's manager, and 'private_manager' to the author, the target, and the target's manager. To answer a feedback request someone sent the user, pass only its id as feedbackRequestId along with the body, and leave out targetEmployeeIds and visibility: the request decides who the feedback is about and who can see it, so there is no need to ask the user about visibility. The request is then marked fulfilled. Returns the created feedback (id, body, visibility, creation time, the author, the targets, and the feedback request it answers, if any). Does not request feedback from others, edit or delete existing feedback, decline a feedback request, or tag company values. Results reflect what the user is permitted to do.

Lists every employee across the whole company for admin-scale analysis, such as picking a population to report on or audit. Unlike other lookup tools, results are not limited to the user's own reporting chain or department — this returns the full company directory, filtered by any combination of department, manager, status, job title, job function, and employee type. Returns each employee's profile (entity ID, name, title, email, department, status). Does not return org-chart relationships (reports, manager chain) or work artifacts (reviews, feedback, goals). Restricted to admins with company-wide visibility; other callers receive an error. Omit all filters to list the entire company.

Lists active departments in the user's company. Use this when the user asks about organizational structure or when you need a department entity ID to filter employees by department. Each department includes its entity ID (UUID) and name. Does not return the employees within each department or the department hierarchy. Results reflect what the user is permitted to see.

Surface goals owned by a specific employee. Use this for review-writing context, 1:1 prep, or recalling what someone has committed to over a recent period. Returns goal metadata and timeline dates plus inline owner identity (name + email already resolved). Each goal also includes the goal it is aligned to and the goals aligned beneath it, limited to goals the user can see. Each goal also includes its level (company, group, department or individual) and the department or group it belongs to. Does not return goal updates/check-ins, comments, or goals owned by other employees. Results reflect what the user is permitted to see.

Retrieves the Grow Track(s) an employee is on with the competencies for their level. Grow Tracks are structured career paths (e.g. Software Engineer) with ordered job levels (e.g. L1, L2) and competencies (e.g. Technical Skills, Communication); each competency has an expectation describing what good performance looks like at a level. Use this for review prep, coaching, or career-progression conversations. Returns the employee's identity plus a paginated array of tracks (an employee may be on more than one). For each track, when the employee's level is known you get currentJobLevel, and with includeNextLevel also nextJobLevel, each carrying that level's competencies and expectations nested inline so no id lookup is needed. When the level can't be determined or the user isn't permitted to see it, currentJobLevel is null and allJobLevels lists every level with its competencies instead, so the framework is still available. When preparing a review for someone the user neither manages nor reports on, pass reviewCycleId for a cycle in which the user is that employee's reviewer to see the track as the review experience shows it, without the specific level; when omitted, results cover the user, their reports, and (for admins) anyone. Use cursor and pageSize to page through tracks. Does not return career-vision responses, growth areas, or review/feedback content. Returns an empty tracks array when the employee has no Grow Track or the user has no permission to see it. Results reflect what the user is permitted to see.

Use this to surface the updates authored by a specific employee, for review-writing context or recalling what the employee has been reporting about their own work. Each update is returned with its inline question/answer text, sentiment (if reported), and metadata. Author identity is returned with name + email already resolved. Filter by dateFrom/dateTo to scope to a review period or other window. Does not return draft updates that haven't been submitted, or updates from other employees. Results reflect what the user is permitted to see.

Reads the published Grow competency framework so a performance rating or review comment about an employee can be interpreted against the actual bar they were measured against, and more generally for role and level comparisons. Without a trackId, lists published tracks, optionally filtered by searchQuery; with a trackId, lists that track’s levels; with both trackId and jobLevelIds, returns each competency once per page with an expectations array containing jobLevelId and expectation for each included level. Pass every level ID returned by a trackId-only call to retrieve a track’s entire ladder (all levels × all competencies) in as few calls as possible, rather than calling once per level. A missing expectation is returned as null, not inferred. Pagination and fullCount count competency-level pairs across all requested levels, not distinct competencies; a competency may recur on later pages with additional levels. Pass nextCursor as cursor to continue and combine expectations by competency ID. This tool does not return the employee’s own ratings, assignments, historical versions of expectations, or draft tracks - only the published framework a rating is measured against. Results reflect what the user is permitted to see.

Asks one or more employees to give feedback, on the user's behalf. Use this when the user wants to request, ask for, or solicit feedback - 'ask Priya and Sam for feedback on me', 'request feedback about my report Alex from his teammates.' Each target id creates a separate feedback request for that person. By default the feedback is requested about the user; pass subjectEmployeeId to request feedback about a different employee instead, for example a manager gathering feedback about their report. The visibility parameter sets the visibility of the feedback that gets written in response: 'private' (the person giving the feedback and the employee it is about), 'only_manager' (the person giving the feedback and that employee's manager), 'private_manager' (the person giving the feedback, the employee it is about, and that employee's manager). Returns the subject the feedback is about and the created requests, each with its target and request id. Does not write feedback directly, and cannot send requests to people outside the company. Results reflect what the user is permitted to do.

Saves answers to an open performance review draft. It should be used when the user wants to record or update their answers on a review they're authoring. Works whether the review currently has no saved answers or partial ones; the answers passed in this call replace any previously saved answers for the same questions. This call does NOT submit the review — it remains an editable draft after saving. Does not create new reviews or change the review's assignment; only saves answer content on an existing draft. Returns the saved state of the review, including the resulting status and the persisted answers.

Saves or updates answers, sentiment, and public flag on the user's current-period update draft. Use this when the user wants to fill in their weekly update - 'save my answers as a draft', 'set my sentiment to 4', 'mark my update as public.' Supports partial saves: answers not included in this call are left untouched; pass `body: null` on an answer to clear it. Does not submit or publish the draft. Returns the updated draft with the saved answers, sentiment, period info, and last-modified timestamp.

Saves the current user's overall manager summary for an employee in a review cycle. It should be used when a manager (or the employee's designated summary writer) wants to record or update the free-text summary they leave on that employee's review. This is a single free-text summary, distinct from question-by-question review answers. Saving replaces any summary the user previously saved for that employee in that cycle. This call does NOT submit, finalize, or share the summary with the employee; it only stores the text. Writing is only permitted when the cycle is set up for manager summaries and the user is the employee's manager or designated summary writer. Returns the saved summary id, the stored text, and when it was last updated.

Submits a performance review draft, transitioning it from drafted to submitted. Only call this tool when the user explicitly asks to submit or explicitly confirms submission of this specific review. Requests such as "write my review for X", "draft my review", "save my answers", or "looks good" do not authorize submission. If submission intent is unclear, ask for explicit confirmation before calling this tool. Never submit automatically after drafting, saving, or validating a review, even when every required answer is complete. The review must already be in drafted state with all required questions answered; submitting an incomplete or unstarted review will fail. Once submitted, the reviewer cannot undo submission or continue editing it as a draft. Does not save answers — answers must be saved before submitting. Returns the resulting review state and submission timestamp.

Submits (publishes) the user's drafted update and sends it to their manager. Use this when the user has finished their update and wants to submit it - 'submit my update', 'publish my update', 'I'm done with my update.' On submission the manager is notified, and if the update is marked public it becomes visible to others in the company, where the company allows public updates. Submitting an update that is currently published returns an error. Until the manager marks it reviewed, a submitted update's answers can still be revised, and the user can clear it back to an empty draft in Lattice, which discards its answers and requires submitting again. This does not create or edit answers, sentiment, or the public flag; those are saved onto the draft beforehand. Returns the submitted update with its answers, sentiment, period info, and the submission timestamp. Results reflect what the user is permitted to do.

Updates an existing goal with new information. Use this to modify goal details after creation - 'update my goal deadline', 'change the priority', 'update the target amount'. Can also publish a draft goal by setting isDraft to false, which makes it visible to others. Supports partial updates, so include only the fields you want to change. Can also align the goal under a parent goal, change its parent, or remove it. Can also change the goal's level to individual, company or department. Can also make the goal private and share it with departments or groups. Returns the updated goal with all current metadata.

Validates an open performance review draft by returning the questions that still need required answers, and whether submission is currently locked for reasons other than missing answers. Each unanswered question includes the question text, description, and which parts of the form are required (comment and/or rating). It should be used when the user wants to know what is left to complete on a specific review they are writing, including whether the form can actually be submitted yet. Submission can be locked when this is a manager review in a cycle where managers submit last and other reviews of the reviewee are still open, or when the cycle has not launched yet during peer selection; the form can still be drafted in those cases. Only applies to open drafts the user is currently authoring; submitted, shared, or closed reviews are not included. Does not return questions that are optional or already have all required fields filled in. Results reflect what the user is permitted to see.

Returns the identity of the current user — their employee profile (entity ID, name, title, email, department) and their manager's profile. Use this when you need to know who is making the request or to get the user's own entity ID for use with other tools. Does not return the user's direct reports, reviews, goals, or other work artifacts.