Lattice

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. 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.

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.

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`; look these up in the top-level `cycles` and `questions` maps (keyed by id) rather than expecting them inline on the review, since the same cycle and question definitions are shared across many reviews. 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. 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. Returns the created feedback (id, body, visibility, creation time, the author, and the targets). Does not request feedback from others, edit or delete existing feedback, 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). 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.

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. It should be used when the user has finished writing a review and is ready to finalize it. The review must already be in drafted state with all required questions answered; submitting an incomplete or unstarted review will fail. Once submitted, the review is no longer editable 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, finalizing it and sending 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.' Submitting is final: an update can only be submitted once and cannot be returned to a draft, and on submission the manager is notified and any answers marked public become visible to others in the company. 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'. Supports partial updates — include only the fields you want to change. 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.