What if our data looks wrong?

For: An ops lead or analyst comparing PropSocket data against what they see in their PMS.

You’ll accomplish: a calm, ordered way to figure out why something looks off — and most of the time, how to fix it yourself before opening a ticket.

“The data looks wrong” almost always turns out to be one of a few explainable things: the data is simply newer in your PMS than the last sync, a property was recently turned on or off, or a field that doesn’t fit the standard model landed somewhere you weren’t looking. Work the checklist below in order before assuming there’s a bug.

Remember what PropSocket is: a copy of your PMS data, refreshed on a schedule. It reflects your PMS as of the last successful sync — not live, to-the-second.

---

1. Diagnostic checklist (work top to bottom)

a. Is the source record correct in the PMS?

Open the same property, unit, resident, or lease directly in Entrata.

• If it’s wrong in Entrata too, the fix belongs in your PMS. PropSocket will pick up the correction on the next sync — fix it there, then re-sync.
• If it’s right in Entrata but wrong in PropSocket, keep going down the list.

b. When was the last successful sync?

Open the integration’s Overview tab and check the Last sync time (see Reading the sync status dashboard). If you changed something in Entrata after that time, PropSocket simply hasn’t picked it up yet. This is the most common cause of “missing” or “stale” data. One caveat: if the most recent run shows Failed, the “Last sync” time is when PropSocket last tried, not when it last succeeded — your real freshness is the most recent Completed run.

c. Was the property recently enabled or disabled?

PropSocket lets you choose which properties to sync (see Choose which properties to sync). On the integration’s Properties list, each property shows an Enabled or Disabled badge. If a property was disabled, its units, residents, and leases stop updating — and if it was re-enabled recently, its data may not be fully refreshed until the next sync completes. Check whether the property in question was toggled lately.

d. Could the record have been removed in the PMS?

When something is deleted in your PMS, PropSocket marks it as deleted rather than erasing it. It then drops out of your normal views. If a resident or lease “disappeared,” confirm whether it was removed in Entrata — that’s expected behavior, not a loss.

2. Understand the freshness window

Your data is only as current as your sync cadence allows. Recent changes won’t appear until the next sync runs and completes:

Plan	Sync cadence
Starter	Every 4 hours
Growth	Customizable, as often as every 15 minutes
Scale	Customizable, as often as every 5 minutes
Enterprise	Customizable

If a change is newer than your cadence window, it’s not wrong — it’s just not synced yet. Don’t have time to wait? Trigger a manual sync (next section).

3. Field-mapping limits (where Entrata fields can land)

PropSocket maps Entrata data into a standard, consistent shape (the Common Data Model) so the same fields look the same no matter which PMS they came from. Most fields map cleanly.

Some Entrata fields don’t have a standard equivalent — things specific to Entrata’s own setup. Rather than drop them, PropSocket keeps them in a custom_data area attached to the record. So if a field you expect isn’t where you’d expect it, it may have landed in custom_data rather than gone missing.

One important thing: custom_data is not shown in the dashboard — it’s only available through the API, where your engineers can read it on each record. So if you’re looking in the dashboard and a field isn’t there, you can’t confirm it landed in custom_data on your own. The fastest path is to ask support (or your own engineering team, if they query the API).

A complete list of which Entrata fields map to standard fields versus custom_data is a per-connector detail; if you need the exact mapping for a specific field, ask support.

4. Re-sync first — it fixes most of these

Before filing anything, open the integration and click Sync Now, then let the run reach Completed (see Run a manual sync). This pulls the latest from Entrata and resolves the most common cause by far: data that was simply newer than the last sync. Re-check the record afterward.

5. If it’s still wrong: file a data-quality ticket

If the source is correct in Entrata, the sync is recent and completed, the property is enabled, and a fresh re-sync didn’t fix it — then it’s worth a ticket.

What to include:

• Your organization name
• The integration name — shown at the top of the integration’s detail page (e.g. “Entrata — Production”). If you want to be precise, you can also copy the integration’s ID from its URL: it’s the long identifier in /integrations/<id>/.
• The data type and a record reference — e.g., “a lease,” and the property/unit it belongs to. The record’s PropSocket ID (and its Entrata ID if you have it) is ideal.
• What the value is in Entrata vs. what it shows in PropSocket
• The field name that’s off
• The Last sync time shown on the integration when you observed the issue
• A screenshot of both, if that’s clearer than describing it

What NOT to include — this matters:

• No raw API keys or passwords. We never need them to investigate a data question.
• No resident personal information beyond what’s strictly needed. Don’t paste full Social Security numbers, full payment details, or unredacted contact lists into a ticket. Reference the record by its ID and the one field in question — that’s enough for us to find it safely.

---

If this didn’t work

If you’ve worked the checklist and re-synced and the data is still wrong, send us the data-quality ticket above by emailing support@propsocket.io. The clearer the “expected vs. saw” and the record reference, the faster we can trace it from your PMS through the sync to the record you’re looking at — without needing any sensitive data.