Yardi Voyager User Roles & Permissions Setup for HOA Board & Managers

In Yardi Voyager, configure board members and managers by creating a security role for each job type, assigning only the needed permissions (menu access, functions, reports, and data scope), then linking each user to the correct role and property/HOA entity. Test with a “least access” approach: start minimal, confirm they can do their tasks, then add only what’s missing.

 

Key terms (plain English)

 

• User: a login for one person.
• Role: a template of what that person can see and do.
• Permission: a specific allowed action (view, add, edit, post, approve).
• Data scope: which associations/properties/records they can access.

 

Step-by-step setup (works even if everything else is already configured)

 

• Plan roles first: typically “Board Read-Only”, “Board Treasurer”, “Manager/AP”, “Manager/AR”, “Manager Full”. Avoid one shared “Admin” role.
• Create or copy a role in Voyager security/admin area: copy a similar role, rename it, then remove anything not needed.
• Set menu/module access: only enable the screens they must use (e.g., Owner/Resident, GL reports, AP, AR, Violations, Documents). If a menu is hidden, the user cannot reach it even if other permissions exist.
• Set function rights: choose view-only vs edit/post. For board members, default to view and report run only. For managers, allow only the posting functions they truly own.
• Restrict data scope: assign which HOA entities/properties they can see. Board members should be limited to their association only. Managers should be limited to their portfolio.
• Assign the role to the user: edit the user record, attach the role, and confirm the user is linked to the correct property/HOA entity list.
• Set approval controls if used: require approvals for invoices, payments, journal entries, or owner credits. Give board treasurers approval rights only if policy requires it.
• Test with impersonation/test login: verify they can run needed reports and cannot access restricted areas (other associations, bank setup, user admin).

 

Common mistakes that cause “access denied” or overexposure

 

• Giving a board member a manager role “just to make it work” (creates privacy and fraud risk).
• Forgetting data scope: user can see the menu but no records, or worse, sees all properties.
• Allowing posting rights (checks, JE, charge posting) when only review was intended.
• Leaving access to bank accounts, vendor maintenance, user security enabled.

 

Troubleshooting checklist

 

• If menus are missing: role lacks module/menu access.
• If records are blank: user not assigned to the right property/HOA entity scope.
• If reports fail: role lacks report permissions or the report is tied to a different module.
• If changes won’t save: user has view-only rights; add edit rights only for that screen.

 

When to contact Yardi support or an admin

 

• Need to change system-level security, custom menus, or database-wide role templates.
• Unsure which permission controls sensitive actions like payments, bank reconciliation, or GL posting.
• Complex setups with multiple entities, shared services, or custom security groups.