Contract Hub is a native part of the Talkpush CRM, replacing the standalone e-signature product for companies that turn it on. A recruiter builds a contract, chooses who signs it, writes the message that carries the signing link, and publishes. From there, the CRM issues, sends, collects, and files the signed document — no second product, no separate login, and no autoflow to wire up.

Contract Hub appears in every manager role’s product menu, including limited managers. Company-level settings, like sealing and default link expiry, are restricted to users with Owner access.

Contracts stop being a side errand. Instead of routing a candidate to a separate e-signature account and hoping the status makes it back into the CRM, the whole loop — building the document, sending it, watching it get signed, and filing the result — happens in the same place recruiters already work.

Before the page-by-page detail, here is the whole loop end to end:

The sections below walk through Contract Hub in that same order: turning it on and setting company defaults, then building and sending a contract, then what the candidate sees, and finally how to track everything through to a signed, filed document.

Contract Hub is turned on per company — reach out to your Solutions Engineer or Account Manager if you'd like the native Contract Hub enabled. When enabled, Contract Hub appears in the product menu with its own left sidebar: Dashboard, Contracts, and Signing. Every manager role, including limited managers, has full access to all three; company-level settings follow the usual Company Settings owner gate.

The Dashboard is what you land on every time you open it, and it is meant to answer "where do things stand" at a glance:

This is where the contract configuration happens — building a contract, deciding who it targets, and preparing the document itself. The Contracts tab lists every contract you’ve built, with its CT- number, description, status chip (Draft, Published, or Archived), signers, a summary of its targeting, and when it last changed. Contracts sit under Active and Archived tabs, are searchable by name, and sort with the newest change first.

Each row has a menu that adapts to that contract’s status, offering some combination of: Edit, Preview, Duplicate, Publish or Unpublish, Download settings, Revert unsigned sessions, History, and Archive or Restore.

A Signing Order tab groups contracts that can reach the same candidate; drag them into the order their documents should appear in that candidate’s signing session.

Click New Contract to open the wizard. It’s five steps, saved as a draft as you go, so leaving and coming back keeps your work:

Finish hands you to the editor.

Once the wizard hands you to the editor, this is where the document you uploaded turns into something a signer can actually fill out and sign — placing a Sign Here field for each signer, text fields for things like a start date or salary, and any other inputs the contract needs. Nothing is fillable until a field is placed for it.

Two routes get you there, depending on what you uploaded: keep a PDF as-is and you get preview-only (overlay); anything else opens as editable. The header, side rail, and publishing controls are identical either way.

Header — controls that sit above the document itself:

Editable document route — when the text is yours to write and fields sit inside it like words:

Preview-only (overlay) route — when the PDF’s pages stay exactly as uploaded, with fields drawn on top:

The side rail holds everything else you’ll need while building:

Once every field is placed, the document is ready. It still is not going anywhere on its own, though — that is what publishing is for.

There’s no separate "send" step — publishing a contract is what sends it. When you click Publish, a dialog confirms the campaigns, folders, and conditions the contract fires on, plus an option to also send it right away to candidates already sitting in those matching folders, with a count of how many that is. From that point on, any candidate who lands in a matching campaign and folder is issued the contract and sent the message automatically, on the schedule you set in Message and Reminders — no autoflow action to configure.

Publishing takes a snapshot of the document — that snapshot is what candidates read; further edits go into a working copy that nobody sees until you publish again. Once a contract is live, Publish wakes back up the moment the working copy differs from what’s published. Pressing it moves every document nobody has signed yet to the new version, keeping any answers already saved; a document someone has already signed keeps the version they signed, so the final PDF always matches what was actually agreed to. Unpublish stops the contract from being issued to new candidates — anyone who already has a link can still finish signing.

From here, a candidate who matches your targeting gets their link automatically — see How It Looks for the Candidate for what they experience, or skip ahead to The Signing Page to track it.

Need to change something later? Open a contract from the Contracts list, its preview page, or the editor URL directly. A draft autosaves and can be published whenever it’s ready; an archived contract needs to be restored first. The read-only preview page shows the document with its fields highlighted, alongside the contract’s info (number, status, dates, signers, targeting), its download settings, and its full change history.

This is the Sign step from How It Works — what happens once a candidate reaches the campaign and folder configured in Targeting. That is what triggers everything below: they are issued the contract automatically and receive the message set up in Message and Reminders, carrying their signing link. Each candidate gets a single link, no matter how many documents are in their session. The experience is branded to match your company — header with your logo, your primary color, your footer — and follows the campaign’s language (falling back to the company’s country), with the same translations as your careers site and no language switcher. Here’s what a candidate sees:

Other signers — a hiring manager or legal contact, for example — get their own personal link by email and go through the same pages, seeing only their own fields. Where the company has enabled it, an AI assistant is available in a side panel to answer questions about the document’s text, in the page’s own language.

Once signatures start coming in, The Signing Page is where you watch it happen.

This is the Monitor and view step from How It Works. The Signing page lists every signing session as a table, one row per candidate. Here’s how to read it, piece by piece:

Status Tabs

All, Pending, Sent, Viewed, In progress, Completed, Declined, Expired, Voided — each shows a live count, so you can jump straight to the sessions that need attention. See Document Statuses for what each one means.

Filters

Search candidates finds someone by name, All contracts narrows the list to one specific contract, and the date picker (Any time by default) filters by when the session was created.

Candidate Table

One row per candidate, showing their overall Status, a Documents column with two stacked progress bars (documents complete, and signers out of the total who’ve signed), when the session was Created at, and when it was Last updated. Check the boxes on the left to select several rows at once for bulk actions.

Row Actions

Each row’s own menu — the same actions available inside the session detail, without opening it:

Export to Excel

Top right of the page — downloads exactly the filtered list you’re currently looking at.

The Signing page’s status tabs, search, and filters are the fastest way to see where every candidate stands across the board. When you’re already looking at one candidate, the same information sits on their own profile: a matching Contracts tab appears right after Documents, listing their sessions with the same actions available there. Three candidate attributes mirror the session’s rolled-up status, so your existing filters, exports, and autoflows built on them keep working without changes: contract_hub_link, contract_hub_status, and contract_hub_signing_date.

Click any row — or a Recent signing activity item on the Dashboard — to open the session detail. The header names the candidate, their overall status, and the campaign the session belongs to, with three tabs underneath:

Once every required signer has signed, the finished PDF is available two places: right there in the session detail’s Documents panel, downloadable from that document’s row; and filed under the candidate’s own Documents tab on their profile, tagged with the contract’s name, with the signing certificate appended. The certificate itself is the company’s own record and isn’t handed to signers directly — where you’ve allowed it, candidates can download their own signed copy from their Done screen once the configured delay has passed.

These are the statuses referenced throughout Contract Hub — on the Dashboard’s stat tiles, the Signing page’s status tabs, and the candidate’s own profile. Each document tracks its own status. The session shown to the candidate — and the status written to the candidate attribute — reflects the combined status of all its documents:

For a company already using the legacy e-signature app, here is how the two coexist during the switch.

With the flag off, nothing changes and the legacy integration runs as before. With the flag on, the Send to Contract Hub autoflow action goes dormant and writes a line to the candidate’s timeline instead of running; the legacy app’s writes to the three candidate attributes above are dropped for candidates the native module owns; candidates already holding a legacy signing link are left alone; and any signed PDFs the legacy app uploads for contracts started before the switch are still accepted.

The recommended path per client: rebuild the contracts natively, turn the flag on, let any in-flight legacy sessions finish, have your Talkpush contact stop the periodic legacy sync, then publish. A few things are deliberately not carried over from the legacy product: its accounts, roles, and logins; its company management screens; its sync history and monitors; its scheduler lane; its analytics; and any companies that only exist in the standalone app.