Platform · Support

Who Gets In and Why

Every unit at every facility carries an answer to one question: should this tenant's phone open this lock right now? This playbook explains how KISS answers it, in plain language: the facts we collect, the rules each facility sets, the five states a unit can be in, and the reason codes that tell support exactly why someone is locked out.

// the big idea

One engine decides everything

A storage facility runs on property management software (we call it the PMS: Storedge, SiteLink, Cubby, and so on). The PMS knows the business facts. KISS knows the access rules. We keep those two things separate on purpose, and one engine combines them the same way for every facility, every PMS, and every app.

Facts

What the PMS tells us about the unit. Who is in it, when they moved in, what they owe, and any flags the facility set (overlock, auction, unrentable). We copy these into our own database on a schedule, so we never depend on the PMS being up to answer an access request.

Rules

What each facility configures in KISS. How much a tenant can owe before losing access, how many days of grace they get, whether one late unit locks a tenant out of all their units, and whether to honor the PMS's own lockout flags.

Overrides

A manager's manual call on a specific unit. Force access on or force it off. An override beats everything else, every time.

✓

The decision: the engine runs the facts through the rules and stamps the unit with a state (one of five, below) and, when a tenant is involved, a reason that says why. Both are saved on the unit, so every app, list, and support screen reads the same answer.

Vocabulary: "status" is out, "state" is in

The old world had one word, status, a string copied from the PMS ("overlocked", "current", "reserved") that mixed up what the PMS knew with what should happen. The new word is state: the decision our engine produces, plus a reason. Two tenants can both look "overlocked" in the old vocabulary; in the new one, one is denied · delinquent (behind on this unit) and the other is denied · blanket_delinquency (behind on a different unit). Same old label, different problem, different fix. When you talk about access, talk in states and reasons.

// the five states

Every unit is in exactly one state

Only one state opens locks for a tenant: permitted. The rest describe why not, or that there is no tenant at all.

State	Plain meaning	Tenant access
vacant	Nobody is in the unit (or the PMS says someone is, but we cannot match them to a KISS account yet)	No tenant to let in
tenant_permitted	Tenant in good standing	Opens locks
tenant_denied	There is a tenant, but access is denied (the reason code says why)	Locked out
auction	The unit is in the auction process	Locked out
unrentable	The unit cannot be rented (maintenance, damage)	No tenant to let in

Why auction and unrentable get their own states: technically both mean "no tenant access", but managers browse them as categories ("show me the auction units") and staff role permissions are granted per state (a role can include auction units but not unrentable ones, for example). Making them full states keeps those everyday views one click instead of a puzzle.

// the support view

Why is this tenant locked out?

Whenever the state is tenant_denied or tenant_permitted, the unit also carries a reason code. This is the first thing to read on any access question, because it tells you where the fix lives.

Reason	What it means	Where the fix lives
delinquent	They owe more than the facility's threshold and are past the grace period	The tenant pays (or the facility changes its rules in KISS)
pms_lockout	The facility flagged them in the PMS (overlock, lien, legal hold)	In the PMS: clear the flag there and it clears here on the next sync
system_lockout	A manager manually locked them out in KISS	In KISS: remove the override
future_move_in	The lease is signed but the move-in date has not arrived	Wait for the date, or correct it in the PMS
blanket_delinquency	They are behind on a different unit at this facility, and the facility locks all of a tenant's units together	Resolve the other unit; this one clears on its own

The shortcut: read the prefix

Reasons that start with pms_ came from the facility's management software, so the answer lives there. Reasons that start with system_ came from KISS itself (a manager override), so the answer lives in KISS. Everything else (delinquent, future_move_in, blanket_delinquency) was computed from the money and dates we synced.

Permitted units carry a reason too: active (all checks passed), pms_exempt (the PMS says never lock this tenant out, so money checks were skipped), or system_exempt (a manager forced access on).

// how the decision is made

The checklist, in order

The engine walks one checklist for every unit, top to bottom, and the first question that matches wins. That ordering is the logic: an override beats a PMS flag, a PMS flag beats a balance check.

Before anything: if the unit has no smart lock and no gate or door that applies to it, we skip it entirely. It gets no state at all, because there is nothing to open.

Did a manager set an override? Force-on means permitted · system_exempt; force-off means denied · system_lockout. Overrides always win.
Is the unit unrentable? Maintenance or damage. State: unrentable.
Is it in auction? State: auction.
Is anyone actually in it? No tenant, or a tenant we cannot match to a KISS account yet: vacant. (The unmatched case is deliberate: if we cannot tell who the tenant is, nobody gets a key.)
Has the lease started? A move-in date in the future means denied · future_move_in. We compare calendar dates in the facility's own timezone, so a lease that starts today works all day today.
Does the PMS say "never lock this tenant out"? If the facility honors that flag: permitted · pms_exempt, and the money checks are skipped.
Does the PMS say "lock this tenant out"? If the facility honors that flag: denied · pms_lockout. One exception: a brand-new move-in gets a short grace window (about two days), because some PMSs leave a new unit flagged until the office finishes setup, and we do not want to lock someone out on day one.
Do they owe too much, for too long? Balance above the facility's threshold and past the grace period: denied · delinquent.
Are they denied on another unit here? If the facility turned on blanket delinquency: denied · blanket_delinquency. This is the only question that looks beyond the unit itself.
Everything passed. permitted · active.

// two kinds of keys

Unit locks and gates are two separate keys

A permitted unit produces up to two things: a key for the lock on that unit (if it has one), and a key for the gates and doors of the area the unit sits in. The gate rule is simply: at least one permitted unit in that area.

Unit key

This unit is permitted and has a smart lock on it. No lock, no unit key, even in good standing.

Gate key

The tenant has at least one permitted unit in the area behind that gate or door. A unit with no smart lock still counts here, which is why we evaluate every rented unit, locked or not.

So a tenant can legitimately have gate access but no unit key (their unit has no smart lock on it), and a tenant denied on their only unit loses the gate too. Both are the system working as designed.

// how fresh is the data

"They just paid. Why are they still locked out?"

Access decisions are made from our copy of the facts, so the real question is how quickly a change in the PMS reaches us. Facts arrive five ways:

Path	When it runs	Speed
Webhooks	The PMS pushes changes to us as they happen (where the PMS supports it)	Seconds
App-open refresh	A tenant opening their app kicks off a background refresh of their own units	Under a minute
Scheduled sweep	A full facility refresh on a cycle, roughly every 15 minutes for most PMSs (Storedge instead relies on webhooks plus a nightly sweep)	Minutes
Manager re-evaluate	A manager forces the rules to re-run on a unit from the dashboard	Immediate, but see the note below
Manual entry	Facilities with no PMS: operators maintain the facts directly in KISS	As typed

✓

The support move for "just paid, still locked out": have the tenant pull to refresh (or close and reopen) the app. That triggers the background refresh that pulls their latest balance and re-runs the rules. Worst case, the scheduled sweep catches it within about 15 minutes.

Re-evaluate is not a re-sync. The dashboard's re-evaluate button re-runs the rules on the facts we already have. If the payment has not synced from the PMS yet, re-evaluating will not change the answer; the refresh paths above are what bring the new facts in.

// common questions

Quick answers

A new tenant moved in today and cannot get in. Check three things in order: the move-in date in the PMS (a future date denies until it arrives), whether the tenant matched to a KISS account (an unmatched tenant reads as vacant), and the PMS lockout flag (new move-ins get about two days of forgiveness on that flag while the office finishes setup, so this one usually resolves itself).

How do I just let someone in right now? A manager override. It beats every other rule instantly. Set it, solve the moment, and remember to remove it, because it also silences the normal rules while it is on.

The tenant is fine in the PMS but denied in KISS. Read the reason code. If it is delinquent or blanket_delinquency, the facility's KISS rules (threshold, grace days, blanket setting) are stricter than what the PMS shows on the surface. If it is system_lockout, someone set an override.

Why does this unit show no state at all? It has no smart lock and no gate that applies to it, so there is nothing to decide. States appear once hardware is involved.

A facility is switching to a different management system. Do we rebuild their company? That is what this architecture is built to avoid: the company, its people, its units, and their locks stay, and only the data source feeding them changes. The clean switch-over flow is still being built (KEEP-1077), so for now loop in engineering before migrating anyone, and do not create a duplicate company as a workaround; that recreates every employee and unit and orphans the history.

Who changes the money rules? They are per-facility settings in KISS: the balance threshold, the grace period, whether one late unit locks all of a tenant's units, and whether the facility honors the PMS's lockout and never-lock-out flags.

Keep this playbook in sync with

The decision engine: UnitAccessEvaluator in kiss-api (the checklist order, the grace windows) and the access_state / access_reason columns on units.
States and reasons: the UnitAccessStatus and AccessReason enums.
Facility rules: LocationPolicy (threshold, grace days, blanket delinquency, respect-PMS-flag switches, move-in lockout grace).
How facts arrive: the per-PMS Sync{Pms}FactsJob schedules, webhook handlers, the tenant app-open refresh, the manager re-evaluate endpoint, and the V2 partner push endpoints (UnitPushGuard ownership rules).
The partner-facing contract: kiss-api-docs (docs.keepitsimplestorage.com) documents what API consumers see; this playbook covers how it works inside.

Who Gets In and Why. One engine, one checklist, five states, and a reason code that tells you where the fix lives. Questions the doc doesn't answer? team@keepitsimplestorage.com.

Audience · support, ops & sales LLM file · facts-based-access.md Last reviewed · Jul 2, 2026