The MoxiWorks Cloze integration synchronizes contacts and activity, according to MoxiWorks’ announcement datelined August 12, 2026. But the announcement and July release notes do not explain which edit wins when both systems change a contact or how existing opt-outs are reconciled. Brokerage teams should resolve those questions in a limited rollout before treating the connection as one reliable customer record for automated campaigns.

What data the integration exchanges

MoxiWorks describes bidirectional contact updates and RISE activity sharing with Cloze’s Intelligence Engine. Synced contacts become available for RISE campaigns, presentations and automations.

The July 2026 release notes give a more specific account: Cloze contacts, tags, birthdays and property preferences flow into RISE and remain updated from Cloze. RISE email unsubscribe and resubscribe changes return to Cloze.

Neither document supplies a complete field map or activity-event list. Ask for a table identifying each supported field, its direction, and whether existing history or only subsequent events transfer. “Activity” needs that definition before an agent relies on it to decide whether a colleague has already contacted a client.

For teams comparing brokerage technology platforms, the useful measure is how much reconciliation remains after connecting them. A contact appearing in both applications is only the first check.

Who has access, and who controls shared contacts?

MoxiWorks says agents, offices and brokerages using both platforms have access across its served markets, including the United States, Canada, Australia, New Zealand and United Kingdom. Agents control which contacts synchronize and when, according to the launch announcement.

That selection control leaves a separate question: which records can the connector access? Cloze’s shared-view documentation, updated October 17, 2023, describes the team view as a separate database containing copies of shared records. It distinguishes shared contact details from optional timeline sharing.

Cloze also documents administrator controls over viewing and editing shared contacts. Those permissions apply within Cloze; the documentation does not establish the permissions of a synchronized RISE copy.

Before including shared contacts, have the providers identify whether the connector uses an agent’s personal account, the team’s records, or both. Ask them to demonstrate the result for an agent-owned relationship and a brokerage-assigned lead. Check who can see, edit and enroll each record in a campaign after synchronization.

Also settle what happens when an agent leaves: which copies remain, who retains access, and who can disconnect the account. These are brokerage operating decisions to record alongside the technical setup. A successful transfer alone cannot settle contractual rights to the relationship or its history.

Which edit wins when records conflict?

The launch announcement and July notes do not state which edit wins when both systems change the same field. That gap matters even if updates normally travel without intervention.

Consider a hypothetical test: an agent corrects a buyer’s phone number in Cloze while an assistant enters a different number in RISE before synchronization completes. Ask the provider to show which value survives, whether either user sees a warning, and whether the overwritten value can be recovered. This is a proposed acceptance test, not a reported defect.

Repeat the exercise with a contact already present in both applications. Ask how records are matched, how duplicate matches are handled, and what happens after deletion or reconnection. Information flowing in both directions does not establish that every field follows the same update rule.

Until the team has verified that behavior, choose an editing policy for the pilot—for example, one agreed application for routine contact corrections. That limits ambiguity without assuming the software enforces the policy.

Unsubscribe updates have a documented direction

The July notes document RISE-to-Cloze subscription updates but leave the reverse path and initial opt-out reconciliation unexplained. They also identify a separate RISE restriction: Do Not Market excludes all marketing regardless of subscription status. Ask how that restriction maps to Cloze before treating a resubscribe as clearance to send.

Test communication preferences at connection as well as after later changes. Using controlled test addresses, check an existing Cloze opt-out before connection, a new RISE unsubscribe afterward, and a resubscribe while another restriction remains.

Observe both the recorded preference and actual campaign eligibility. Ask whether the restriction applies to one agent, the brokerage, a particular email address or a broader contact record, and how long an update takes to affect a queued message.

For teams adopting AI and automation in housing, campaign eligibility is the practical test. A displayed preference alone does not show that every relevant sending workflow respects it.

What to establish before enabling campaigns

The launch announcement and July notes leave subscription tiers, integration fees, required administrator approvals and support commitments unspecified. Obtain account-specific answers before assuming existing licenses cover the connection.

Request written confirmation of the permissions granted to the connector, any contact-volume limits, expected synchronization delay, failure notifications and recovery process. Establish which vendor will handle a record that arrives incorrectly, so agents do not have to diagnose which application caused the discrepancy.

Keep the first audience small and use controlled addresses for sending tests. Expand automated campaigns after the brokerage can show that contact selection, edit handling and communication restrictions work together for its actual account configuration.