Start here
What is not available yet
Every capability people expect from the platform that does not work today, why each one does not, and what to do instead.
Software that half works is harder to use than software that refuses. This page is the complete list of things the platform looks like it should do and does not, so that nobody has to discover one of them at the worst possible moment.
It is also the only place any of this is written down. Every article that would otherwise describe one of these capabilities renders from this same list, so when one of them ships there is a single edit and every page changes with it.
How each claim is kept honest
Every entry below carries a check against the service’s own source: a pattern that must still match, or must still not match. When a capability lands, its check fails and this page has to be rewritten before the documentation can be published again. Entries also carry a review date, which is the backstop for the ones no automated check can see.
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.
Photos and files on a ticket
Shipped, not configured- What people expect
- Attach a photo of the problem to a ticket.
- Why it does not work today
- The two routes that arrange an upload are deployed and gated, and the storage behind them is now wired. As with governing documents, whether they work is a property of the deployment: it must name PROPMGMT_ATTACHMENT_BUCKET, and PROPMGMT_DOCUMENT_BUCKET with it, because the service wires all of its storage or none of it. Where they are unset the refusal is honest about being a deployment state rather than a mistake by the person uploading.
- What to do instead
- On a deployment with its buckets set, attach the photo. Where they are not, describe the problem in the ticket text and email photos to the management office if they matter; a manager can record the detail in a comment so it stays with the record.
Checked against the code on 2026-09-09. Next review 2026-10-15.
Rebuilding the knowledge base
Shipped, not configured- What people expect
- The 'Reindex now' button on the documents page rebuilds a searchable index of the association's governing documents.
- Why it does not work today
- The button is real and the route behind it is real, and pressing it today returns an error rather than starting anything. The service has no Cloud Run Jobs runner installed, so there is nothing for it to start. Half of what the job itself would need has since arrived: the object storage client that reads the stored files is now installed and wired, so a job could at last open a document. The other half has not: nothing produces the embeddings, so there is still no route to a built index. The button refuses on purpose. A button that answered 'started' and started nothing would be worse.
- What to do instead
- Expect the error and read it: it names the reason. Nothing is damaged by pressing it, and any index that already exists is untouched. The service's own error message ends "An operator can still run the job directly against Cloud Run", and that sentence is still wrong, though for one reason now rather than two: the job can read the documents, and cannot turn them into vectors.
Checked against the code on 2026-09-09. Next review 2026-12-01.
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.
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.
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.
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.
Turning an amenity fob on or off
Not built- What people expect
- Deactivate a fob from the platform when somebody moves out.
- Why it does not work today
- The platform has the seam for it and no integration behind the seam, because the association's access control vendor has not been identified. The shipped adapter files a task for a person instead of touching a panel, and it reports the fob's state as unknown rather than guessing, because a wrong 'deactivated' is the answer somebody stops checking.
- What to do instead
- Treat the task the platform files as the actual work item and deactivate the fob in the vendor's own system. The credential stays live until a person acts.
Checked against the code on 2026-09-07. Next review 2026-12-01.
For balance, because a list of absences reads worse than the product is. Sign-in works. Owner registration and verification against public records works, including the review queue for the ones a machine should not decide. The ticket board works, with a nine-state machine, an unalterable history and internal notes a resident cannot reach. The vendor directory works, with an audit entry per change.
The document library is the awkward case and it belongs on neither list cleanly. Its pages, its publishing rules and its resident view are all built and behave correctly. They are also all operating on a collection that cannot have anything in it, because the only code path that creates a document record runs after a storage check that always refuses. So the library works and is unusable, and the register entry above is the honest description of it.
What is missing from the rest is mostly money, one assistant, and the two setup steps that have to happen outside the product before anybody can file a ticket or open the management console.
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.