Web dashboard

Create a review role

Build a role that can review form responses and nothing else — including the dependency the panel warns you about.

Sound is off

A role is a bundle of access you assign to people. This one is a Form Reviewer: it can read and review form responses, reach the Forms page, and nothing else.

Scope is the ceiling. Nothing inside a role can reach wider than the scope you pick, so start at the narrowest one that covers the work.

The panel counts what you have switched on — capabilities, permissions and pages — and starts at zero. Pages are counted separately from permissions for a reason: a role with the right grants but no page access cannot get to the screen that uses them.

Two things the panel tells you as you go, and both are worth reading rather than clicking past. Granting Responses · Read raises a note that it reads every submitted response in the organisation, past the permissions set on individual forms — for frontline staff, setting access on the form itself is usually the better answer. And Read on its own does not work: somebody has to be able to see the form before they can see what came back on it, so the panel warns until View form is granted too.

Review is not only a workflow step. It is the gate on office-only questions, which stay hidden from anyone without it.

Creating a role assigns it to nobody. That is a separate step.

Step 1
Decide what the role needs to do
Write the sentence first — "read and review form responses" — then grant exactly that. A role built by ticking what looks useful is how people end up with access nobody intended.
Step 2
Open Roles and create one
Admin Settings > Roles, then Create Role.
Step 3
Name it for the job
The next administrator reads this name in a list and has to know what it is for.
Step 4
Set the scope
The ceiling for everything inside the role. Nothing in it can reach wider, so pick the narrowest scope that still covers the work.
Step 5
Start from nothing
Enabled access counts what is switched on, and it starts at zero — every capability below begins off.
Step 6
Grant Responses · Read
On the Forms row. Read the note it raises: this reads every submitted response in the organisation, past the permissions set on individual forms.
Step 7
Grant Responses · Review
Approving a response or sending it back — and the gate on office-only questions, which stay hidden from anyone without it.
Step 8
Read the warning
Read on its own does not work. Someone has to be able to see the form before they can see the responses to it.
Step 9
Grant Templates · View form
The warning clears, and the role holds together. Granting it raises a second note: anyone with this role can see every form template in the organisation, whatever the per-form permissions say — which is what reviewing across all forms needs, so read it and keep it.
Step 10
Give it page access
Permissions say what someone may do; page access says where they can go. Turn on Web for the Forms row and the summary counts a page as well as permissions.
Step 11
Create it and check
Reopen the saved role: the name, the scope, and exactly the access you granted.
Step 12
A role with no page is a role that cannot get there
This is the most common half-built role. The grants are right, the person signs in, and the menu item they need is not there — because page access is counted and granted separately from the permission itself.
Step 13
Creating is not assigning
The role exists and does nothing until somebody is given it. And a person can hold several roles, so their access is the union of all of them — which is why a narrow role is safer than a broad one you intend to use "just for now".