Reference · built on requestOperator by FibricProperty & tenants

Lease Violation

Links complaints, door events, and camera counts to the lease clause they touch, and proposes a violation notice with a cure period.

Request accessPricing ↗

About

Lease Violation is an operator job for the complaints and events that point at a lease clause. It reads complaint tickets from Freshdesk and resident requests from Buildium, door events from Kisi and Brivo such as held-open, forced, and tailgate, and zone counts and dwell from Camera Vision on RTSP feeds. It reads the lease, the resident, and the unit from Buildium or AppFolio, and the clause map you configure: which events count, how many, over what period, and the cure period each clause allows.

When the evidence crosses your threshold it proposes a notice: the clause, the tickets and events behind it, and the cure date. The property manager approves, edits, or declines. On approval it proposes a note on the lease, a reply to the complainant, and, once the cure period passes without a new event, closing the matter.

This is a reference listing. It documents what Fibric would read from Lease Violation and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Complaints as tickets: Freshdesk tickets with fields and conversations and the contact behind them; Buildium resident requests
  • Door events: Kisi lock.held_open, lock.forced_open, lock.tailgate, and reader.access; Brivo access events of type exception, with user and access point
  • Zone counts, entry and exit transitions, and dwell at doors from Camera Vision, processed on the site's edge node
  • Leases, residents, and units: Buildium leases and tenants; AppFolio occupancies, and community association rules and violations
  • Prior notices and cure periods on record, as notes on the lease in Buildium
  • The clause map: which events and tickets count toward which clause, thresholds, periods, and cure days, in the operator's configuration

Proposed actions

  • Target capability: propose a violation notice per lease with the clause cited, the tickets and events behind it, and the cure date from your rule
  • Target capability: propose a note on the lease or tenant in Buildium recording the notice and the cure date, once approved
  • Target capability: propose a reply or a private note on the Freshdesk ticket telling the complainant what was done
  • Target capability: propose closing the matter when the cure period ends with no new event: a ticket status change and a closing note
  • Target capability: propose a lease charge where the lease sets a fee for the clause, through Buildium lease transactions or an AppFolio charge

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Turn repeated held-open events into a notice

    Kisi lock.held_open events at a resident's door pass your threshold inside the period. The operator proposes a notice citing the clause, with the events listed, and a Buildium note on the lease once approved.

    With Kisi, Buildium

  • Tie noise complaints to a lease

    Freshdesk tickets about the same unit are matched to the AppFolio occupancy. Past the threshold the operator proposes a notice with a cure date and a reply to each complainant saying a notice went out.

    With Freshdesk, AppFolio Property Manager

  • Flag occupancy over the guest limit

    Camera Vision zone counts for a unit's floor stay above the limit you set for consecutive nights. The operator proposes a review, with the counts and dates, before any notice is drafted.

    With Camera Vision (RTSP), Buildium

  • Close a matter after the cure period

    When the cure date passes with no new Brivo exception event or ticket, the operator proposes closing the Freshdesk ticket and a closing note on the lease.

    With Brivo Access, Freshdesk

Requirements

  • A property connector with leases and residents: Buildium or AppFolio
  • At least one evidence source: Freshdesk tickets, Kisi or Brivo door events, or Camera Vision zones on cameras the on-site edge node can reach
  • A clause map with thresholds, periods, and cure days per clause, entered in the configuration
  • A person named to approve notices for each property
Authentication
Carries nothing of its own. Tickets, door events, camera counts, and leases are read, and notices and notes proposed, under the credentials of the connectors you bind.

Limits

  • Door and camera events show that something happened, not who did it. The operator names the credential or zone; a person names the resident
  • The clause map is yours. It does not read the lease document or decide what a clause means
  • Notices are proposed, not served. Delivery method and legal form stay with you
  • It reads counts and events derived from video, not footage. Where a recording matters, a person reviews it in your video system

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Lease Violation ↗

Questions and answers

What does the manager approve before a notice goes out?
A notice: the lease and resident, the clause, every ticket and event counted with its time, and the cure date. The manager approves, edits the text, asks for a review, or declines. No note or reply is written until then.
What record is kept?
The evidence as read from each system, the clause and threshold applied, the notice text as approved with name and time, the lease note and ticket reply as created, and the close-out or the escalation when the cure period ended.
Does it identify a person from video or send a notice by itself?
No. It reads zone counts and door events, not faces, and it never serves a notice. A person attributes the event to a resident, approves the notice, and delivers it the way your leases require.
Ask about Lease Violation

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy