> This is the Markdown of a Backed Help Centre page, https://admin.backed.giving/help/administrator/users/access-configurations.md. Every page is listed at https://admin.backed.giving/help/llms.txt.

> This page uses Backed's default terms, such as Funding Round and Application Template. An organisation may rename them, so read each as your organisation's own term if you've renamed it.

Backed has four kinds of user: administrators, assessors, applicants and verifiers. Titles such as
Super Admin, Programme Manager or Auditor are not extra kinds of user. Each one is an administrator
with a chosen set of access permissions, in the Admin Groups that give them the right records.

## Before you start

You need `Can edit Permissions` to choose what someone can do, `Can access Users > Admins` to open
another administrator's page, and `Can manage Admin Groups` to set up groups.

## Role profiles

Each title below is a way of setting someone up, not a separate kind of user.

| Title | How to set it up in Backed |
|---|---|
| Super Admin | An administrator holding `Can edit Permissions`, `Can manage Admin Groups` and `Can access Settings > Organisation`, in a group with `Any Criteria` and `Full Access` |
| Admin | An administrator holding a broad set of permissions, with the access the `Default Group` gives |
| Staff, Programme Manager or programme officer | An administrator holding only the permissions their work needs, in an Admin Group with `Specific Funding Rounds` |
| Assessor or community reviewer | An assessor. A community reviewer is an assessor given a simpler Assessment form |
| Panel convenor | An administrator |
| Applicant | An applicant |
| Verifier | A verifier |
| Auditor or external partner | An administrator in a read-only group, with no report permissions (see below) |
| Chair, committee, board, trustee or minister | Nobody signs in for these. Send them reports and dashboards instead |

A Programme Manager in a group with `Specific Funding Rounds` sees only the Funding Rounds you tick,
and only those rounds' Applications, in their lists. A record in any other round opens as though it
were not there. This holds only while the `Default Group` gives no access of its own, so lower the
`Default Group`'s rule to `No Access` when you scope people this way.

## Set up a read-only auditor

An auditor or external partner can open every record and change none of them, and has no way to
export or download a report.

1. Invite them as an administrator from `People > Administrators`.
2. Open their page and select `Edit`. Under `Access Permissions`, tick every `Can access …`
   permission except `Can access Users`, `Can access Users > Admins` and
   `Can access Settings > Organisation`. Tick nothing else, and in particular none of
   `Can generate reports`, `Can create and update reports`, `Can generate document reports` and
   `Can create and update document reports`. Select `Save`.
3. Go to `People > Admin groups` and select `Add Group`. Name it, for example, `Auditors`, and tick
   the auditor under `Members`.
4. In the group's rule, set every type of record to `Read Only` and choose `Any Criteria`. Select
   `Save`.
5. Open the `Default Group` and check its rule. Set any type of record that is above `Read Only` to
   `Read Only` or `No Access`. Give the people who need more their own group first, because the
   `Default Group` covers every administrator.

Every export, bulk export, PDF download and report needs `Can generate reports` or
`Can generate document reports`, so an auditor without them sees no export action anywhere, and
Backed refuses an export they ask for directly. They also cannot open the Applicants directory,
because `Can access Users` also opens the people exports; they see each applicant on its
Application instead.

## Six common configurations

These are the configurations Backed is tested against. In each, a type of record you do not set
stays at `No Access`.

### Unrestricted admin

Leave the `Default Group` with its original rule: `Any Criteria` and `Full Access` to every type of
record. Every administrator has the same experience as before Admin Groups were introduced.

### Programme-specific team

Lower the `Default Group`'s rule to `No Access`. Add a group for the team with `Specific Funding
Rounds`, tick the team's Funding Category or rounds, and give `Full Access` to the types of record
they work on, such as Funding Rounds, Applications, Contracts and Payments. Members work only on
records of the selected rounds.

### Read-only auditor

Follow [Set up a read-only auditor](#set-up-a-read-only-auditor). The auditor sees everything and
changes nothing.

### Separation of duties: Programme Managers and Finance

Lower the `Default Group`'s rule to `No Access`. Add a `Programme Managers` group with `Any Criteria`
and `Full Access` to Funding Rounds, Applications and Assessments, and `No Access` to Contracts and
Payments. Add a `Finance` group with `Read Only` on Applications and `Full Access` on Contracts and
Payments, and give `Can approve Payment Batches` to Finance only. Programme Managers cannot see
payments, and Finance cannot change applications.

### Payment approval separated from bank account changes

Lower the `Default Group`'s rule so that it gives no `Full Access`. Give the people who approve
payments `Can access Payments` and `Can approve Payment Batches`, in a group with `Full Access` to
Payments and `Read Only` on Applicants and Contracts. Give the people who keep applicant records up
to date a group with `Full Access` to Applicants and Contracts and `Read Only` on Payments, and no
payment approval permission. Nobody both approves a payment and changes the account it pays.

### Restricted baseline with promoted access

Set the `Default Group`'s rule to `Read Only` on Funding Rounds and Applications only. Add an
`Experienced Staff` group with `Any Criteria` and `Full Access` to every type of record. New
administrators automatically get read-only access through the `Default Group`. Once they are
trained, add them to `Experienced Staff` to give them full access.

## Planning your groups

Before you build groups, decide how your organisation divides its work:

- **By programme.** One group per Funding Category or set of rounds, each with `Specific Funding
  Rounds`, so each team sees only its own applications.
- **By function.** Groups for what people do, such as assessment, contracts or finance, each giving
  `Full Access` to its own types of record and `Read Only` or `No Access` to the rest.
- **By seniority.** A restricted `Default Group` for everyone, and a group with wider access that
  people join once they are trained.

You can combine these: someone in several groups gets the widest access any of them allows. Then
set up in this order:

1. Write down who needs to see and change which records.
2. Create the groups and add their members.
3. Give each person the permissions their work needs on their page under `Access Permissions`.
4. Review the `Default Group` last. While it gives `Full Access` with `Any Criteria`, every
   administrator sees everything, whatever other groups they are in.

## See also

- [Admin groups](admin-groups.md)
- [Administrators and permissions](administrators-and-permissions.md)
- [Approval limits](approval-limits.md)