Page Access
A page can be public or restricted, with four modes of increasing strictness.
Where to find it
Architect Panel → Layout & Pages:
- Page Builder — documents, revisions and publishing
- Pages — the site’s page structure
Admin Panel → User Administration:
- User Groups — the groups a page can be restricted to
Architect Panel → Security:
- Permissions — the record gate the strictest mode uses
The four modes
- Public — anybody. A page with no rule is public.
- Signed in — any identified user.
- Group — members of named security groups.
- Record — delegated to the platform’s own record access check.
The record mode is the powerful one
Rather than restating a rule, it asks the platform whether this person may see the record the page is bound to. So classification, lifecycle, record access roles and break-glass all apply without the page needing to know they exist.
That is the mode for a page showing somebody’s case, order or account.
It fails closed
If the access check cannot be performed, the answer is no. That is the correct behaviour and worth knowing, because it means a misconfiguration produces a page nobody can see rather than one everybody can.
A refusal does not admit the page exists
By default. Somebody probing for a members area learns nothing from the response, which is the right default for anything sensitive.
Turn on the login redirect deliberately
A separate setting sends an unauthenticated visitor to sign in instead. That is friendlier and it discloses that the page is there.
Right for a customer portal a user is expected to reach; wrong for anything whose existence is itself sensitive.
Being in no groups is not the same as unresolved
A subtlety the platform handles explicitly, and one worth understanding: a user whose groups have not been worked out yet is not a user with no groups. Treating them the same grants access to everybody or to nobody.
The practical consequence is to test with a real account rather than reasoning about the configuration.
Test every mode with the right accounts
Signed out, signed in without the group, signed in with it, and for record mode a user with and without access to the record. Four accounts, four results.
Public by omission is the risk
A page with no access rule is public. When building a restricted section, confirm each page carries a rule rather than assuming it inherited one.
Worked example
A customer portal uses record mode for case pages, group mode for its account section, and a login redirect on both because users are expected to arrive there. A check found two pages in the restricted section with no rule at all, which were public.
Recommendations
- Record mode for anything showing one person’s data.
- Confirm every page in a section carries a rule.
- Login redirect only where the page’s existence is not sensitive.
- Test with four accounts, not by reading the configuration.