Running an association
Onboarding a community
The Vara-side walkthrough: every step needed to bring an HOA onto the platform, in order, with what each one decides and what happens if it is skipped.
4 sections of this article carry operator-only instructions. They are published so the whole picture is visible, and nobody outside Vara can act on them. They are marked where they appear: Before you start, The steps, Access and contact are not the same thing, When it is done.
Before you start
Operator onlyThis whole article is for Vara staff
Every step below happens in the Vara console at /admin/associations, which is gated to verified @varapartners.ai Google accounts. A manager or a board member cannot reach any of it, and nothing here is something to hand to an association.
Onboarding is one screen and a handful of steps, and the screen tells you which ones are outstanding. You do not have to memorise the order: create the community first, and after that the readiness list is the checklist.
- The association’s legal name and a short slug for it.
- The county parcel export as a CSV. This is the roster owner registration is matched against, so getting the right file matters more than getting it early.
- One email address for whoever will run the community day to day. They become the first manager.
- The ACH provider and general ledger the association will run on. Ask; do not guess.
- The CC&Rs, bylaws and any rules, as PDFs. These are uploaded later, by the community, in their own console.
The slug is permanent
It becomes part of every stored record. Changing it afterwards is a data migration rather than an edit, so pick the obvious one: lower case, hyphens, no year, no abbreviation only you would recognise. The display name is separate and can be changed whenever you like.
The steps
Operator onlyVara console only
Every step here except the last is taken at /admin/associations, which only Vara staff can open. The last one is the manager’s, and it is marked as theirs.
- 1Create the communityOperator
Vara console → Communities → Add a community. This writes the association record and the settings documents behind it, and invents no business values: every skeleton is left empty on purpose, because a default nobody chose is indistinguishable afterwards from a decision somebody made. Everything else needs this to exist first.
- 2Give somebody staff accessOperator
The single most important step, and the one that is easiest to leave until last. Until at least one manager or operator has a member record here, everybody who opens the management console is refused, which looks exactly like sign-in being broken rather than like a step nobody has taken. Grant the community’s manager the manager role. Grant operator only to Vara staff: it is authority over every community on the platform, not this one.
- 3Set the notification addressesOperator
Manager and board email addresses, either list alone or both, so you can set the manager’s before the board is elected. These are where mail goes and they grant nothing. An address here cannot sign in.
- 4Import the units and owners of recordOperator
Upload the county parcel export. Leave both checkboxes off for the first import and read what it reports: a parcel the roster does not recognise usually means the file is for the wrong community, and an import that would shrink the association usually means a truncated download. Turn a box on only once you have read the report and agree with it.
- 5Set the ticket categoriesOperator
What a resident may file a ticket about, and which fields each category requires. Until this is set the portal shows an explanation instead of a form, because a form whose submission would be refused is worse than no form. Sending a new catalogue replaces the whole thing rather than adding to it.
- 6Choose the payment railsOperator
The ACH provider and the general ledger. The service validates both and its refusal names the whole valid set, including the ones that were researched and never built, so if you are unsure, send your best guess and read what comes back.
- 7Upload the governing documentsManager
Not a Vara step. Once the manager has access they upload the CC&Rs, bylaws and rules in their own console at Settings → Documents, and publish them. That is the point of doing staff access early: the association does its own document library rather than emailing PDFs to us.
Every step can be re-run
Re-sending the same thing is a no-op rather than a duplicate or an error. If you are not sure whether a step landed, do it again and read the answer. The readiness list on the community’s page is the authority on what is left.
Access and contact are not the same thing
Operator onlyBoth of these forms are Vara’s
A community cannot add its own staff or edit its own contact list today, so every one of these decisions is taken by whoever is doing the onboarding.
This is the mistake this product invites, and it looks correct afterwards from both sides. Two forms on the same page take an email address and do entirely different things.
What each form does
| Form | What it writes | Can that person sign in? |
|---|---|---|
| Staff access | A member record with a role | Yes. This is the only thing on the platform that lets anybody into the management console. |
| Notification addresses | A list of addresses on the association record | No. Not now, not later, and no amount of adding them again will change it. |
The failure is silent from both ends
Somebody added only as a contact is told they have access, finds the console refuses them, and reports that sign-in is broken. Nothing in the logs distinguishes that from a person who was never added at all. If somebody says they cannot get in, check the staff access list first and the contact list second.
When it is done
Operator onlyThe community’s page says Ready when every step is done. That is a statement about configuration and not about the association being live: nobody has been told the portal exists, no owner has registered, and no document has been published unless the manager has done it.
- Sign in as the new manager yourself, once, and confirm the console opens. It is the only way to be sure the staff access step did what you think it did.
- Ask the manager to upload and publish at least the CC&Rs before anybody is invited, so the portal library is not empty on the first visit.
- Then follow the going-live article, which is written for the manager and covers the announcement and the registration queue.
What onboarding does not create
No storage bucket, no service account, and nothing in Google Cloud at all. Communities are separated by path inside two shared buckets that already exist, which is why adding one is a form rather than an infrastructure change. If somebody tells you a new community needs a bucket, it does not.
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.