Roles, groups & access: who sees what, and why

Access in Fieldcurve is deny-by-default: a user sees nothing they haven’t been granted, and every read — dashboards, search, exports, the worksheet — flows through the same predicate. There is no side door where a report shows more than the grid would.

Roles are capability bundles at a scope

A role is a named bundle of capabilities (view, edit progress, manage structure, administer…) granted at a scope:

• Organization — the whole tenant; typical for program controls and admins.
• Group — a business unit, region, or asset; the everyday scope for most teams.
• Project — one project only; typical for contractors and short-term specialists.

Your org admins define and grant roles themselves — adding a user or changing a permission is an admin screen, not a vendor ticket.

Groups scope visibility, not security

Groups carve the org into visibility scopes — the CSU group sees CSU projects. The hard security boundary is the organization: it’s enforced with row-level security at the database, beneath the application, and verified by an automated isolation gate on every change (the security overview covers this in depth).

Assignment is responsibility, not access

Being assigned a task marks you responsible for it — it never grants access to anything. Assignment presupposes you can already see the project; handing someone a task can’t quietly widen what they see. The distinction sounds pedantic until an auditor asks.

Everything lands in the audit trail

Permission changes are audited like data changes: who granted what, to whom, when. Access reviews start from a record, not a reconstruction.