Elevate Your Real Estate Operations with Expert Yardi Solutions

What good BAU support looks like CASE STUDY

1. Executive Summary

The “Good” BAU Target State: A successful Yardi BAU model functions as a Center of Excellence (CoE). It balances daily user support (Helpdesk) with continuous platform optimization. By implementing tiered support and automated health checks, the organization can expect a 30% reduction in monthend stress and a 99% accuracy rate in system-driven financial reporting.

2. Introduction

Yardi BAU Optimization

Objective: To transition Yardi support from a reactive “break-fix” model to a proactive Service Management framework that ensures financial integrity, operational continuity, and platform scalability.

Current State Challenges:

• High Latency: Critical accounting issues during Month-End Close (MEC) are not prioritized, leading to reporting delays.
• Knowledge Silos: Reliance on a few “super-users” creates significant operational risk.
• Data Integrity: Lack of standardized change management in the Live environment leads to reconciliation discrepancies.

3. Background Information

The “Access Creep” Security Breach – The Problem: An internal audit revealed that 15 former employees still had active “System Admin” access to Yardi Voyager because the HR offboarding process wasn’t linked to IT.

4. Case Analysis (SWOT)

Identified the Root Cause: Process Silos. HR (onboarding/offboarding) and IT (Yardi permissions) were not communicating. In Yardi, “Admin” rights are often given as a shortcut to bypass complex security setups.

5. Proposed Solutions & Alternatives

To solve the bottleneck came in The BAU Strategy: RBAC (Role-Based Access Control).

• Instead of custom-fitting every user, “Good” BAU creates “User Templates.”

6. Implementation & Recommendations

We implemented a “90-Day Stabilization Plan”:

1. Days 1-30: Audit all active Yardi users and clean up “Admin” permissions.
2. Days 31-60: Build a “Knowledge Base” of the top 20 recurring issues.
3. Days 61-90: Automate “Month-End Health Checks” to catch errors before the close begins.

7. Conclusion & Lessons Learned

The Shift from Trust to Verification

The successful resolution of the governance breakdown wasn’t achieved by a one-time cleanup, but by shifting the BAU (Business As Usual) culture from “Implicit Trust” (assuming people have the right access) to “Continuous Verification” (systematically proving they do).

By integrating Yardi access with HR lifecycles and moving to a Role-Based Access Control (RBAC) model, the organization transformed its support desk from a “password reset center” into a “compliance partner.”

This change protected the company from both external breaches and internal fraud, while significantly reducing the manual workload on the IT team.

User Management

1. Introduction

Managing user creation in Yardi requires a balance between operational speed and strict security controls. A well-defined process ensures that users have exactly the access they need to perform their jobs without compromising data integrity.

2. Standard end-to-end user management workflow for New User creation.

1. Request and Approval Phase
2. Technical Setup in Yardi
3. Communication and Onboarding
4. Post-Creation Audit

1. Request and Approval Phase

Standardized Request Form: Even before the user the created in Yardi system an Access request form or User creation form should be sent through email or ticketing system. Role Identification: The requester should mention the role that needs to be assign to the user for the workflow approval matrix is required.

2. Technical Setup in Yardi

Create the User Record: User ID: Follow a consistent naming convention, also enter the required information to create the user.

Assign Security Groups: Assign the user to one or more Security Groups.

Property Security: Filter the user’s access by Property List or Property Group. Ensure they only see the assets within their specific portfolio.

3. Communication and Onboarding

Welcome Email: Send a secure notification with the Yardi URL, Username, and instructions for the initial login/password reset.

Multi-Factor Authentication (MFA): Ensure the user is prompted to set up MFA

4. Post-Creation Audit

Verification: Does the setup match the original request?

Access Test: Does the user have access to the correct properties?

3. Offboarding/Deactivation of the user

A streamlined Offboarding/Deactivation Workflow is just as important as the setup. Promptly deactivating users protects your data and ensures you aren’t paying for Yardi licenses you no longer need.

1. Trigger & Timeline

The process should begin the moment Department Head confirms an employee’s last day (or immediate termination).

• Standard Exit: Deactivate at the close of business on the last day.
• Immediate Exit: Deactivate instantly upon notification.

2. Technical Deactivation Steps

Disable the User ID

1. Uncheck “Active”: This is the most important click. It immediately prevents any further login attempts.
2. Remove Security Groups: Strip all groups from the user profile. This ensures that even if the account were accidentally reactivated, it would have zero permissions.
3. Wipe Property Access: Remove all property filters.
4. Email Notification: If using Yardi’s automated notifications, ensure the user’s email is removed from any distribution lists or alert groups.

Workflow & Approval Clean-up – If the user was part of an approval chain (especially in PayScan or Work Orders), their departure can stall your operations.

A Roadmap was ensured for the user management while the clean-up process was carried out for a client

• This roadmap was designed to move the organization from potentially ad-hoc setups to a structured, audit-proof environment.

1.Recommendations for 100% Quality check

• The “Gold Standard” Role: Create a master list of what a “Property Manager” should see. This prevents “Permission Creep” where users accumulate access they no longer need.
• The Paper Trail: Quality is defined by evidence. Ensure that for every user created, there is a corresponding PDF or ticket stored in the archives.
• Security Controls – Minimal permission overlaps and secured entry points

2. Conclusion & Lessons Learned

Through the implementation of these four phases, several critical lessons typically emerge for Yardi Administrators and Technology Specialists:

1. Documentation is the Only Source of TruthFinal Scope:
2. “Least Privilege” Boosts Productivity
3. Offboarding is More Critical than Onboarding.
4. The “Continuous Audit” phase is required for the clean environment of the User management.

The Ghost Integration (API Failure)

Introduction

Voyager usually refers to a specific technical breakdown where data appears to exist in one system but is “invisible” or inaccessible to the other due to synchronization, permission, or schema mismatches. While “Ghost” isn’t an official Yardi product name, the term is frequently used by integration consultants and developers to describe orphaned records or asynchronous failures where the API returns a success code, but the data never actually populates the Yardi UI.

Primary Causes of “Ghost” Failures.

1. Vendor Gating & Permissions
2. Technical Troubleshooting Workflow
3. The “Silent Failure” Scenario

Primary Causes of “Ghost” Failures

In Yardi integrations, these failures typically stem from three specific architectural bottlenecks:

1. Vendor Gating & Permissions
2. SOAP vs. REST Discrepancy
3. Relational Dependencies

Technical Troubleshooting Workflow

If you are currently experiencing an API failure where data is missing despite “Successful” logs, follow this hierarchy:

The “Silent Failure” Scenario

Case History: An integration pushes 100 residents. The API returns 200 OK. However, because the Property ID in the (Third party Application) didn’t perfectly match the Property_Code in Voyager, the records are stored in a temporary interface table but never “promoted” to the live Resident table. They are “Ghosts”—present in the database but invisible to the property manager.

Issue Fixed: Direct Database Query: checked the Web_Service_Log table to see if the data is stuck there.

Reprocess via Interface: Navigated to Interfaces > Communications > Review within Yardi to manually push “pending” or “failed” records that the API didn’t fully commit.

Recommendations for 100% Quality check

The “Triple-Check” Reconciliation Strategy

To ensure zero data loss, your integration architecture should follow a three-tier validation process.

Conclusion & Lessons Learned

The “Ghost Integration” phenomenon with Yardi is a masterclass in why API response codes are not the same as database integrity. Achieving a 100% Quality Check requires moving from a “fire and forget” mindset to a “verify and reconcile” architecture.

We practiced these three pillars to prevent future “Ghost” incidents:

1. Automated Reconciliation: Run a daily “Variance Report” comparing the source system IDs against Yardi’s Identification_ID.
2. Negative Testing: Purposefully send bad data (e.g., a lease for a non-existent unit) to see exactly how your system handles the error. If it shows “Success”, your QC is broken.
3. Human-in-the-Loop: For high-stakes financial data, use a “Pending Approval” dashboard where a human verifies the first 5% of a bulk upload before the rest are triggered.

THE “ZERO-TRUST” AUDIT IN YARDI

1. Executive Summary

As commercial real estate portfolios expand, enterprise system access often becomes decentralized, leading to severe compliance vulnerabilities. This case study examines a tier-one Australian Commercial Real Estate Investment Trust (REIT) that faced significant risks of failing its SOC 1 Type II audit due to “permission creep” within Yardi Voyager. Through a comprehensive Segregation of Duties (SoD) audit, the rationalization of more than 150 legacy Menu Sets into a strict Role-Based Access Control (RBAC) model, and the deployment of an offshore managed support team for automated provisioning, IT General Control (ITGC) risks were successfully mitigated. Support overhead was reduced while institutional-grade compliance was ensured.

2. Introduction

In the highly regulated Australian commercial property sector, Yardi Voyager acts as the central financial nervous system. During a pre-audit health check, a rapidly expanding commercial REIT discovered that its Yardi environment had evolved into a “security spiderweb”. Years of ad-hoc access requests, employee turnover, and regional workarounds resulted in junior staff holding unauthorized permissions to sensitive financial modules. A critical failure in Segregation of Duties (SoD) was identified as the core issue. Users possessed the ability to both create vendors and approve payments, creating a significant vector for financial fraud and posing a serious threat to the organization’s compliance standing.

3. Background Information

Institutional investors require strict adherence to IT General Controls (ITGC) to ensure the integrity of financial reporting. Historically, the client allowed regional offices to manage their own user provisioning inside Yardi Voyager. This decentralized approach led to a bloated system containing more than 150 poorly defined Menu Sets for a workforce of only 300 employees. Key stakeholders included the Chief Financial Officer (CFO), who was responsible for the upcoming SOC 1 Type II audit, and the internal operations team, who struggled daily with cluttered menus and irrelevant modules.

4. Case Analysis (SWOT)

To systematically isolate the security vulnerabilities, a SWOT analysis of the existing user access landscape was conducted:

1. Strengths:A highly granular, robust native security architecture is possessed by Yardi Voyager, which is capable of strictly enforcing compliance if configured correctly.
2. Weaknesses:A complete lack of a centralized Segregation of Duties (SoD) matrix was identified. Additionally, “Super User” access was frequently granted as a quick fix to resolve L1 support tickets.
3. Opportunities:
   A dual benefit was offered by the redesigning and condensing of Menu Sets: audit requirements could be satisfied while the daily User Experience (UX) was drastically improved by hiding irrelevant modules.
4. Threats:Risks included the immediate threat of failing the SOC 1 Type II audit, potential financial fraud due to SoD violations, and the exposure of Personally Identifiable Information (PII) belonging to commercial tenants.

5. Proposed Solutions & Alternatives

To address the compliance gaps, two primary remediation paths were presented to the executive team:

Recommendation: Option B was selected to ensure remediation was completed before the arrival of external auditors and to fix the root cause through a centralized support model.

6. Implementation & Recommendations

A strict, three-phase remediation plan aligned with Australian business hours was executed by the offshore technical team:

1. Phase 1: Discovery & SoD Matrix Development (Weeks 1–2):
   All current user access logs were extracted directly from Yardi’s backend tables. Every job function (e.g., AP Clerk, Property Manager) was mapped against a newly developed SoD Matrix. Forty-two instances where users held conflicting financial privileges—such as the ability to edit bank details and process payments—were immediately identified and revoked.
2. Phase 2: Menu Set Rationalization (Weeks 3-4):
   The 150+ convoluted, legacy Menu Sets were archived. In their place, 12 standardized, strictly “Role-Based” menus were engineered. Users were restricted to the exact screens and reports necessary for their specific job descriptions, which drastically reduced UI clutter.
3. Phase 3: Automated Provisioning & BAU Handover (Weeks 5-6):
   A strict, ticket-based workflow was established for all future access requests. “New Hire” tickets are now submitted by the local Australian HR team to the offshore team, who provisions the exact role-based template to ensure “permission creep” cannot reoccur.

7. Conclusion & Lessons Learned

System security within Yardi is not considered a “set and forget” deployment. By shifting from a decentralized, reactive permission model to a highly governed, centralized RBAC architecture managed by an expert offshore team, the SOC 1 Type II audit was successfully passed with zero critical ITGC findings. Furthermore, internal L1 support tickets dropped by 60% as the operational friction of navigating Yardi was significantly reduced. The ultimate lesson learned is that clear, role-based system boundaries not only protect the organization from risk but also empower end-users to work faster and with greater confidence.