Direct Permissions

A direct permission is an explicit grant that says "this specific user or group has this specific level of access to this specific entity". Where the broader authorization system answers access questions through rules and relationships, direct permissions answer them by being recorded against the entity itself. They are the simplest, most targeted form of access control in the platform and are typically used when a team or individual needs hand-curated access to a particular record.

What a direct permission represents

Every direct permission ties three things together:

• A subject — the user or permission group who is being granted access.
• An entity — the specific record the access applies to, identified by its type and identifier.
• A permission level — what the subject is allowed to do with that entity.

Because direct permissions are attached to one entity at a time, they are well suited to ad-hoc sharing decisions — for example, giving a colleague edit access to a single document, or granting a temporary reviewer view access to one application — without having to model a new role or rewrite a policy.

Permission levels

Direct permissions are granted at one of four levels. Each level fully includes everything the levels below it allow.

Level	What it allows
View	Read the entity and its related details. The subject cannot make any changes.
Edit	Everything View allows, plus modify the entity's data.
Admin	Everything Edit allows, plus manage the entity's own access control — granting and revoking direct permissions to others.
Own	Everything Admin allows, plus transfer or remove ownership. There is normally exactly one owner of an entity at any one time.

Levels are ordered, so any check for a lower level is satisfied by a grant at a higher level. A subject with Admin access automatically passes any Edit or View check, and an owner automatically passes any check at all.

Time-bounded access

Each direct permission can carry an optional start date and end date. The grant is only effective between those dates:

• A grant with no start date is effective immediately.
• A grant with no end date remains effective indefinitely, until it is removed.
• A grant whose end date has passed no longer grants any access, even though it remains on the record for audit purposes.

This makes it straightforward to express access that is genuinely temporary — for example, granting a contractor Edit access to a project for the duration of an engagement, or giving an auditor View access for a fixed review window — without having to remember to revoke it later. The grant simply stops applying when its end date is reached.

Expired permissions are not silently deleted. They remain visible in the entity's access history, so administrators can see who had access and when.

Non-overlapping grants

For any given combination of subject, entity, and time window, only one effective direct permission can exist at a time. The platform prevents administrators from creating a second grant that overlaps an existing one for the same subject and entity.

The intent is to keep the answer to "what access does this user have to this entity right now?" unambiguous. If a subject had two overlapping grants, it would be unclear which level applied, and removing one grant could leave behind another that quietly preserved access.

In practice this means:

• To change a subject's level on an entity, the existing grant is updated (or ended) rather than a second grant being added alongside it.
• To extend or shorten a window of access, the existing grant's dates are adjusted.
• To replace one grant with another that takes effect later, the first grant's end date must precede the new grant's start date so the two windows do not overlap.

The rule applies to each (subject, entity) pair independently, so the same user can hold non-overlapping grants on many different entities, and many different users or groups can hold grants on the same entity at the same time.

Groups as subjects

A direct permission can be granted to a permission group instead of an individual user. When that happens, every effective member of the group — including members brought in by nested group membership — receives the grant.

In this example, the Reviewers group has a single direct permission granting Edit access to Application 123. Alice, Bob and Chen all receive that Edit access through their group membership, without each needing an individual grant. If Bob leaves the group, his access to the application stops immediately; if a new member is added, their access begins immediately.

Granting to groups keeps the number of direct permissions small and makes large changes — onboarding a team, rotating reviewers — a single membership change rather than a sweep through many entities.

How direct permissions fit with the wider access model

Direct permissions are one of several mechanisms the platform uses to decide whether an action is allowed. They sit alongside:

• Permission groups — the way subjects are aggregated so that grants do not have to be made one user at a time. Groups have no permissions of their own; they only matter once they are referenced by a direct permission or an authorization rule.
• The authorization (ReBAC) system — relationship-based rules that derive access from how records are connected (for example, "the assigned reviewer of an application can edit it"). ReBAC is well suited to access that follows the data; direct permissions are well suited to access that is granted by hand.

When an action is attempted, the platform considers all of these sources together. A subject is allowed to perform the action if any one of them grants the required level — a direct permission on the entity, an effective grant through a group, or a relationship-based rule. There is no need to choose between them in advance; they overlap by design so that broad policy and targeted exceptions can coexist.

The practical guidance is:

• Reach for direct permissions when a specific entity needs specific people to have a specific level of access, especially when the access is temporary.
• Reach for groups when the same set of people will be granted access in many places.
• Reach for authorization rules when access should follow a relationship in the data and should not have to be re-applied for every new record.

Auditing and change tracking

Because direct permissions decide who can see and change individual records, every grant is audit-tracked. The standard audit fields record who created or last changed each grant, and historical and expired grants are retained so that "who had access to this entity, at what level, and during what period?" can always be answered.

Related topics

• Permission Groups — how groups aggregate users so direct permissions can be granted to many people at once
• Data Model Overview — how tenant scoping, audit fields, and time-bounded validity apply across Foundation
• Menus and Navigation — how role-based menu visibility complements entity-level access control