Feature guides

Sequential stages, parallel reviewers: how flows advance

A review flow is a stack of stages. The rule is simple and worth memorizing: stages run top → bottom in sequence, and reviewers within a stage review in parallel. A stage completes only when every reviewer in it approves; the moment it does, the next stage's reviewers are emailed automatically.

As you add reviewers on the New Contract screen, each stage shows a small pill describing its shape (illustration — sample data):

How a flow moves

1. You Create & start review. The first stage becomes active and its reviewers are emailed their review requests.
2. Each reviewer approves (or rejects) from their own emailed link. While a stage is active, its reviewers work at the same time — order among them doesn't matter.
3. When the last pending reviewer in the active stage approves, the stage turns complete and Pishik activates the next stage, emailing its reviewers.
4. When the final stage completes, the contract is marked Approved and moves to the Approved column on the Board.

You can name stages (e.g. Final legal sign-off) or leave them unnamed — an unnamed stage simply reads as Stage N. Stages can be reordered and removed while you build.

A review can't be started with zero reviewers — Pishik refuses rather than create a flow that can never advance. Building the very first flow is covered step by step in Build the review flow; splitting a contract across parts is next.

Multi-part contracts and per-document reviewer assignments

A single contract can hold several linked documents — a Main Agreement plus a Schedule, an Excel exhibit, whatever the deal needs. Each part keeps its own name, and each reviewer in a stage can be pointed at the specific part they own, so different people review different parts at the same time.

Add the parts

1. On the New Contract screen, in the Documents section, paste a share link for the first document.
2. Press Add document / part and paste the next link. Once there's more than one, a Part name field appears for each — Pishik pre-fills a name from the link where it can (e.g. Main Agreement, Schedule A) and falls back to Document N for opaque links.
3. Type your own part name any time — a name you type always wins. Clear it to hand naming back to Pishik.

Documents are share links, never uploads — the files stay in your own storage. That model, and how to scope the links safely, lives in How Pishik works with your storage.

Point each reviewer at a part

When a contract has more than one part, every reviewer row gains a reviews dropdown:

1. Add a reviewer to a stage as usual.
2. In their reviews dropdown, pick the part they own — or leave it on Entire contract (all parts) to give them everything.
3. Put two reviewers in the same stage, each pointed at a different part, and they review in parallel — that's the Parallel — split across parts shape. Their review email and decision page name exactly which part is theirs.

Save and reuse review paths

If your team runs the same shape of review over and over — Legal, then Finance, then sign-off — save it once as a path and apply it to future contracts in a click. A path stores the stages and their reviewers, not the documents.

Save a path

1. Build the stages and reviewers you want on the New Contract screen.
2. In the Review workflow section, press Save as reusable path.
3. Name it (e.g. Standard NDA) and choose its visibility: Only me (private) or Whole team.
4. Press Save.

Apply a path

1. On a new contract, open the Apply a saved path… picker in the Review workflow section and choose one. Its stages and reviewers drop straight in.
2. On a multi-part contract, re-point each reviewer at the right part — per-part assignments are re-picked per contract, since parts differ every time.

Who can edit a path

• Private paths belong to you alone — only you can apply, rename, or delete them.
• Team paths can be applied by everyone, but only an admin can edit or delete them.

Manage all your paths — rename, change visibility, delete — from Settings → Review paths. You can also delete a path inline from the Manage control next to the path picker.

Remind and resend: manual nudges vs. the automatic schedule

Three separate things chase a quiet reviewer. Knowing which is which saves confusion:

Nudge manually

1. Open the contract and find the Review flow. Each active, pending reviewer's node carries a remind and a resend button.
2. To nudge everyone still pending on the active stage at once, use Remind all in the Actions section.
3. Prefer to work from the outbox? The Sent page's Awaiting reply zone lists everyone mid-review with the same resend and remind buttons.

Let Pishik chase for you

Automatic reminders send themselves on a cadence you control — every 1–30 days, up to a total cap per reviewer, at a time on your own clock — and they stop after 45 days of silence, where a human decision is needed instead. Manual nudges never count against the automatic cap. The full setup — and why reminders sometimes don't fire — lives in Configure automatic reviewer reminders.

A reminder needs an email channel configured for your workspace; how mail is delivered is covered in Send email from your own domain. If a reviewer says the mail never arrived, work through A reviewer didn't get the email.

Handle a rejection: resolve, resend, or revise & restart

When a reviewer rejects, the flow halts, the contract lands in the Needs Attention column, and the rejecter's comment is shown so you know what to fix. From there you have two recovery paths depending on how big the change is.

Small fix → resolve & resend to the rejecter

You addressed exactly what they flagged. Send it back to just that reviewer for another look — everyone else's approvals stay intact.

1. Open the contract. Under Rejected — resolve & resend, you'll see each reviewer who rejected, with their comment.
2. Press Resend on that reviewer. Their earlier decision is cleared, a fresh single-use link is issued and emailed, their stage reactivates, and the contract returns to In Review.
3. If several reviewers rejected, Resend to all handles them together.

Bigger change → revise & restart

The revisions were substantial enough that the whole flow should run again. Revise & restart resets the contract to Draft so you can rebuild the workflow from scratch.

1. From the contract's Actions (or the link under Rejected — resolve & resend), press Revise & restart.
2. The contract returns to Draft with brand-new review links. Every prior decision is cleared and every old link is invalidated.
3. Adjust the flow if needed, then Start review again.

Change a review that's already running

You can add a review stage to a contract at any point in its life — while it's a draft, while it's in review, or even after it's been fully approved. The new stage always runs after the current ones.

Add a stage to a live contract

1. Open the contract and find the Review flow. Press Add reviewers.
2. In the Add a review stage panel (it notes "runs after the current stages"), give the stage an optional name.
3. Pick reviewers from your book — or add a brand-new one inline — and, on a multi-part contract, point each at a part.
4. Press Add stage. Reviewers you add together review in parallel; the stage completes only when they all approve.

This is also how someone completes a contract that was handed to them without a workflow — see Assign a contract to a teammate.

Adding a stage to an already-approved contract reopens it

If the contract was already Approved, adding a stage reopens it and immediately routes the new stage for review. One consequence is important enough to spell out:

So: adding a late stage to a live review costs you nothing; adding one to a signed-off contract is a deliberate reopening — quick to do, but worth doing with eyes open.

Record a decision on a reviewer's behalf

Sometimes a reviewer answers outside their link — a phone call, a hallway "yes", a plain reply email. A signed-in teammate with edit rights can record that approve or reject for them, and Pishik keeps the record honest about who actually entered it.

How to record one

1. Open the contract. In the Actions section, find Act on a reviewer's behalf — it lists each reviewer still pending on the active stage.
2. Press the reviewer you're recording for. Their decision page opens with a banner: "You (your name) are recording this decision on behalf of the reviewer. The activity log will show it was entered by you — and only they can speak in their own words, so the reviewer-comment box is locked."
3. Choose Approve or Reject, add an optional note explaining why you're entering it, and confirm.

Afterward, the Activity timeline reads "X (recorded on behalf of Y)", the decision appears under Reviewer notes tagged "entered by X", and the reviewer is automatically emailed a notice that a decision was recorded in their name — skipped only if they have no email on file or recorded it themselves.

Send a status update — and control exactly what it reveals

Need to tell a reviewer or an outside counterparty where a contract stands? Send a branded status email straight from the contract, with precise control over how much it discloses. The body is always composed fresh from live contract data, so it's accurate the moment it sends.

Send one

1. Open the contract and press Status update in the Actions section.
2. Under Send to, choose A reviewer (pick from your book) or Other party (type any name and email — external counterparties are first-class here).
3. Write a short Message if you like; a live Preview on the right shows exactly what the recipient will get.
4. Press Send status update. Pishik sends it and logs it.

The disclosure controls

Two settings decide what the email shows. First, How much of the flow to show:

Then, under Include, toggle individual details: Reviewer names, Approve / reject outcomes, Decision dates, and What's coming up next. (These toggles are disabled under General status only, which hides all of them by design.)

The starting defaults for these controls come from Settings → Email content → Status; set them once and override per send. That's covered in Customize the emails Pishik sends.

Comments and @mentions: discuss contracts without leaving them

Every contract has a threaded discussion for your team, in the Comments & mentions section of the contract detail. It's for the people working the contract — kept separate from your owner-private notes and from Reviewer notes (the comments reviewers leave with their decisions).

Who can see and post

A thread is visible to the contract's owner, admins, delegates, and any teammate tagged into it. Owners and admins can comment on any contract; a regular user can comment on contracts they own, hold delegated access to, or were @mentioned into.

Post, reply, and tag

1. Type in the composer ("Write a comment — @ tags a teammate…"). Press Cmd + Enter (or Ctrl + Enter) to send, or click Comment.
2. To pull someone in, type @ or press Tag someone and pick a teammate. Tagged names are highlighted in the text; you can tag up to 10 people per comment.
3. Tick Also email them to send an email alongside the in-app alert. Without it, tagged people are notified in-app (and by email only if they or your workspace have that turned on).
4. To keep a side-conversation tidy, use the reply icon on a comment. Replies group under the original — a reply to a reply flattens into the same thread rather than nesting endlessly.

Edit and delete

• Edit your own comment any time — it's marked · edited, and the audit log keeps the original wording. Editing is author-only; even an admin can't edit someone else's words.
• Delete your own comment (admins can remove anyone's). The comment keeps its place as a "Comment removed by … — the audit log keeps the history" tombstone; the wording disappears everywhere, and any open @mentions attached to it are dismissed so they stop chasing people.

What lands in an inbox

Mention emails are deliberately content-free: they say who tagged you, on which contract, and give a link — never the comment text — so contract details never sit in inboxes. Your personal mention-email preference always wins: an explicit never is honored even if a commenter ticks Also email them. Set yours under Personal preferences. Mention emails need an email channel configured; without one, mentions are in-app only.

Threads live-refresh every few seconds while open, so everyone sees new comments without reloading. A thread holds up to 500 comments and each comment up to 2,000 characters — if a discussion truly fills up, resolve it and start fresh or move context into notes. The lifecycle of a mention — seen, resolved, nudged, escalated — is its own guide, next.

The mention lifecycle: seen, resolve, dismiss, nudge, escalate, reopen

Every @mention is tracked from the moment it's created until it's closed out, so internal follow-ups get the same accountability as reviewer requests. Your open mentions collect in the Tagged items card on your Dashboard, and each one carries a status.

What each person can do

• If you were tagged: Resolve it when you've handled it, or Dismiss it if no action is needed. Opening the thread already marks it Seen for you.
• If you did the tagging (or you're an admin): you can Resolve or Dismiss the mention, or Nudge the person again (a reminder email plus in-app alert).
• Stuck and unanswered? Either party — tagger or tagged — can Escalate to the admins. Every admin gets an email explaining who tagged whom and how long it's been open. A mention can be escalated once.
• Closed by mistake? Reopen a resolved or dismissed mention to send it back to Pending.

Hovering a mention chip shows its full history — tagged by whom, whether it was emailed, when it was seen, and how it was closed.

Notes, to-dos, reminders, and supporting document links

Each contract has a private working area — Notes, checklist & reminders — for the owner's own context. It's the collapsible section on the New Contract screen and on the contract detail. Everything here is owner-private: view-only teammates never see it, and it's kept apart from team comments and from reviewer notes.

Use them

1. Open the contract and expand Notes, checklist & reminders (the summary line shows what's already there).
2. Write in Notes; add checklist items with an optional due date; add reminders with a date; paste reference links under Supporting documents.
3. Board cards flag when a contract has notes, open to-dos, reminders due soon, or attached reference docs, so nothing gets lost.

Deadlines, priority flags, and overdue detection

Two different signals keep urgent work visible: a deadline on the whole contract, and overdue detection on an individual reviewer who's gone quiet. They're easy to confuse, so here's each one plainly.

Contract deadlines and priority

Set a deadline and toggle high priority from the contract's Assignment & deadline area. Only the owner, a delegate, or an admin can change them. The deadline renders as a colored chip wherever the contract appears:

A deadline chip disappears once the contract is Approved or archived — a settled contract isn't "late." The chip is about the whole contract; it doesn't track individual reviewers.

Overdue reviewers

Separately, a reviewer who hasn't decided is flagged Overdue on the board card, the flow map, and the Sent page's awaiting list once they pass the workspace's threshold. The count starts from the last time that reviewer was emailed — so sending a reminder resets their overdue clock.

Signature and execution tracking

Once a contract is approved, Pishik helps you track execution — who has signed and when — and hold the link to the final signed document. Two things to be clear about up front:

Track who has signed

On an approved contract, open the Signing & execution section:

1. Tick Our side when your side signs, and Counterparty when they do. Each records the date; press Edit on a signed row to correct the date if someone ticked it late.
2. The status pill tracks the overall state: Awaiting signatures → Partially signed (1 of 2) → Fully executed.
3. When both parties are marked signed, the contract reads Fully executed, admins are notified, and it moves to the Signed column on the Board.

Attach the executed document and archive

1. Under Signed agreement, press Link signed agreement and paste the share link to the final signed file, with an optional label. It's then one click away from the board card, the contract detail, and the repository row — same links-not-uploads model as everywhere else.
2. Press Archive to repository to move the finished contract off your board for safekeeping (you can Restore from repository any time). Pishik tips you to archive once fully executed, but never forces it.

Understand your analytics

Analytics live on the Statistics tab of the Dashboard. Everything is drawn from your own workflow data — no external analytics, ever — across three panels.

Contracts by type

A breakdown of your contract portfolio by type, switchable between a donut (with a center total) and a horizontal bar view. Empty until you've created contracts.

Decision insights

Three headline numbers plus a volume chart:

• Decisions logged — total reviewer decisions recorded.
• Avg. to decide — how long a reviewer takes to respond, on average.
• Avg. full cycle — average time from a contract's creation to completion.
• Volume · last 6 months — Created vs. Completed bars, month by month.

Reviewer performance

A per-reviewer table you can filter by name and department, and sort by decisions or average time. Its columns:

Export a contract record

Export any contract as a clean, print-ready record — for filing, for your records, or to share outside Pishik. You choose exactly which sections go in.

Export it

1. Open the contract and press Export in the Actions section.
2. In the Export contract dialog, tick the sections to include (or Select all / Everything). The available sections are: Summary & status, Documents, Review flow & decisions, Reviewer notes, Internal notes, Checklist, Reminders, Supporting documents, and Activity log.
3. Export. Pishik downloads a standalone HTML file.
4. To make a PDF, open the file and use your browser's Save as PDF (Print → Save as PDF).

Every export is recorded — in the contract's Activity timeline and in the admin audit trail, with who ran it — so a record leaving the workspace is never invisible. For exporting a whole workspace or your own personal data (rather than one contract), see Export and restore.