Five levels, from the root account down to a member of a research group.
Each one’s powers are listed below, and so is where they stop — the second
half matters more, because it is what you rely on when you hand someone an
account.
The five levels
Alpha
The root account. There is exactly one, and the platform enforces that in
the database rather than trusting anyone to remember it.
Alpha alone can promote someone to staff, decide which powers each staff
member holds, create partners, and hand alpha itself to another account.
It holds every staff permission by definition — the account that grants
permissions cannot be missing one, or it could lock itself out of the
console it grants them from.
Alpha requires a second factor. So does every other account with power over
someone else’s.
Admin
Platform staff. An admin holds exactly the powers alpha granted them, one
at a time, and nothing else. A brand-new admin account starts able to read
the audit log and do nothing else.
This is deliberate and it has a consequence worth knowing before it
surprises you: making someone an admin gives them no powers at all.
Their powers arrive when you grant them at Admin → Staff.
Admins cannot edit the permission matrix, create partners, or promote other
admins. Those are alpha’s.
Partner
A partner brings institutions to the platform and administers the ones they
brought. They create the organizations they sponsor, invite each one’s first
administrator, and see usage for their own tenants.
Where a partner stops is the important part. A partner cannot see another
partner’s institutions, cannot impersonate anyone, cannot read a member’s
research, cannot reach an organization they did not create, and cannot
apply a discount that was not approved for them. They administer the
tenancy, not the people inside it.
Institution
A university, department, research group, or team. Its administrators
invite and remove members, manage the subscription, and work within a seat
allowance.
An institution administrator manages their own organization and no other.
User
Everyone else. What a user can use comes from their plan, never from
their level: a student covered by their university’s subscription gets the
full feature set while their own personal organization stays free.
The free tier is the whole platform minus data downloads.
Levels and plans are different questions
This is the distinction the whole model rests on, so it is worth stating
plainly: your level says who you are; your plan says what you can use.
A partner on a free plan cannot download data. An institution
administrator whose subscription lapsed drops to free features while
staying an administrator. Being staff is the one exception — platform staff
bypass entitlements, because they have to be able to see what they are
supporting.
Where each level is managed
| To do this | Go here | You must be |
|---|---|---|
| Promote someone to staff, or change what a staff member may do | Admin → Staff | Alpha |
| Create or end a partner | Admin → Partners | Alpha, or an admin holding partners_manage |
| Create the institutions you sponsor | Partner console | A partner |
| Invite or remove members, manage seats | Your organization’s page | An institution administrator |
| Change your own plan | Billing | Anyone |
What an institution administrator can see happen
An organization’s page has an Audit log link for its admins. It lists,
newest first, what happened across the organization’s members:
| Event | Recorded when | What the row says |
|---|---|---|
| Signed in, signed out | A member’s session begins or ends (password, Google, the institution’s identity provider, second factor, or a remembered browser) | Who, from which IP address, and how (via: saml for the identity provider) |
| Failed sign-in | A wrong password or second-factor code for a member’s address | The address, masked (stu…@example-uni.edu), and the reason. Never the password |
| Password reset, password changed | A member uses a reset link, or changes the password from the account page | Who |
| Export completed, download link issued | A member’s data export finishes, or they open a download link for one | The request’s name and row count |
| API key used | Any request with one of the organization’s keys | One row per key per day, with the day’s request count |
| Member invited, member removed, role changed | An admin acts on the member list, or a member leaves | Who did it, to whom |
| Retention purge | The nightly sweep deletes expired trash, history or export files | The counts |
| Two-factor mandate | An admin requires a second factor of every member, or stops requiring it | Which |
| Domain verified | The email domain’s TXT record passes | The domain |
| Single sign-on configured, verified | An admin saves the identity provider, or a test connection passes | The IdP’s entity ID; for a test, the masked address it signed in |
Filter by event and by date, or download the whole slice as CSV. Rows are
written once and never edited; staff holding the audit permission read the
same log, whole, at Admin → Audit log, filtered by who acted, the
action, what it acted on, the organization and the dates. Reading it is not
recorded; downloading it as CSV is, as an audit.exported row naming the
filters. What is recorded, and for how long, is set out in the
privacy policy and in Your data.
Verified email domains
An organization can claim an email domain, so that anyone who confirms an
address on it joins as a member. That is a claim on every future sign-up
from the domain, so it has to be proven before it admits anyone, and it is
re-proven weekly afterwards.
Staff set the domain. The organization’s administrators prove it, because
the proof goes in their DNS: on the organization page, under Email domain,
choose Generate a record. The record is shown once:
_dfrds-verify.university.edu TXT <token>
Add it to the domain’s DNS, then choose Verify now. The check is
immediate; DNS changes can take a while to spread, so a record added a
minute ago may need a second try. Once it passes, the panel reads Active,
the audit log records the verification, and sign-ups on the domain join
from then on. An address confirmed while the domain was unproven does not
join retroactively; invite it.
Every Monday the record is checked again. If it has gone, auto-join pauses,
the panel reads Paused, and the administrators are emailed. Existing
members are unaffected. Put the record back and verify to resume, or leave
it: a domain that changed hands should stop admitting people, and the pause
is how it does.
Generating a new record replaces the old one, which stops proving anything
from that moment; the domain stays verified until the next weekly check,
which will need the new record.
Seats still apply. Someone the domain admits when every seat is in use is
told so, on the confirmation page or after their institution’s sign-in, and
the administrators are emailed to free one.