This document is the current source of truth for HOAfy units, members, invitations, directory, requests, violations, voting, and documents. It describes implemented behavior and material limitations.
Units and Ownership
Watch units and property records in the demo
A unit is the property or assessment account. A member is a person or placeholder record associated with the community. A unit can have several owners, with one designated as primary for delivery and operational defaults.
Unit records support labels or addresses, lifecycle state, ownership links, and summary information. Authorized users can create, import, rename, merge, deactivate, and restore units. Deactivation preserves history. Merge should be reserved for genuine duplicates because invoices, requests, violations, and ownership links can be affected.
Do not duplicate a unit to represent co-owners. Ownership and application access are distinct: import creates or updates roster relationships, while an invitation lets a person claim application access. A virtual member can exist before registration.
Members, Roles, and Status
Member administration supports names, email and phone, association role, status, unit assignment, primary-owner designation, and detail history. The roster can include owners, residents, board members, committee roles, property managers, and vendors according to the fixed role model.
Account Owners and users with member-management permission can administer records, assign units and roles, and send invitations. Other authorized users receive a privacy-reduced directory. Homeowners can manage their own profile and preferences but cannot administer the roster.
Account Owner removal uses a two-party consent flow and cannot be performed as an ordinary role edit. Deactivation should preserve attributable invoices, communications, votes, and audit history.
Email is used as the user's key for identity matching, invitation matching, and many delivery workflows. After a member is created, administrators cannot edit that member's email address because the member owns their profile and changing the email would represent a different user. If a member was added with the wrong email address, delete that member and create a new one with the correct address. The replacement can be added manually with Add Member, through bulk import, or by sending an invitation from the Invitations tab.
SMS phone numbers should use E.164 format. Contact data alone does not override communication preferences or SMS consent.
Invitations and Directory
Individual invitations are created for a roster email and intended role, then tracked as pending, accepted, expired, or revoked. Invitations expire after seven days and must be accepted using the invited email address. Revoke and reissue an invitation sent to the wrong address; do not share its token.
Bulk invitation tools operate on existing roster members. Import never sends invitations automatically, allowing administrators to review names, roles, ownership, and contact quality first.
The directory provides Board and Members views, name search, role filters, unit context, avatars, and details. Contact fields are withheld from callers without member-management permission.
The current directory does not provide per-field visibility preferences, household profiles, vehicle or pet records, radius search, or a general roster export.
Requests
Core request types, submissions, staged review, comments, fees, SLA tracking, and work-order conversion are available. Advanced field rendering and durable named assignment are incomplete.
Watch request management in the demo
Administrators can define request types with a name, description, active and owner-visible state, custom and required fields, conditional visibility, review stages, allowed actions, SLA targets, escalation, optional SLA auto-approval, fees, and versioned configuration.
The model supports text, number, date, selection, file, photo, and signature-like field definitions. Current owner forms fully handle common scalar and conditional fields. File, photo, and signature definitions can fall back to basic text controls, and backend submission does not consistently enforce every declared pattern, range, choice, or type.
The current owner workflow is:
- Select an active owner-visible request type.
- Complete the visible required fields and review any fee summary.
- Submit into the first workflow stage and SLA clock.
- Exchange owner-visible or internal comments.
- Approve, reject, advance, request information, escalate, or complete the request.
A displayed fee does not mean payment is collected during submission. Submitted field values cannot currently be replaced through a dedicated owner revision step. Reassignment records history but does not persist a durable named assignee in every path.
SLA-based auto-approval operates only when configured and should not be used where governing documents or law prohibit approval by silence. Eligible maintenance requests can be converted to work orders while preserving source context.
Violations
Watch violation management in the demo
The core notice and hearing lifecycle, templates, owner views, history, photos, fine data, and calendar synchronization are available. The enforced progression is:
- Draft
- First Notice
- Second Notice
- Hearing
- Resolved
Transitions create history, and hearing scheduling creates or updates a calendar event. Authorized staff select the unit and member, describe the issue, optionally select a template, record notes and fine information, and add hearing details.
Existing evidence photos can be displayed, but the current web create/edit form does not provide a complete photo-capture workflow. The current transition path sends a system notice and does not consistently render the stored template version selected on the violation. Verify exact statutory text and delivery before advancing a notice.
A stored fine does not automatically create an invoice or GL entry. Dedicated owner appeal/evidence submission, escalating fine automation, repeat-offender automation, and lien workflow are not complete. Handle appeals through an approved request or communication channel and preserve the decision record.
Voting and Surveys
Watch community voting in the demo
Core web voting is available for elections, resolutions, multi-question ballots, and surveys. It includes eligibility snapshots, weighted ballots, proxies, results, and audit packets.
Eligibility is snapshotted when a vote opens so later roster changes do not rewrite the electorate. Current filters emphasize roles and unit IDs rather than the full communications audience engine. Weighted unit voting and joint-owner allocation are supported and must be configured according to governing documents.
The current lifecycle is:
- Draft and review wording, choices, eligibility, weights, and quorum.
- Explicitly open the vote.
- Collect eligible ballots and supported proxies.
- Record supported mail or in-person ballots for hybrid meetings.
- Explicitly close the vote.
- Review results, quorum, and audit information.
- Purge secret-ballot identity links according to retention policy.
Start and end dates do not automatically open or close a vote. Automated reminders and postal ballot delivery are not available.
Identified voting retains voter attribution for authorized review. Anonymous voting separates identity from content and supports identity purge. Small electorates, weighted choices, exports, and procedural records can still create inference risk, so it should not be represented as absolute anonymity outside the defined process.
Documents
Watch document management in the demo
Core folders, multi-file upload, public or board-only visibility, PDF and image preview, download, delete, ZIP import, and references from supported workflows are available.
The current permission model is broad: public or board-only. Committee-specific access and custom ACL inheritance are not implemented. Treat public visibility as intentional disclosure; owner records, ballots, violations, financial working papers, and confidential board material must not be made public.
Formal version history, OCR/full-text search, effective dates, required-document completeness, expiring share links, richer retention, and complete packet/export tooling are not available. Replacing a file should not be assumed to retain a prior-version chain. Preserve dated copies when version history matters.
Document ZIP import recreates safe archive paths under the selected destination and applies one chosen visibility to imported folders and files. Detailed import limits and lifecycle are in HOA Data Import, Migration, and Export.
Owner Experience
Watch the homeowner portal in the demo
The web owner portal currently provides role-aware dashboard information, one-time payments and payment history, autopay, statements, requests, violations, voting, documents, calendar, directory, and personal preferences. The Flutter app provides broad association-aware routes for many of the same workflows, but full web parity and all provider handoffs are not complete.
Owners see only records authorized for their selected association and unit relationships. A person with memberships in several associations must switch context; data is not combined into a cross-association owner view.
Operating Guidance
- Normalize unit labels before import and model co-owners on one unit.
- Use stable personal email addresses rather than a departing officer's shared login.
- Preview bulk invitations and remove stale or role-account addresses.
- Review Account Owner assignments after every board transition.
- Keep request types focused and avoid unsafe SLA auto-approval.
- Use internal request comments for deliberation and owner-visible comments for requirements and decisions.
- Cite governing provisions and objective evidence in violations.
- Confirm hearing timezones, notice lead time, recipients, and delivery methods.
- Verify fines in Billing rather than assuming automatic posting.
- Freeze clean roster and unit data before opening a vote.
- Test quorum and voting-weight calculations with known examples before opening.
- Retain the voting audit packet, certified result, and meeting minutes together.
- Verify document visibility immediately after upload or import.
- Use predictable document folders and put effective or meeting dates in filenames.
- Retain legally authoritative ownership, election, and adopted-document records as required outside the product.
Support Answers
- Does roster import email everyone? No. Import and invitation delivery are separate.
- Can I change a member's email address? No. A member's email is their identity key in HOAfy and cannot be edited after creation. Delete the incorrectly created member and add a new one manually, through bulk import, or from the Invitations tab.
- Can two owners share one unit? Yes. Link both owners to the same unit and designate a primary owner when needed.
- Why can an invitation not be accepted? Verify that it is pending, less than seven days old, and matches the sign-in email.
- Can residents see everyone's email and phone? Not by default. Contact fields require member-management permission.
- Can the roster be exported? No general customer-facing roster export is currently available.
- Can an owner upload a photo or sign every request form? Those field types can be configured, but the current form does not provide complete native controls for every type.
- Does an overdue request auto-approve? Only when that stage explicitly enables SLA-based auto-approval.
- Does a violation fine charge the owner automatically? No. The corresponding invoice and accounting entry must be verified or created separately.
- Can an owner appeal a violation in the portal? There is no dedicated appeal action in the current owner view.
- Does a vote open or close automatically? No. Both transitions are explicit administrative actions.
- Does HOAfy provide a dedicated resale-certificate workflow? Not currently.