Run your weekly Lever pipeline review and decide in the app

Build an app that my recruiter and hiring manager open together during our standing weekly pipeline review, a meeting that runs at the same day and time each week for about thirty minutes. It reads from Lever, writes decisions back to Lever, drafts documents with Google Docs, and posts to Slack using Slack Bot. Nothing runs on a schedule: two people open this app at the start of the meeting and work out of it for the whole call. The goal that shapes every decision in the build is that when the meeting ends, nobody has to open Lever in a second tab and retype what we just agreed.

The app looks at one posting or requisition at a time, never a portfolio of every open role at once. Start with a picker that lists the open roles using List Postings, resolves the requisition each posting belongs to with List Requisitions so I can pick by requisition code or headcount when that is how we think about the role, and remembers whichever role we reviewed last so reopening the app drops us back where we were.

Once a role is selected, the main view is that role's whole pipeline laid out as columns, one column per stage, in Lever's own stage order rather than an order I invented. Read the stage list with List Stages and the candidates with List Opportunities filtered to that posting. Every active candidate on the role is a card in the column for their current stage. Within each column, the candidates who have sat longest float to the top, because the point of the meeting is to work through the people who are stuck rather than the people who are moving fine on their own.

Each card shows the candidate's name, the owner responsible for them, how many days it has been since that candidate last advanced, and their latest interview feedback so we can actually talk about the person without leaving the app. Pull feedback with List Feedback on an Opportunity and show the most recent submitted form, summarized down to something readable on a card with the full text available on click. Pull notes with List Notes on an Opportunity and surface the most recent one the same way. Resolve the recruiter, the hiring manager and the collaborators on the role with List Users with Access to a Posting, and let me filter the board down to just the candidates a given person owns.

Be careful with time. Lever timestamps including createdAt and lastAdvancedAt are Unix milliseconds and not ISO strings, so parse them as numbers. Days since the candidate last advanced is computed from lastAdvancedAt, not from createdAt, which measures something different and would make long tenured candidates look stuck when they are actually progressing. Total age in the pipeline comes from createdAt when I want it as a secondary number on the card.

Fetch efficiently, because a busy role has a lot of candidates and the board should feel instant during a live meeting. The Lever list endpoints accept repeatable expand parameters, so expand applications, contact, owner, stage and stageChanges on the opportunity list instead of firing a separate request per candidate. Pagination is opaque cursor based: pass the next value as the offset parameter and keep going while hasNext is true, so a role with hundreds of candidates loads completely rather than silently truncating at the first page.

We decide inside the app during the meeting, so every card carries three actions that write straight back to Lever. First, move the candidate to the next stage with Update Opportunity Stage, defaulting to the next stage in Lever's order but letting us pick any stage, including moving someone backwards. Second, add a note with Create Note on an Opportunity, so the reasoning behind a decision is captured on the candidate while we are still talking about them. Third, archive the candidate with Archive or Unarchive Opportunity, choosing from our own archive reasons rather than a hardcoded list, which means the reason dropdown is populated from List Archive Reasons. The same action restores someone we archived by mistake, so an undo is always available.

Attribution matters more here than in most apps, so build it in rather than leaving it as an afterthought. Lever write operations accept an optional perform_as query parameter carrying a user id, which attributes the action to that real person in Lever's audit log. When the hiring manager clicks advance, that stage change should show up in Lever as the hiring manager doing it, not as whoever happens to own the integration connection. Ask each person to match themselves to their Lever user the first time they open the app, resolving the choice against the users on the role, remember it for them afterwards, and pass their user id as perform_as on every stage change, note and archive they trigger.

Two filtering rules should be baked in rather than exposed as settings. Archived candidates stay off the board, so the columns show only the people we would actually discuss. Confidential postings and opportunities are excluded by Lever unless the credential holds the confidential access scope and the request explicitly opts in with confidentiality set to all, so by default the app should quietly skip them and never half render a confidential candidate or surface an error about one.

Put a Prep this review button on the board that kicks off a background agent for the selected role. The agent walks every active candidate on that role, reads their interview feedback and their notes, and for each one writes two things back onto the card: a one line status describing where the candidate genuinely stands, and a recommended next step that names a specific action rather than a vague nudge. Save that output in the app keyed to the role and the week it was generated, show progress while the agent runs since reading every candidate takes a moment, and keep the previous run readable while a new one is still generating.

The same agent also drafts the meeting agenda into a Google Doc, creating it with Create Document and filling it with Batch Update Document. The agenda is ordered the way the meeting should actually run, leading with the candidates who have been stalled longest and the stages where work keeps piling up, then the candidates moving normally, and it names the owner against each item so it is obvious who is expected to speak. Link the finished document from the board so we can open it at the top of the call, and remember the link for the role so last week's agenda is one click away.

Log every decision made during the session, which candidate moved to which stage, which notes were added, and who was archived with which reason, along with the person who made each call. Reflect each decision on the card immediately so nobody wonders whether it saved, and reconcile against Lever afterwards so the board never drifts from the real state. Then give me a second button that posts the decisions recap to our hiring Slack channel when the meeting ends, using the Slack Bot Send a Message action. The recap covers only the decisions from that session, groups them by candidate rather than dumping a flat event log, names who made each call, links the agenda document, and lets me confirm or change the target channel before it sends. Show when the recap was last posted so the same meeting does not get announced twice.