Customers
What this page is — who may sign in to the Papers customer portal for this project, and how they are added, suspended and invited.
What it is for — so a client who receives documents repeatedly can find all of them in one place, instead of asking you to resend links.
The problem it solves — customers ask you to resend documents they could fetch themselves, and you have no controlled way to let them.
Route: /org/papers/project-settings → Customers · Permission: Manage which customers can access the Papers document portal for a project (enroll by email, suspend/remove, send invitations)..
1. What it is
A Papers customer is a real account — one per person across the organisation — enrolled on a project.
| Layer | Holds | Scope |
|---|---|---|
| Account | Verified email, password, profile, customer code | Organisation-wide |
| Enrolment | Active or suspended | One project |
| What they see | Documents where they are a party | Matched per document |
Enrolment does not decide what a customer sees. A customer sees a document when a party on it matches them — by their account link, or by the same email, ignoring case. So documents they were invited to by magic link before they had an account appear once they sign in.
| Customer | Counterparty | |
|---|---|---|
| Logs in | Yes | No — magic link |
| Sees | Every document they are a party to, in enrolled projects | One document per link |
| Best for | Repeat business | One-off dealings |
2. Why you would use it
- "Can you resend that agreement?" stops. Clients retrieve their own documents and obligations.
- One login across projects. A client on two engagements is one account enrolled twice.
- Suspension is precise. Pausing a relationship on one project leaves their other access intact.
- The move from counterparty is free. Nothing needs re-sending when an occasional contact becomes a client.
3. Step by step
A brand-new person — Add Customer opens the CRM customer form: it creates the person properly — name, contact details, customer record — and enrols them on this project in one step.
Someone already in the organisation — Enroll → pick them from people not yet on this project. Selection, not typing: nothing to mistype.
Tell them — Send invitation email. Leave it off when enrolling ahead of an announcement.
Pause or end — set the status to suspended, or remove the enrolment.
Enrolment used to take a typed email. An unrecognised address silently created a bare portal profile with no name and no CRM record, and a typo created a second ghost account nobody noticed. Picking real people removes both failure modes. The permission's description still says "enroll by email" — the screen does not.
4. Field reference
| Control | Does |
|---|---|
| Add Customer | Creates a person via the CRM form and enrols them |
| Enroll picker | Enrols an existing person not yet on this project |
| Send invitation email | Emails them that they have access |
| Status | Only active customers can view, download, sign and negotiate. Suspended loses access to this project only |
| Remove | Ends the enrolment; the account remains |
For integrations, the API still accepts project_id and email, refusing without them: project_id and email
are required.
5. Onboarding and offboarding customers
Before the first invitation
| Check | Why |
|---|---|
| The customer portal is published | An invitation that leads nowhere is the worst first impression |
| The customer is already a party on at least one document | Otherwise they sign in to an empty portal |
| The party email on those documents matches the account email | Documents are matched by account or by email — a different address shows nothing |
| You know when they should hear from you | Invitations can be held back |
Enrolling many at once
For a launch, enrol quietly with Send invitation email off, check a couple of portals yourself, then invite everyone on the day. Nothing about enrolment is visible to the customer until they are invited or sign in.
Choosing between suspend and remove
| Situation | Choose | Because |
|---|---|---|
| A relationship is paused — a contract dispute, a lapsed retainer | Suspend | Access returns with one change, and the enrolment history stays |
| The engagement on this project has ended for good | Remove | Keeps the enrolled list honest |
| The person left the client company | Remove, then enrol their successor | The account is the person, not the role |
| They should lose access to everything | Suspend or remove in every project they are enrolled on | Enrolment is per project; there is no organisation-wide switch here |
What a customer can do once active
View and download the documents they are a party to, sign where they are a signer, and negotiate where the document's state invites it — in every project they are actively enrolled on, and nowhere else.
6. Worked example
A managed-services firm onboards Northwind Traders as a retainer client.
Dana Okoye, Northwind's contract manager, signed an NDA by magic link in January — she was a counterparty. In March the retainer starts, and the account manager enrols her:
- Add Customer — Dana has no account yet — full name, email
[email protected], phone. Enrolled on Northwind Retainer. - Send invitation email on.
- Dana signs in. Her portal shows the January NDA — her email matches the party on it — plus the new retainer agreement.
In June Northwind starts a second engagement. The manager uses Enroll on the Northwind Data Project and picks Dana; one account, two projects.
In October the data project pauses. Status → suspended on that project. Dana still sees everything on the retainer.
7. The admin contract
| Must be true | Where | What breaks without it |
|---|---|---|
| The role holds Manage which customers can access the Papers document portal for a project (enroll by email, suspend/remove, send invitations). | Role editor | The section is missing |
| The customer is a party on documents | Parties | Their portal is empty |
| Party emails match their account email | Documents | Documents do not appear |
| The customer portal is published | Customer portal | There is nowhere to sign in |
| The email channel can deliver | Communication Channels | Invitations do not arrive |
8. Downstream
| When you… | Then |
|---|---|
| Enrol someone | They can sign in to this project's portal |
| Add them as a party on a document | It appears in their portal |
| Suspend | This project's documents disappear from their portal |
| Remove | Enrolment ends; account kept |
9. Don't confuse this with…
| Counterparties | An address book; grants nothing |
| Customer portal | Where customers sign in |
| Project members | Internal people |
10. Troubleshooting
| Symptom | Cause |
|---|---|
| The customer's portal is empty | They are not a party to any document, or the party email differs |
| They never got an invitation | It was left off, or the email channel failed |
| They cannot sign in to one project | Suspended there |
| A duplicate customer exists | Created by the old typed-email enrolment |
| There is no email box to enrol | By design — use Add Customer or Enroll |