Start here
What the property management platform does today
The surfaces that exist in the HOA property management product right now, who can reach each one, and what is deliberately not here yet.
Vara runs an HOA property management service at propmgmt.varapartners.ai. It has two signed-in surfaces: a management console for the people running an association, and a resident portal for verified owners. Today those surfaces cover people (registration and owner verification), work (tickets), and the trades the association uses (vendors). A governing document library exists too, though nothing can be put in it yet. Money, work orders and the chat assistant are not part of it at all, and this documentation says so in every place a reader might assume otherwise.
How to read these pages
Every article states which roles can do the thing it describes. Where a capability is described as unavailable, that comes from a single register rather than from the article, so it changes everywhere at once on the day it ships.
Six pages exist behind sign-in, plus a public landing page, a public contact form and a public registration form. Everything else in the navigation is a label with no link behind it, which is how this service says a surface has not arrived.
| What | Who can | Route |
|---|---|---|
| The management console The shell a manager works from. A resident is refused outright. | OperatorManagerBoardResident | GET /manage |
| The resident portal The resident shell. Staff roles are refused here: the portal is not a preview of what a resident sees. | ResidentOperatorManagerBoard | GET /portal |
| Resident roster and registration review The board can read the roster. Approving or rejecting a registration is a separate, narrower gate. | OperatorManagerBoard | GET /manage/residents |
| Ticket board Reading tickets is open to the board. Moving them is not. | OperatorManagerBoard | GET /manage/tickets |
| Vendor directory The board can look. Editing a vendor is operator and manager only. | OperatorManagerBoard | GET /manage/vendors |
| Governing document library A resident who lands here is redirected to their own copy of the library rather than refused. The page works; the library is empty and cannot be filled yet. | OperatorManagerBoard | GET /manage/settings/documents |
| Resident ticket list A resident sees their own tickets and never another resident’s. | Resident | GET /portal/tickets |
| Resident document library Current, published versions only. A draft cannot reach this page, and nor can anything else yet. | Resident | GET /portal/documents |
Six things are worth knowing before you go looking for them. Two of them are setup steps that have to happen outside the product, and until they do, filing a ticket and opening the management console both refuse. The full list, with the reason for each, is on the register page.
Filing a ticket
Waiting on setup data- What people expect
- A resident opens the portal, picks what the problem is, and files a ticket.
- Why it does not work today
- The ticket surface is deployed and works. The list of categories a ticket can be filed under is operator data held in the association's settings, deliberately never in code, and it has not been provisioned for the pilot association. With no categories the portal shows an explanation instead of a form, because a form whose submission would be refused is worse than no form. An operator-gated API route to seed the catalogue now exists in the service (`PUT /internal/associations/{slug}/ticket-categories`), but nothing in this website calls it yet, so seeding it today still means a person running a request against the service directly rather than a page in the admin console.
- What to do instead
- Residents should contact the management office directly until the categories are seeded. Managers can still read, transition, assign and comment on any ticket that already exists.
Checked against the code on 2026-09-08. Next review 2026-10-15.
Giving somebody a manager, board or operator role
Shipped, not configured- What people expect
- Add a manager or a board member to the association so they can sign in and use the management console.
- Why it does not work today
- A staff role comes from a member document held under the association, and until recently nothing in the service or its scripts ever wrote one: the service only read them, and the tenant seeder wrote the association and its settings documents and no member. That was a deadlock, because the provisioning API itself required an operator session and an operator session required one of those documents. An operator-gated route now writes them (`POST /internal/associations/{slug}/members`), it also accepts a Google-signed token from a service account, and the Vara admin console at `/admin/associations` has a form for it. What is still missing is a screen in the COMMUNITY's own console: a manager cannot add their own staff, so every addition goes through Vara. The console route for that does not exist yet.
- What to do instead
- Ask Vara to add the person; it is a form in the Vara console rather than a database edit. Residents are unaffected either way: registration creates a resident account, so the portal works whether or not a single staff member exists. Note that manager and board contact addresses are a different thing entirely and grant no sign-in access at all.
Checked against the code on 2026-09-09. Next review 2026-11-15.
Uploading and downloading governing documents
Shipped, not configured- What people expect
- A manager uploads the CC&Rs; a resident opens them from the portal.
- Why it does not work today
- Object storage is now wired: the service holds a real client, an upload writes the bytes and then claims the record, and a reader is handed a short-lived signed URL. What decides whether any of that works is the DEPLOYMENT. Each one must name its two buckets (PROPMGMT_DOCUMENT_BUCKET and PROPMGMT_ATTACHMENT_BUCKET), and it must name BOTH: the service wires all of its storage or none of it, because one set would mean documents worked and ticket attachments answered 503, which reads as a bug in attachments rather than as a deployment configured halfway. Where they are unset, every upload is still refused before anything is stored, and the console library, the resident library, publish, supersede and download are all operating on an empty collection.
- What to do instead
- On a deployment with its buckets set, nothing: upload the CC&Rs and publish them. Where they are not set, distribute governing documents the way the association distributes them today, and say so in the announcement rather than letting residents hunt through an empty page. The refusal names the reason.
Checked against the code on 2026-09-09. Next review 2026-10-15.
Dues, payments, the ledger and ACH
Not built- What people expect
- Residents pay dues in the portal; managers see receivables, payables, bank reconciliation and a board report pack.
- Why it does not work today
- None of it is built. The portal's 'Pay' entry and the console's Receivables, Payables, Reconciliation and Reports entries are labels with no links behind them. No route in the service accepts or records a payment, and the service holds no bank details for anyone.
- What to do instead
- Collect dues the way the association collects them today, outside this platform. Nothing in the portal will record a payment, so do not tell residents to look for one there.
Checked against the code on 2026-09-07. Next review 2026-12-01.
The grounded chat assistant
Written, not shipped- What people expect
- Ask the portal a question about the association's rules and get an answer drawn from the governing documents.
- Why it does not work today
- The chat pipeline was written and stopped in review, twice, without being merged. It is on a branch and not in the deployed service. There is no route for it: the portal's 'Ask' entry is a label with no link behind it, which is how this service says a surface has not arrived.
- What to do instead
- File a ticket from the portal, or email the management office. A person answers, which is what the portal's 'Ask' summary already promises.
Checked against the code on 2026-09-07. Next review 2026-12-01.
Raising a work order
Not built- What people expect
- Send a job to a vendor from a ticket and track it from raised to closed.
- Why it does not work today
- There is no work order surface and nothing that raises one. A ticket does have a work order field, and writing to it records a reference and nothing else. The service never checks that anything exists at the other end of that reference, and the page says so where a manager will read it.
- What to do instead
- Dispatch the vendor the way the association dispatches one today, then paste the reference onto the ticket so the record points somewhere. Move the ticket to dispatched so its state matches what happened.
Checked against the code on 2026-09-07. Next review 2026-12-01.
- If you are setting an association up for the first time, read Going live.
- If you want the exact answer to "can I do this", read Who can do what.
- If something refuses and you do not know why, read What is not available yet, then the FAQs.
- If none of those answer it, the management office can. Say what you were trying to do and what the screen said, and they can tell you whether it is a permission, a setup step or a genuine fault.
Still stuck?
That is a fair place to be, and it is usually faster to ask than to keep reading. Your association's management office can tell you whether what you are hitting is a permission, a setup step or a fault. Say what you were trying to do and what the screen said. If it needs changing at the service level, they will bring Vara in.