Summary and recommendation
Yardi user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Yardi ships two distinct platforms with separate user-management surfaces: Yardi Breeze, aimed at smaller portfolios, and Yardi Voyager, the enterprise-grade system used by larger operators.
Both use role-based access control, but Voyager's permission model is substantially more complex and is configured during implementation rather than through self-service admin tooling.
Because Yardi gates nearly all procedural documentation behind its Client Central portal, administrators without an active support login will find public guidance sparse across every app and module they need to manage.
Quick facts
| Admin console path | Settings / Administration > Users and Roles (exact labels vary by tenant) |
| SCIM available | Yes |
| SCIM tier required | Enterprise (Voyager) |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| System Administrator | Full access to system configuration, user setup, and all modules as documented in Yardi Voyager implementation guides. | Voyager (Enterprise) | Yardi does not publish granular role definitions in public-facing documentation; specifics are delivered via implementation and training engagements. | ||
| Standard User | Access limited to modules and functions assigned by administrator; role-based restrictions apply per property or portfolio. |
Permission model
- Model type: role-based
- Description: Yardi Voyager uses a role-based access control model where administrators assign users to roles that control module and function access. Yardi Breeze uses a simpler user-level permission assignment. Specific permission granularity is not publicly documented.
- Custom roles: Unknown
- Custom roles plan: Not documented
- Granularity: Expect administrative access to be separated from standard user access, with exact scopes configured per tenant.
How to add users
- Log in as an administrator.
- Open settings or administration and navigate to users.
- Choose the add or invite user action.
- Enter the user's work email and assign the appropriate role.
- Save the user and complete any activation or SSO steps required by the tenant.
Required fields: Work email address, Role
Watch out for:
- Yardi does not publish step-by-step user-creation workflows in public help documentation. User setup procedures are typically covered in implementation training or via Yardi's client support portal (Client Central), which requires an existing client login.
- User provisioning details for Voyager are delivered through Yardi's implementation team and are not available in publicly accessible documentation.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (Voyager) |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Official public documentation does not explicitly describe whether user accounts can be deleted or only deactivated. No verified source confirms either behavior.
- Open the users area as an administrator.
- Locate the user to offboard.
- Disable, revoke, or remove the account using the controls available in that tenant.
- Review any integrations, service accounts, or credentials associated with the departing user.
| Data impact | Behavior |
|---|---|
| Owned records | Tenant data remains in the workspace; public docs do not describe user-owned content semantics in detail. |
| Shared content | Shared content and workspace records typically remain available unless separately removed or reassigned. |
| Integrations | Review service credentials, workflow ownership, and integrations separately during admin offboarding. |
| License freed | Seat reuse behavior is contract-dependent and not publicly documented in detail. |
Watch out for:
- Deactivation and deletion behavior is not documented in publicly accessible Yardi help resources. Clients should consult Yardi Client Central or their account representative for authoritative guidance.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Yardi Breeze | Full platform access for residential or commercial property management | $1/unit/month (minimum $100/month) |
| Yardi Voyager | Enterprise property management platform; pricing and seat structure are custom | Custom (~$1,200+/month as reported; not confirmed by official public pricing page) |
- Where to check usage: Settings / Administration > Users and Roles
- How to identify unused seats: Review the tenant user list and any visible login or activity metadata. No public unused-seat report was verified.
- Billing notes: Yardi does not publish seat-level billing details publicly. Voyager pricing is negotiated directly with Yardi sales. Breeze pricing is unit-based, not per-seat.
The cost of manual management
Voyager's role configuration requires administrator-level access that most staff cannot exercise independently, meaning every app permission change routes through a small group of credentialed admins or the Yardi implementation team.
Breeze uses simpler user-level assignment, but its unit-based pricing model means seat tracking is not a native workflow - there is no documented path to identify unused accounts or reclaim licenses from the UI. Without a structured offboarding process, dormant accounts accumulate silently across every app tied to a user's Yardi access.
The decision
Manual management is viable for small Breeze deployments where the user count is low and turnover is infrequent.
For Voyager environments spanning multiple properties or portfolios, the combination of opaque role hierarchies, gated documentation, and implementation-dependent setup creates compounding overhead - and the risk of access persisting across every app long after an employee has left.
Teams should confirm deactivation versus deletion behavior directly with their Yardi account representative before building any offboarding workflow, as this distinction is not resolved in any publicly available documentation.
Bottom line
Yardi's manual user-management story is functional but heavily dependent on implementation support and Client Central access, neither of which is self-serve. Breeze is manageable at small scale;
Voyager demands a deliberate, documented internal process to avoid permission drift and orphaned accounts across every app in the portfolio. Any team operating Voyager at scale should treat user lifecycle management as an ongoing operational commitment, not a one-time setup task.
Automate Yardi workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
