When associating a user with the property, one of the roles you can use is designated contact. This article explains what this does and does not mean in terms of permissions and communications.
What "Designated Contact" actually is:
Intended use: "Contact person for a unit (e.g., family member managing a property remotely)" - stored as a UnitOccupancy row with type DESIGNATED_CONTACT, not as ownership.
👉 Platform defaults:
Relationship | Auto-grants org role? | Creates ownership? |
Owner / Owner-Occupant |
| Yes |
Renter |
| No |
Designated Contact | None | No |
Caretaker |
| No |
Guest | None | No |
So unlike renter or caretaker, adding someone as Designated Contact does not automatically give them a portal role. They only get capabilities if an admin assigns a role manually, or if the org configures a default role under General Settings → Roles and Permissions → Unit Relationship Defaults.
⚡️ Communication Routing
The unit communication settings split audiences by owner vs. occupant, not by occupancy subtype:
Bucket | Who receives it |
Financial (invoices, fines) | Owners only |
Notices / violations / certified mail | Owners only (certified → primary owner) |
Governance / voting | Owners only |
General HOA comms | Owners only |
Emergency | Owners + all current occupants |
Designated contacts are treated like any other occupant for emergency alerts - they are included alongside owners, not instead of them.
Email automations behave similarly:
property_owner→ ownership records onlyproperty_residents→ owners plus all current occupancies (any type, including designated contact)
Nothing in the system promotes a designated contact to primary contact. That flag is owner-only and drives certified mail / billing responsibility. A designated contact cannot be starred as primary contact on the unit.
⭐️ What they can and can't do
Can:
Be linked to the unit in People / property records
Appear in the property switcher (as an occupant-only user)
Receive emergency communications (along with owners)
Be included in
property_residentsautomations if those are configuredCoexist with an owner on the same unit (owner + designated contact is a valid pattern)
Cannot (by default):
Vote in elections (voting follows ownership / entity membership)
See My Portfolio or billing for the unit (owner-only surfaces)
Receive assessments, violation notices, or certified mail as the primary recipient
Get portal/resident capabilities unless a role is assigned separately
Replace or suppress owner communications
⭐️ isPrimaryResidence is not set for designated contacts (unlike renter, caretaker, etc.), which signals they're a remote/secondary contact, not someone living at the property.
👉 For third-party property managers specifically
There is already a separate Caretaker relationship type, described in seed data as "Caretaker or property manager." That one does auto-grant the caretaker org role (ACC submission, documents, financial view, autopay management, etc.).
Use case | Better fit |
Remote family member / extra contact, minimal portal access | Designated Contact |
Third-party manager who needs to act on behalf of the unit in the portal | Caretaker (or Designated Contact + manually assigned role) |
Recommended setup for leased units with a third-party manager
Keep the owner on the ownership record (legally responsible party).
Add the manager as either:
Designated Contact - if they mainly need to be reachable for emergencies and listed on the unit, without portal powers; or
Caretaker - if they need to submit ACC requests, view unit info, etc.
Optionally rename the display label under Unit Relationship Defaults without changing behavior.
If using Designated Contact but portal access is needed, assign an org role manually or set a default role for that relationship type in the same settings page.
The owner will continue to receive financial and legal communications regardless. The manager won't bypass them unless automations are explicitly configured to include property_residents (which adds recipients; it doesn't remove owners).
🛟 Need more help? Just ask!