Give every rep a Clay prospecting desk without a Clay seat

Build an internal prospecting desk that each of my sales reps opens daily to work their own territory. The source of truth for the list is Clay, but the reps do not have Clay seats and should never need to open Clay or fight a spreadsheet UI. Ops builds and enriches the account and contact tables centrally in Clay, and this app is the per-rep, filtered, claimable view on top of them.

The main view is a ranked worklist. Load rows with the Clay Query Tables operation against our enriched account table and contact table, and filter to the signed-in rep by matching the owner field stored on each row against the rep's identity. This filter is not cosmetic and must not be flattened into one shared table: a rep may only ever see their own territory. Query Tables is cursor paginated, so page through it and keep the worklist responsive rather than loading everything at once.

Each row renders as a card carrying the enrichment fields a rep actually decides on: contact name and job title, company name and size, and any hiring or funding signals we store on the row. Rank the list so the strongest signals sort to the top, and let the rep sort and filter by signal type, company size, and whether the record has been checked against the CRM yet.

Before a rep works a record, check it against Salesforce. Use Get Many Leads with a SOQL query matching on the record's email address, falling back to the company domain, and mark the card clearly when a matching lead already exists so reps never touch someone already in the system. Show who owns the existing lead when Salesforce returns one. Run this check as the worklist loads and cache the result per row, so the rep is not waiting on the CRM on every scroll.

Each card has a button to request deeper research on that one account. It fires our Claygent routine for just that row using Run a Routine with a single inline item, which sits well inside the 100 item inline limit. Run a Routine is asynchronous and returns a routine_run_id, so do not block the UI waiting on it. Put the card into a pending state, store the routine_run_id against the row, and poll Get Routine Run Results until the status reaches a terminal value of complete, failed, or validation_failed. On completion, stream the research summary back onto that card in place. On failure, show it on the card and let the rep retry.

The Claim button is how a rep takes a record. Claiming writes it into Salesforce with Create or Update Lead (Upsert), so an existing lead is updated rather than duplicated, then attaches the Clay research summary using Add Note to Lead. Claims must be exclusive: store the claim in the app's own storage keyed by the Clay row id along with the claiming rep and a timestamp, and enforce uniqueness on that row id so the first claim wins. The moment a row is claimed it disappears from every other rep's worklist, and a second rep attempting the same row gets a clear message that it is already claimed and by whom. Claimed rows stay visible to the rep who claimed them.

Show each rep a simple counter of how many accounts they still have left to work this week, measured as their remaining territory rows against a weekly target and counting down as they claim. It is per rep, it resets weekly, and it sits at the top of the worklist.

Clay table ids and the routine id are not discoverable through the Clay API, so give an admin a settings view to paste them in, along with the name of the owner field used for territory matching and the weekly target. If the team runs HubSpot instead of Salesforce, the same flow works with Search Contacts for the duplicate check, Batch Upsert Contacts for the claim, and Create Note for the research summary.