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”.

Browse the catalog

Every shipped type — arguments, allowed values, and examples — is in the policy catalog. Search by name or policy_type, then open the type page. This guide explains the model; the catalog is the reference.

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. Disabled rows and audit_only rows never block.

One deliberate exception

The only policy that relaxes rather than restricts is emergency free egress. When active, OpenApp will not deny inbound cloud opens (curfew, quiet hours, lockdown, hold-closed lockout). It is not fire-alarm release, not FACP door unlock, and not a substitute for listed exit hardware. Every activation is audited. Until you enable it, every live policy only restricts.

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: if the policy applies, the open is denied even when roles and grants would otherwise allow it.
• 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.

A third kind of row is a denial hook (for example notify on curfew attempt): it records or notifies after another policy has already denied the action. It does not itself grant or deny.

Author org policies on Settings → Policies, integration policies on the integration Policies tab, and device-tier policies (PalGate steward) on the device Policies tab.

Settings Policies with organization timezone and org-tier policies.(click to enlarge)

Close

Worked examples

Invitation curfew

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

Organization policy form for an invitation curfew.(click to enlarge)

Close

• 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.
• Org timezone (IANA, for example Asia/Jerusalem) is what “local hour” means. When unset, evaluation falls back to UTC. Curfews follow DST in that zone.
• Admin override: an organization admin may mark a specific invitation as exempt from curfew (an explicit emergency exception). Exempt invitations skip the curfew check at redemption and do not show the guest “subject to curfew” hint. Non-admins cannot set or clear that flag.
• 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. Existing invitation rows are never rewritten.

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 with user sharing control:

• 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.

Linked-account admin (PalGate)

PalGate setup probes whether the connected vendor account is a hardware admin of the gate. An org linked-account admin policy controls whether a non-admin vendor account can finish setup: warn only, warn and require acknowledgment, or block until an admin account is used. Default when no policy is set is warn and acknowledge.

Holding a door or light

Admins (and anyone granted the set hold role) can keep a door open or closed, or a light on or off, until they clear it, until a time, or on a repeating schedule (every day, working days, weekend, or chosen days — working days follow the building timezone, not the admin’s language). Policies do not grant that ability — they only limit it:

• Require hold expiry — members and residents cannot set a permanent hold.
• Max hold duration — caps how long a temporary hold can last. Longer requests are rejected.
• No repeating holds — one-shot temporary only.
• Allowed hold modes — for example, hold-closed but not hold-open.
• No holds — the set-hold role is granted, then tightened per org, integration, or device.

Guests with an invitation still see the door listed. If it is held closed they see the reason (or “This door is held closed”) and cannot open it. See Access portals.

Invitation authoring limits

When someone creates or updates an invitation, these policies reject the request if it would exceed the folded cap (they do not silently shorten the invite). The create wizard shows the effective limits. See each type in the catalog:

• Max invitation duration
• Max share duration
• Default share uses
• Max share uses
• Max invitation uses
• Max invitation devices
• Max active invitations per user
• Require invitation expiry
• Allowed entry kinds
• Require invitation justification
• Max doors per invitation
• Own-apartment doors only
• Prohibit master-door invitations
• Who may invite
• No invitation re-share
• No transitive delegation
• Require invitation identity — PIN, host photo, and/or verified phone
• Invitation allowed days — weekdays, blackouts, and an optional holiday calendar

Combination is most-restrictive (minimum numeric caps, intersection of kinds and creator roles, union of master-door ids, OR of boolean forbids). Reject, do not clamp. Device-tier rows bind every org on that hardware (PalGate steward only).

Agent-safety limits

Non-human principals (agents, API keys, invitations) can be narrower than a human admin. These types still never grant — they only restrict:

• Quiet hours — block listed principal kinds during a local hour window.
• Rate limit — throttle opens per principal in a sliding window.
• Require step-up — extra confirmation before a physical write.
• Emergency lockdown — when active, deny non-admin principals.
• Anti-tailgating cooldown — wait after a successful open of the same entity.
• Maintenance window — during a local hour window, only listed roles (for example technicians) may open.

Approval threshold raises a pending share or invitation approval to N distinct org-admin votes (any deny denies; self-approval does not count).

Lifecycle rows revoke invites on move-out and expire dormant users (revoke invites and residencies; they never delete the user).

Notification hooks notify on first use (invite uses 0→1) and notify on new sharing emit audit when channels includes audit. They do not block.

Agents are managed on Organization resources → Agents.

Site-level policy authoring for a building lives on the building Policies tab.

Site Policies tab for an access-control building.(click to enlarge)

Close

Related

• Policy catalog — every shipped type, searchable
• Regaining control of shared devices
• Roles you need and the Roles reference
• PalGate permissions and Linked Device