Going live: onboarding a new association

Three parties, in order. A Vara operator provisions the association and its settings. The manager signs in, checks what the operator set up and fills in the association’s own content. Only then do residents hear anything, because a resident who registers before the roster is loaded is turned away by a machine for no reason.

1. 1
   Provision the association and its settings documents

   Operator

   The seeder creates the association record and six settings documents: brand, fee schedule, ticket categories, notification templates, approval policy and knowledge base index. It back-fills absent keys only, so re-running it never overwrites what a manager has since edited. Run it as a plan first, then apply.

2. 2
   Set the brand name

   Operator

   The association’s display name lives in the brand settings document and is what appears on the console, the portal and the public page. Getting it wrong is visible to everybody on day one.

3. 3
   Load the owner roster from public records

   Operator

   Import the county’s parcel layer for the association. Run it as a diff first. This is what makes owner verification possible, so it comes before any resident is invited.

4. 4
   Confirm the authentication controls are configured

   Operator

   Session secret, bot check, email delivery, public base URL, and optionally Google sign-in for Vara staff. Each unconfigured control is published on the health endpoint and written to the startup log. Do not go on until sign-in genuinely works, because every other step needs somebody signed in.

5. 5
   Add the association’s people and their roles

   Operator

   Managers and board members are members of the association with a role each. There is no invitation flow: a member record is what makes somebody a manager. Add the manager before you ask them to sign in.

6. 6
   Seed the ticket category catalogue

   Operator

   The seeder deliberately leaves the category list absent rather than inventing one, so this is a decision somebody makes on purpose. Until it is done, residents cannot file tickets.

7. 7
   Set the approval policy

   Operator

   Decide whether a board member’s document upload should land as a draft for review. It is off unless you turn it on, which means a board member’s upload publishes immediately by default.

An hour, honestly. Most of it is checking that what the operator set up matches the association you actually run.

1. 1
   Sign in and check the name

   Manager

   Ask for a sign-in link, open it within 15 minutes, and look at the top of the console. If the association’s name is wrong or generic, stop and tell the operator. It is one settings value and it is on every page a resident sees.

2. 2
   If the console answers 403, that is the member document

   Manager

   A signed-in caller with no staff role is denied, and the page says nothing about why. It means the operator has not created your member document yet. Tell them; there is no way for you to fix it and nothing you type will change it.

3. 3
   Open the resident roster

   Manager

   It will be empty until owners register, and that is correct. What you are checking is that the page loads and that the pending filter is there, because that queue is where your work will arrive.

4. 4
   Build the vendor directory

   Manager

   Add the trades the association already uses. Record each insurance expiry date, because a vendor with no date recorded shows as unknown rather than as covered, and unknown is easy to read as fine.

5. 5
   Agree the ticket categories with the operator

   Manager

   Decide what residents should be able to report, and have the operator seed it. Until that is done the portal explains that no categories are set up rather than showing a form that would be refused.

6. 6
   Decide how documents will reach residents for now

   Manager

   Document upload works where the deployment names its two storage buckets, and refuses where it does not, in which case the portal library will be empty. Check before the announcement: if it is empty, agree with the board how the CC&Rs get to owners in the meantime and say so in the welcome message, rather than letting people hunt for a page that has nothing on it.

7. 7
   Read Who can do what before you brief the board

   Manager

   The board can read everything in the console, can comment on a ticket where the resident sees it, and can mark a document superseded. Those last two surprise people. Better that the board hears it from you than discovers it.

Residents receive nothing automatically. There is no bulk invitation in the platform, so the association sends its own announcement pointing owners at the registration form. What happens after that is the same for everybody.

1. 1
   An announcement from the association

   Resident

   Written and sent by the association, not by the platform. It should carry the registration link and one sentence about what the portal does and does not do yet.

2. 2
   The registration form

   Resident

   Email address or mobile number, name, the address of the home, and optionally the last four of the parcel id or the deed book and page.

3. 3
   Either a sign-in link, or a wait

   Resident

   Confirmed registrations get a sign-in link by email that lasts 15 minutes. Held registrations get told they are held, and hear again once a manager decides. Unmatched registrations are told nothing was created and to check the address.

4. 4
   A portal with two working pages

   Resident

   Their own tickets, and the association’s published documents. Everything else in the portal navigation is a label with no link behind it.

Two ordinary jobs have no path through the platform, and both come up in the first few months rather than eventually. Agree with the board who does them before the situation arrives, rather than during it.

• Registrations arrive in bursts after the announcement. Most confirm automatically. Homes held in a trust or a company never do, so expect those in the pending queue.
• Check the pending queue daily at first. A held registration is somebody waiting, and the platform does not chase you.
• Every approval and rejection needs a reason. Write one somebody could read back to the owner.
• Expect the same three questions: how do I pay, where are the CC&Rs, and can I ask a question here. Have an answer ready for each.

If something refuses and the message does not tell you why, that is worth reporting rather than working around. The service is written to explain its refusals, so a refusal you cannot read is itself a defect.