A partner brings institutions to dfrds and administers the ones they brought.
This guide is the staff side: creating the row, setting the terms, and ending
the relationship. What a partner sees is covered by their own console.
Everything here is at Admin → Partners, and needs the partners_manage
permission. Alpha holds it by definition; admins hold it only if alpha granted
it, and nobody holds it by default.
The terms are the agreement
A partner’s powers are the fields on their row and nothing else. Every check
in the application asks this row — never the form a partner submitted — so a
partner cannot exceed the terms even by posting different values.
| Field | What it decides |
|---|---|
| May create | Which kinds of tenant they may set up: university, team, or both |
| Maximum discount | The ceiling on what they may discount, and therefore on what they earn |
| Bundled dataset | A dataset their sponsorship carries, granted to every organization they bring |
| Default plan | What a new institution they create starts on |
| Notes | Who agreed to this, when, and anything the fields do not capture |
Set the maximum discount to zero until an agreement is signed. Zero means
“may apply no discount”, which is the right posture for a partner whose terms
are still being negotiated.
Changing any of these asks you to confirm your password first. It is the same
class of action as granting a courtesy subscription, and for the same reason:
it decides what someone may charge and what they may give away.
Who administers a partner
Assign people from the partner’s own page. Doing it there sets both their
platform role and their partner link in one step, so a partner user is never
half-created across two consoles — an account with the role but no partner can
sign in and see nothing, with no clue why.
Staff cannot be assigned as partner administrators. Demote them to a member
account first. This is deliberate: a partner is a customer-facing role with
delegated power over other people’s tenancies, and staff powers on the same
account would blur which hat someone is wearing.
Partner administrators are required to have a second factor, like staff.
Ending a partnership
Ending is not deleting, and the difference matters to the institutions
involved.
What ends: the bundled dataset entitlement, because that was the sponsor’s
to give. Provisioning — the partner can no longer set up new institutions.
What does not end: every organization they brought keeps working, on its
own plan, with its own members and its own subscription. Their research is
untouched. The partner’s administrators keep their accounts and their console,
which now says the partnership ended and on what date rather than turning them
away with no explanation.
You must give a reason, in a sentence. It goes into the audit log, which is
where someone will look in a year when they are trying to work out what
happened.
Ending cannot be undone from the console. Resuming a partnership is a
deliberate act, not an undo.
How you get paid
The commercial model is settled: dfrds bills the institution and pays the
partner a commission. The institution’s money arrives through the
platform’s own Stripe customer and invoiced-subscription path, tax stays with
the platform’s registrations, and no partner has to pass Stripe Connect
verification abroad. The partner’s side of that is a monthly statement.
- Issued on the 2nd. A day after a month closes,
BuildPartnerStatementsJob
builds one statement per partner who sold something in it, from the split
each sale froze at the moment of sale, and issues it to their console at
Partner → Statements. A month with no sales gets no statement. - Paid by bank transfer. Staff send the transfer, then open the statement
on the partner’s page and record the bank reference. The reference appears
on the partner’s statement, which is what they reconcile against. - Frozen once paid. An unpaid statement can be rebuilt (the job does so if
it runs twice, and you can build a named month from the partner’s page); a
paid one is never touched again.
Recording a payout asks for your password and writes an audit line with the
reference, like every other action here that moves money. Staff can build a
month early from Admin → Partners → the partner → Statements, or with
bin/rails "partners:statements:build[YYYY-MM]" on the host.
Everything is audited
Every create, every change of terms, every assignment and every ending writes
an audit_logs row naming who did it and, for a change of terms, what they
were before and after. Reading the console writes nothing.