User groups and permissions get treated as an administrative setting — configured once during onboarding and never revisited. In an award programme they are a fairness control, and the most damaging misconfiguration is not a security breach.
It is a judge who can see entries they were never assigned.
On this page
- Why visibility is a fairness problem
- Groups, roles and rights
- User groups and permissions at function level
- Criteria: the setting that actually matters
- The part everyone forgets: revocation
- Setting it up
Why visibility is a fairness problem
A judge who can browse entries outside their assignment has been exposed to submissions they may have a relationship with — and cannot declare a conflict against something they were never formally assigned. A judge who can see an entrant’s identity where the programme intended anonymous assessment has had that anonymity removed without anyone deciding to remove it.
Neither looks like a security issue on a risk register, which is exactly why they persist. Both are permission settings.
Groups, roles and rights
Access is assigned to groups rather than to individuals. A group carries a label, a description and its member emails, and every group holds a set of rights — visible at a glance as a rights count, so an administrator can see immediately which groups are configured and which are still empty.
Typical groups in a running programme look like this.
Full configuration of flows, pages, templates and account types. The smallest group you can manage with.
Runs the cycle without touching platform configuration — the secretariat’s working group.
One group per panel rather than one “judges” group, so visibility can be scoped panel by panel and revoked panel by panel.
For judges sitting outside a panel structure — a small rights set, deliberately.
Read access for someone verifying the process without participating in it. Worth creating before anyone asks for it.
Two rights, for people’s-choice voting. Everything else stays closed.
Access to their own submission and nothing else.
Roles can be picked from a preset — System Admin, User Admin, User Journey Manager, Analytics Manager, Award Management Team, Applicant, Judge — or set to Customized and built up function by function. Most programmes start from a preset and customise one or two groups.
User groups and permissions at function level
Each function carries four separate rights — read, create, update and delete — rather than a single on-off switch. That distinction does real work: an Analytics Manager who reads everything and changes nothing is a different risk profile from one who can edit, and a single “access” toggle cannot express the difference.
Studio
- Page — application pages and form layouts
- Flow — process flows
- Template — email and message templates
- Account Type
- Experience — the applicant journey
Admin
- Contact — contacts and their records
- Audit Log — request log and queue exports
- Data Health — field quality and drop-off
Application
- To Do List — the applicant to-do list
- Records — the applicant’s own records
- Team — the applicant’s team members
Note that Audit Log and Data Health sit on the Enterprise plan. If your programme’s governance case depends on producing a request log, check that against your plan before you rely on it — a point worth raising with any vendor, and one of the questions in our RFP guide.
Criteria: the setting that actually matters
Function rights decide what someone can do. Criteria decide which submissions they can do it to, and this is where award programmes get themselves into trouble.
The default is permissive, and the interface says so plainly: submissions from any flow you have not listed in a criteria remain visible. Add one criteria per flow to bring it under control.
Read that twice if you run multiple award streams. Scoping one flow does not scope the others — an unlisted flow stays open. This is the single setting most likely to leave a judge looking at entries from a programme they have nothing to do with.
A criteria is built from three parts: the flow it applies to, the stage within that flow, and optional field conditions — for instance, restricting a panel to entries where Award Category equals a particular value. Conditions can be stacked, so a panel can be scoped to one category at one stage of one programme.
Stage scoping is the part worth dwelling on. A judge assigned at first-round assessment does not need visibility once entries reach finals, and a finals panel does not need to see who was eliminated earlier or why. Scoping by stage keeps each panel’s view to the decision it is actually making, which is the practical expression of the independence argued for in our guide to the award judging process.
One criteria per flow, per group, written before entries open. Retro-fitting criteria mid-cycle means some judges have already seen what the criteria was meant to hide, and a permissions change cannot un-see it. Treat the criteria set as part of your programme rules rather than as configuration.
The part everyone forgets: revocation
Almost every programme grants access carefully and removes it never. Judges recruited years ago frequently still hold working logins, and each dormant account is standing access to personal data for someone with no current role.
Under the PDPO, DPP4 requires all practicable steps against unauthorised access, proportionate to the sensitivity and volume of data held, and the six Data Protection Principles apply across the whole lifecycle rather than at the collection moment. Access that outlives its purpose is exactly the exposure DPP4 is aimed at — see our PDPO compliance guide for a defensible retention and revocation shape.
Per-panel groups make this tractable. Revoking a panel’s rights at announcement is one action against one group rather than a hunt through an account list — which is the practical reason to create a group per panel rather than a single judges group.
Setting it up
- Create a group per panel, not a single judges group — it is what makes scoping and revocation one action each
- Start from the nearest preset role, then customise, rather than building from an empty Customized set
- Add a criteria for every flow each group should be limited to — unlisted flows stay visible
- Scope by stage as well as flow, so panels see only the round they are judging
- Create the Auditor group before someone asks for one
- Decide how supporting documents are handled if judging is anonymised — organisation names inside a PDF defeat an anonymised form field, and no permissions model can fix a letterhead
- Set revocation as a trigger rather than a date — at announcement, not “end of year”
The sixth is the one that catches experienced programmes, and the third is the one that catches everyone else.
If you are evaluating platforms rather than configuring one, ask to see the judge view rather than the administrator view — and ask what a judge sees for a flow nobody remembered to scope.
Want to see the judge view on your own programme structure? Book a live demo or see pricing.
