User & team management

Everything about the people in your workspace: inviting them, setting what they can do, moving work between them, covering for each other, and offboarding cleanly — with nothing ever silently deleted or transferred.

Invite teammates and set roles

People who sign in to build and manage review flows are members of your workspace. (The reviewers who approve contracts by email are different — they never sign in and never need an invite. See Seats explained.)

You need: an admin or owner role. Members are managed under Settings → Team & users.

Send an invite

  1. Open Settings → Team & users and click Invite people.
  2. Enter each person's name (optional) and email, and pick their role — User or Admin. Use Add another to invite several at once.
  3. Click Send invites. Each person gets an email with a personal link to set their own password.
  4. If email delivery isn't set up for your workspace, Pishik hands you a copy-and-share invite link for each person instead.

An invited person shows an amber Invited pill until they accept. Each pending invite holds a seat until it's used.

The three roles

RoleWhat they can do
OwnerExactly one person per workspace. Everything an admin can do, plus transferring ownership. The owner can't be removed or archived.
AdminManages the workspace: team & users, seats, settings, reviewers, delegation, and the audit log — on top of creating and routing their own contracts.
UserCreates and routes their own contracts, and can follow any contract for context. Can't change workspace settings or manage other people.

To change someone's role later, open their row's menu in Team & users and choose Make admin or Make user. Promoting or demoting is confirmed first, because admin access is real power. Roles aren't set on the owner's row — to move ownership, see Transfer workspace ownership.

Treat invite links like passwords. An invite link lets whoever opens it set the password for that account, so anyone holding the link can claim the seat. Send it only to the intended person over a channel you trust. Invite links also expire after 30 days — if one lapses, re-send it (see below) to mint a fresh single-use link and invalidate the old one.

Seats explained: who needs one

A seat is for a person who signs in to Pishik to build and manage contracts — that's the owner, admins, and users. The Settings → Team & users header shows your usage as “X of Y seats used”, with the reminder: people who sign in to manage contracts — reviewers stay free.

What counts against your seats

  • The owner, every admin, and every user — one seat each.
  • Pending invites, too: an invitation holds a seat from the moment you send it until it's accepted or cancelled.
  • Archived (former) members do not use a seat — archiving someone frees theirs. See Offboard a teammate.

Why email reviewers never need a seat

Reviewers receive a personal email link, open the document in your own storage, and approve or reject on a hosted decision page. They never create an account, never sign in, and never see your workspace — so they never consume a seat. That's why you can send a contract to as many reviewers as you like. Adding reviewers to your reviewer book is covered in Add reviewers.

During the private beta, each workspace has a fixed allowance of seats. When you're full, the Invite people button is disabled until you free one up (archive someone who's left). For the commercial side — that reviewers are always free and unlimited, and how seats work once billing arrives — see Seats and reviewers and Billing during the beta.

Assign a contract to a teammate

An admin can create a contract straight into another member's workspace — useful when the person who spots a contract isn't the person who should run it. The contract lives in the assignee's workspace from the start, with your written instructions attached.

You need: an admin or owner role. (A regular user creating a contract always owns it themselves; to move an existing contract to someone else, see Reassignments and hand-offs.)

Create and assign

  1. Click New contract and give it a title and at least one document share link.
  2. Under Assign to, pick the teammate. As the app notes, the contract lives in the assignee's workspace — it appears in their inbox with your instructions, and they get an email.
  3. Add Instructions for them (optional) — context, priority, what to watch for.
  4. Choose Assign to [name] to hand it over as a draft, or Assign & start review if you've already built the flow and want the first reviewers emailed right away.

You can sketch the review workflow for them or leave it blank — the assignee can build and start the flow from their own workspace. Every assignment is recorded in the activity trail with you named as the assigning admin.

What the assignee sees

The new contract lands in a highlighted New — assigned to you inbox on their Dashboard, showing who assigned it and your note, and they get an email. Opening the contract acknowledges it — that clears the “new” badge automatically; there's no separate acknowledge button.

Reassignments and hand-offs

Reassigning moves an existing contract to another member's workspace. Pishik never transfers a contract silently — a move is always requested and approved (or accepted), and every step is logged.

How a move happens depends on who starts it

  • A user requests it. From the contract, choose Request reassignment, pick the new owner, and add an optional reason. The contract stays with you until an admin approves — it doesn't move on request.
  • An admin reassigns to a user. Choose Reassign contract and it applies immediately; the new owner is emailed.
  • An admin hands off to another admin. The receiving admin must accept first — as the app puts it, no silent hand-offs between admins. Choose Send hand-off and they're emailed to accept or decline.

You need: to own the contract to request its reassignment; an admin role to reassign directly or to approve others' requests.

Approve, deny, or chase a request

  1. Admins review pending reassignments in the Dashboard → Queue (the approval queue), and approve or deny each.
  2. The requester sees the live status on their own Dashboard and can cancel a pending request, or remind the person who owes a decision.
  3. On approval the contract moves and the new owner is emailed; on denial the requester is notified.
Requests expire after 14 days. A reassignment request (or an admin-to-admin hand-off) that nobody acts on is marked expired automatically, so stale requests never linger. Just submit a fresh one if it's still needed. Note that a delegate covering someone's workspace can edit that person's contracts but can't request a reassignment.

Delegate your workspace while you're out

Going on leave? Hand your whole workspace to a teammate for a set window. They can act on your contracts during that time, everything they do is logged under their own name (marked as delegated), and access ends on its own — nobody has to remember to switch it off.

You need: anyone can request delegation of their own workspace; an admin's grant takes effect immediately, while a user's request waits for admin approval. Delegation lives under Settings → Delegation.

Set it up

  1. Open Settings → Delegation and click to Delegate a workspace.
  2. Choose Delegate to — the teammate who'll cover for you. (Admins also pick Whose workspace is being delegated.)
  3. Set the Starts and Ends times, and add a Reason (shown to the admins and logged).
  4. Click Grant access (admins) or Request approval (users). Admins approve or deny pending requests from the same tab or the Dashboard queue.

The delegate sees the covered contracts on their own board with a banner naming whose they are and until when.

Extend, end early, and the automatic warning

  • Coverage ends automatically at the end time. In its last 24 hours it shows an Ends soon flag, and admins are emailed that a delegation ends within 24 hours.
  • An admin can extend an active delegation or end it at any time; the owner or the delegate can also end it early, and a pending request can be withdrawn.
Admin workspaces can only be delegated to another admin. Since covering an admin means inheriting admin reach, the delegate must already be an admin. Delegations are also capped at 180 days — extend later if a longer absence needs it.

Offboard a teammate

When someone leaves, you archive them rather than deleting anything. Archiving signs them out everywhere, frees their seat, and hands their live contracts to whoever picks up the work — while keeping their history intact and the account restorable.

You need: an admin or owner role. The owner can't be archived — transfer ownership first if the owner is leaving (see below). You also can't archive yourself.

Archive and hand off their work

  1. In Settings → Team & users, open the person's row menu and choose Archive / remove….
  2. Decide what happens to any contracts they own: Hand everything to one person, Choose per contract, or Leave the contracts where they are (transfer them later).
  3. Optionally click Activity report in the dialog to save a snapshot for your records (see Member activity report).
  4. Confirm. As the app promises: they're signed out everywhere and their seat frees up, but they stay in the Archived list — restore them anytime, and nothing in the workspace is deleted.

Restore, transfer later, or remove permanently

Archived people are listed under a collapsible Archived group in Team & users. From an archived row you can:

  • Restore to the team — brings the account back (needs a free seat).
  • Transfer any contracts they still own to active teammates.
  • Remove permanently — a hard delete of the archived row; their contract history stays attributed in the workspace either way.

A person who was invited but never joined isn't archived — use Cancel invite on their row instead.

Transfer workspace ownership

Every workspace has exactly one owner. Ownership can be handed to another active teammate — for example when the founding owner leaves or hands the reins to a colleague.

You need: to be the current owner. Only the owner can transfer ownership; admins can't.

Hand over ownership

  1. Open Settings → Team & users and find the active teammate who should become owner.
  2. From their row menu, choose Transfer ownership.
  3. Confirm. As the prompt says, you'll become an admin — the transfer swaps the two roles in one atomic step, so the workspace is never left without an owner.

The new owner must be an active member (not invited or archived). After the transfer, you keep full admin access; only ownership itself changes hands. To reverse it, the new owner transfers it back.

Locked out? Admin-sent password resets

If a teammate can't get in, an admin can send them a password-reset link. Pishik deliberately separates resetting a joined member's password from re-inviting someone who never joined — and won't let you re-invite an active member, because that would be an account-takeover risk.

You need: an admin or owner role. This lives in Settings → Team & users. Members can also reset their own password from the sign-in screen — see Can't sign in.

Send a reset to a joined member

  1. In Settings → Team & users, open the active member's row menu.
  2. Choose Send password-reset link. Pishik emails them a link that's valid for one hour.
  3. The link goes only to the member's inbox — it's never shown to you, so an admin can't set another person's password. When they use it, their other sessions are signed out for safety.

This needs email delivery configured for your workspace; if it isn't, Pishik says so rather than pretending the mail went out.

Re-send an invite to someone who hasn't joined

For a person still showing Invited, the same menu offers Resend invite email (or Copy invite link to share it yourself). Re-sending mints a fresh single-use link and invalidates the old one — handy when the first link expired (invite links last 30 days).

Why you can't re-invite a member who already joined. Accepting an invite sets that account's password, so re-inviting an active member could let an admin overwrite their credentials and hijack the account. Pishik blocks it and points you to a reset instead: “That person has already joined — send them a password reset instead.”

Member activity report

Admins can download a printable snapshot of everything in the workspace tied to a particular member — a handy record when someone changes roles or leaves. Like every export in Pishik, generating one is recorded in the audit log.

You need: an admin or owner role.

Export the report

  1. In Settings → Team & users, open the member's row menu and choose Export activity report (it's also offered as Activity report inside the archive dialog).
  2. Pishik downloads a self-contained HTML file. Open it and use your browser's Print → Save as PDF to file it.

The report covers their Account details, Contract activity, any decisions recorded under their name, and the relevant workspace audit trail entries.

How the report is matched. Workspace records store names, not account IDs, so the report gathers entries by matching the person's name and email. It's a convenience snapshot for your records — and, as the report itself notes, removing a person from the team never deletes any of this history.

Still need a hand with your team?

Tell us your workspace name and what you're trying to do — never paste share links or confidential documents.

Contact support