# Board Reference: Insurance, Violations, Collections, Rule Changes, Conflict of Interest, Budget Distribution Six smaller board-portal pages, documented together rather than as six separate tutorials since each is simple on its own: three are read-only reference views, three are single-purpose action pages. > **A note on this guide:** the three read-only pages (Insurance, > Violations, Collections) were confirmed against the live database > directly — every figure shown was cross-checked against the actual > table it reads from. The three action pages (Rule Changes, Conflict of > Interest, Budget Distribution) were each walked once with a real > submission, through the live site, using the demo association ("200 > River Drive Condominium") specifically because two of the three actions > trigger real notifications (email + in-app) to board members or > superadmins — the demo association's board members use a non-deliverable > `@200riverdrive.demo` address, so no real person receives mail from > testing this. All test data (the proposed rule change, the COI > disclosure, the budget distribution record, their notifications, and > their audit log entries) was deleted and verified gone afterward. 🎥 **See this in the walkthrough video:** [Board Walkthrough, starting at 0:42](https://myaccount.joantool.com/demo.php?video=board&t=42) — covers Collections. ## Insurance (`board/insurance.php`) — read-only Lists active insurance policies for your association: type (Master, Liability, D&O, Flood, Umbrella, Workers' Comp, Other), policy name, carrier, policy number, coverage amount, annual premium, effective/expiry dates, a status pill (**Current** / **Expiring Soon** within 60 days / **Expired**), and the agent's name and phone if on file. A "View Policy" link appears if a document was uploaded for that policy. With no policies on file, the page shows a plain empty state rather than an error — confirmed directly against a real association with zero rows in `association_insurance`. ## Violations (`board/violations.php`) — read-only Lists violations for your association with a status filter (All / Open / Cure Period / Fined / Resolved / Waived) and a unit/street search box. Each row shows the unit, violation type, status, cure deadline (with days remaining or "EXPIRED Xd ago" once past due), when it was noticed, the fine for that specific violation, and the unit's total year-to-date fines across all violations. A permanent banner states MN SF1750's caps: no single fine over $100, no more than $2,500 combined per unit per year — and the page visually flags any figure that exceeds either cap. This page is intentionally **read-only** — moving a violation between statuses (e.g. out of an expired cure period) is an admin action on a separate page, not something board members do here. Confirmed directly: a real violation with an expired cure period displayed correctly as "EXPIRED 44d ago" with no board-side action available, which is expected, not a bug — `admin/violations.php` is where status changes actually happen, and it has its own overdue indicator for admins. ## Collections (`board/collections.php`) — read-only Lists active (non-resolved, non-closed) collection accounts: unit, owner, balance owed, balance excluding attorney fees, days outstanding, status (Delinquent / Meet & Confer / Collection Action / Foreclosure), whether the required meet-and-confer step is complete, attorney fees for collections vs. foreclosure (collections has its own MN SF1750 cap — $1,500, flagged visually if exceeded; foreclosure attorney fees have no statutory cap — they're governed by the association's own declaration/ bylaws instead), and a foreclosure eligibility column that explains in plain language exactly why an account isn't yet eligible (balance below $5,000 excluding attorney fees, and/or fewer than 180 days outstanding — both are spelled out individually if unmet, not just a generic "not eligible"). ## Rule Changes (`board/rule-changes.php`) — action page Tracks proposed governing-document rule changes through MN SF1750's required 60-day member notice period. Click **+ Propose Rule Change**: - **Change Type\*** (Modify existing / Adopt new / Revoke), **Intended Board Meeting Date** (optional, but if set must be at least 60 days out — the form's date picker itself enforces the minimum and a matching server-side check rejects anything earlier with a specific message naming the earliest valid date). - **Current Rule / Context\*** and **Proposed Change\*** — free text. **Confirmed directly:** submitted a real proposal with a meeting date 65 days out. It saved instantly with status **draft**, and — since this association has two active board members — both received a real notification (in-app + email, `email_sent=1` for both) titled "Rule Change Proposed." From there, an active proposal shows three possible actions: **Mark Notice Sent** (records today as the notice date and computes a 60-day comment-period end date), **Mark Adopted** (only available once notice has been sent and the 60-day comment period has actually elapsed), and **Mark Revoked** (always available). A red border and "Notice Required" badge appear automatically on any proposal whose meeting date is within 60 days and hasn't had its notice marked sent yet. Finalized proposals (adopted or revoked) move to a separate History table. ## Conflict of Interest (`board/conflict-of-interest.php`) — action page Tracks each board member's annual MN SF1750 conflict-of-interest disclosure — the same disclosure that gates large-contract approvals (see the Board Approvals guide). Shows a full board roster with each member's filing status for the current year, and a table of what's actually been disclosed (vendor/business name, nature of the relationship, estimated value, and relationship type, for anyone who reported a real conflict). If you haven't filed yet this year, a **+ File My [year] Disclosure** button and an amber "Action Required" banner appear. The form asks whether you have a conflict to disclose; answering **Yes** reveals additional fields (vendor/business name, relationship, nature of the interest, estimated annual value) that are required only in that case. Every disclosure requires checking an acknowledgement statement and entering your name before it can be submitted. **Confirmed directly:** filed a real "no conflict" disclosure. It saved correctly (vendor recorded as "N/A", nature as "No conflict to disclose", `has_conflict=0`), the board's filing-status table updated immediately to show that member as Filed, and the association's superadmin received a real notification. **One filing per board member per year is enforced** — the code checks for an existing disclosure for the same board member and year before allowing a new one; attempting a second submission for the same year is rejected with a message pointing to contacting admin for an amendment, not silently allowed to duplicate. ## Budget Distribution (`board/budget-distribution.php`) — action page A single-purpose compliance record: MN SF1750 requires the annual budget be distributed to all unit owners before the annual meeting. The page shows days remaining until the association's next annual meeting (pulled from `events`, if one is scheduled) and, once distribution is confirmed, locks the record for that fiscal year. The confirmation form asks for the distribution date (defaults to today, can't be set in the future), method (Email / Physical Mail / Both), number of units notified (pre-filled from the association's own unit count), and optional notes. **Confirmed directly:** submitted a real confirmation for the current fiscal year. It saved correctly and the page immediately switched to its locked state — a green checkmark, "Budget Distributed," the date and method exactly as submitted, and the note **"This record is locked. Contact a superadmin to make corrections"**; the confirmation form itself disappears once locked, so there's no way to accidentally resubmit or overwrite it from this page. Unlike the other two action pages here, this one does **not** send any notification — confirmed directly (zero new rows in `notifications` after submitting), which makes sense since distribution is something the board does *to* the owners outside the app (email/mail), not an in-app event anyone else needs alerting about. --- No bugs or friction were found while walking these six pages — all three action flows behaved exactly as documented (correct validation, correct notifications going only where expected, correct duplicate/lock protections), and all three read-only pages' figures matched the database exactly.