Policies

Roles decide what a user is allowed to do. Policies decide what nobody is allowed to do beyond the limits an owner sets — they are administrative constraints that layer on top of roles and access grants. A policy never grants access; it only narrows it. This makes policies safe to reason about: adding a policy can only ever restrict, never widen, what someone could already do.

Policies vs roles

A role might let a resident open the lobby door. A curfew policy can still stop a guest invitation from opening that same door at 02:00 — without changing anyone’s role. Roles answer “who may act”; policies answer “under what limits”.

Three tiers of policy

Policies exist at three scope tiers, in increasing authority:

1. Org policy — applies across an organization and down its sub-orgs. Example: “guest invitations are subject to a 22:00–06:00 curfew.”
2. Integration policy — applies to a single integration (one provider connection in one org). Example: “on this PalGate integration, only admins may share gate access.”
3. Device policy — applies to a real-world physical device and is set by the verified hardware owner. It binds every organization and integration that points at that same physical device. This is the strongest tier and exists to let a hardware owner retain control even when others have connected their own integrations to the same device. See Regaining control of shared devices.

How tiers combine

• Within the org tree (org + integration tiers): most-restrictive wins. A sub-org admin can make a parent’s policy stricter, but can never loosen it. This is the franchise / landlord invariant — a parent organization can set floors that children cannot lower.
• The device tier is the highest authority, but restrict-only. A device policy set by the hardware owner can clamp things down across every org using that device, but it can never relax what an org or integration already forbade.

The net effect everywhere is deny-overrides: the effective limit is the most restrictive of all applicable policies.

One deliberate exception

The only policy that relaxes rather than restricts is emergency free egress (life-safety). It is an explicit, audited carve-out so that the “restrict-only” rule has exactly one documented exception rather than a silent hole.

When policies are enforced

Policies take effect at two moments:

• Access-time — when someone opens a door/gate or triggers an entity action. Time-based limits (curfews, quiet hours, lockdown) are enforced here, evaluated alongside OpenApp’s attribute-based access checks.
• Authoring-time — when someone creates an invitation or shares device access. Limits like “max invitation duration”, “who may invite”, or “require approval” are enforced here. Where a policy requires approval, OpenApp opens a pending request for an admin to approve or deny.

Worked examples

Invitation curfew

An org admin sets a night curfew on invitations. From then on:

• A guest holding a valid invitation cannot open the door during curfew hours, even if the invitation’s own schedule covers the night. The invitation is not modified — the curfew is evaluated live every time the link is used.
• A non-admin who creates, say, a 48-hour invitation cannot override the curfew. The invitation simply works during allowed hours only, and the guest sees a “subject to curfew” note.
• Admins and residents are never curfewed — the limit targets invitation-based access specifically.
• When the curfew is first set, OpenApp surfaces a report of existing invitations that overlap the curfew window, so the admin can see what changes for guests.

Controlling who can share access

Some providers expose a directory of device users (for example PalGate gate users). An org admin can decide whether non-admins may add or share those users:

• Block non-admin sharing entirely, or
• Require admin approval before a non-admin’s share takes effect, or
• Allow it.

This prevents users from quietly handing out access “out of band” and keeps the admin in control of who is on the gate. OpenApp can only gate sharing performed through OpenApp; sharing done directly in the vendor app is outside its control, but OpenApp can still surface and (optionally) reconcile unmanaged vendor-side users.

The policy catalog (overview)

The framework is extensible; the first delivery focuses on curfews and sharing control, with a broader catalog designed in:

• Invitations — max duration, max uses, max active invites per user, require expiry, require identity (PIN / photo / verified phone), allowed entry kinds, allowed days / blackout dates, no re-share, require justification.
• Time — curfews / quiet hours, holiday calendars.
• Sharing & delegation — who may invite, approval thresholds, no transitive delegation.
• Access scope — max doors per invite, restrict invites to a resident’s own apartment doors, prohibit master-door invites.
• Security & compliance — step-up for sensitive doors, rate limits, anti-tailgating cooldowns.
• Lifecycle — auto-revoke invites on resident move-out, auto-expire dormant users.
• Operational — emergency lockdown, emergency free egress, maintenance windows.
• Notifications — alert admins on first use, on out-of-curfew attempts, and on new sharing.

Related

• Regaining control of shared devices
• Roles you need and the Roles reference
• PalGate permissions and Linked Device