Policy catalog
Policies are administrative limits that layer on top of roles. A policy never grants access; it only narrows what someone could already do. For the three-tier model (org / integration / device) and how rows combine, see the policies architecture guide.
Use the catalog below to find a policy by name, category, when it is enforced, or tier. Categories start collapsed — expand one to see its policies. Machine policy_type keys are on each type page. Each card opens a page with every argument, allowed values, and an example config.
Common fields
Section titled “Common fields”These fields exist on every policy row, not only in config:
| Field | Values | Meaning |
|---|---|---|
enforcement | enforce, require_approval, audit_only | enforce blocks. require_approval opens an admin inbox (when the type supports it). audit_only records and never blocks. |
enabled | boolean | Disabled rows are ignored. |
applies_to | agent, api_key, invitation, member, resident, admin, all | Optional principal-kind bind. Defaults differ by type — see each page. |
output | string or integer | Optional channel / output id. Omitted means every output of the tier target. |
capability | invitations, users_admin, switchable, or unset | Optional column scope. Unset applies everywhere. |
Author org policies on Settings → Policies, integration policies on the integration Policies tab, and device-tier policies (PalGate steward) on the device Policies tab.
Catalog
Section titled “Catalog”40 policies
Invitations
Guest invites — duration, uses, who may create them, and which doors they can cover.
19 policies
Invitations
Guest invites — duration, uses, who may create them, and which doors they can cover.
19 policies
Invitation curfew
Blocks invitation-based opens during a forbidden time window (for example nights). Admins and residents are never curfewed; existing invitations are evaluated live, not modified.
Max invitation duration
Caps how long each invitation schedule slot may last. Longer create or update requests are rejected, not shortened.
Max share duration
Caps how long a short-term share (TTL invitation) may last. Combined with max invitation duration as the stricter of the two. Longer create requests are rejected, not shortened.
Default share uses
When the author omits a use count on a share, store this default. The system default is 1 when this policy is not configured.
Max share uses
Ceiling on how many times a share may be used. Unlimited shares require allow_unlimited on every applicable row and no invitation_max_uses.
Max invitation uses
Requires a finite use count and rejects unlimited invitations or counts above the cap.
Max invitation devices
Caps the number of unique guest browsers or app installations that may register an invitation.
Max active invitations per user
Caps how many enabled, unexpired invitations one person may have at once.
Require invitation expiry
Forbids open-ended recurring invitations that never end.
Allowed entry kinds
Limits which portal types (door, gate, boom-gate) an invitation may grant. Combination intersects allowed sets.
Require invitation justification
Requires a non-empty creation justification when creating or updating an invitation.
Max doors per invitation
Caps how many unique portals a single invitation may grant.
Own-apartment doors only
Invitations may only grant doors the author can open as a resident of an allowed apartment. Org/integration admins are exempt unless applies_to says otherwise. PalGate-only sites with no apartments fail for residents.
Prohibit master-door invitations
Rejects an invitation if any granted portal’s door is a listed OpenApp device id (union of ids; never client-forged hardware ids).
Who may invite
Literal allow-list of roles that may create invitations. Combination intersects lists; empty intersection means nobody. Not admin-exempt. Compose with user_sharing (both must pass).
No invitation re-share
When the row binds the actor, invite create/update is rejected. Org/integration default bind is resident (invitees), not generic members. Device-tier without applies_to binds everyone.
Require invitation identity
Requires a host PIN, a host-attached photo, and/or a verified invitee phone before an invitation can be created or used.
Invitation allowed days
Limits invitation-based opens to listed weekdays, minus blackout dates and optional holiday-calendar dates. Existing invitations are evaluated live, not modified.
Holiday calendar
Lists organization-local ISO dates that invitation allowed-days can treat as holidays. This type does not deny access by itself.
Holds
Door hold-open and hold-closed — who may set a hold and for how long.
5 policies
Holds
Door hold-open and hold-closed — who may set a hold and for how long.
5 policies
Require hold expiry
Members and residents cannot set a permanent hold. Temporary (and unless also forbidden, weekly) holds are still allowed.
Max hold duration
Caps how long a temporary hold can last. Longer requests are rejected, not shortened. PalGate hardware latch max is an extra cap when present.
No repeating holds
Members and residents may only set a one-shot hold, not a repeating calendar schedule.
Allowed hold modes
Limits members and residents to hold-open, hold-closed, or both (for example, stay-off for lights but not stay-on).
No holds
Members and residents cannot set a hold, even if an admin granted the set-hold role. Device-tier without applies_to binds everyone, including admins.
Sharing
Who may share access or manage linked users outside invitations.
4 policies
Sharing
Who may share access or manage linked users outside invitations.
4 policies
User sharing control
Restricts whether non-admins may share access or create invitations out of band — block outright or require admin approval.
Linked-account admin
Controls whether a non-admin PalGate vendor account can complete setup: warn only, warn and require acknowledgment, or block until an admin account is used.
No transitive delegation
Invite create: org admin or apartment admin only. Vendor users_admin writes (except list): org admin only. Runs in addition to user_sharing.
Approval threshold
Requires N distinct organization-admin approve votes before a pending policy approval proceeds. Any deny denies. Self-approval does not count.
Lifecycle
Move-out and idle membership — revoke leftover invites without deleting the user.
2 policies
Lifecycle
Move-out and idle membership — revoke leftover invites without deleting the user.
2 policies
Revoke invites on move-out
When a resident is removed from an apartment, enabled invitations they authored that grant that apartment’s doors are revoked.
Expire dormant users
After idle days, revoke that person’s invitations and remove residencies. The user account is not deleted. Admins are exempt unless included.
Agent safety
Time windows, throttles, and extra confirmation for agents, API keys, and guests.
4 policies
Agent safety
Time windows, throttles, and extra confirmation for agents, API keys, and guests.
4 policies
Quiet hours
Blocks access during a local hour window for listed principal kinds (agents, API keys, invitations). Admins are not restricted unless included.
Rate limit
Throttles entity opens per principal in a sliding window so retrying agents cannot exhaust door quota.
Require step-up
Requires extra confirmation before a physical write for the listed principal kinds.
Anti-tailgating cooldown
After a successful open of an entity, further opens of that entity are denied until the cooldown elapses. Admins are exempt by default.
Operational
Site-wide lockdown and notifications when a policy denies access.
6 policies
Operational
Site-wide lockdown and notifications when a policy denies access.
6 policies
Emergency lockdown
When active, denies non-admin inbound cloud opens. Does not lock a means of egress or fire-door assembly, and is not a building lock-in.
Emergency free egress
When active, OpenApp will not deny inbound cloud opens. This is not fire-alarm release.
Notify on curfew attempt
Emits an audit event (and configured channels) when curfew blocks an open.
Maintenance window
During a local hour window, only listed roles may open. Empty role intersection means nobody. Technicians match the same way as who-may-invite.
Notify on first use
Emits an audit event when an invitation’s use count goes from 0 to 1, if audit is among the channels.
Notify on new sharing
Emits an audit event after users_admin writes (except list) and after invitation create that actually shares, if audit is among the channels.
No policies match those filters.