Knowledge Base
Salesforce listing feeds to UAE property portals: one source of truth
Publishing to Property Finder and Bayut from Salesforce means the property is maintained once. The work is in what happens when the portal says no.
Salesforce listing feeds let a brokerage hold each property once, in one system, and push it outward to every portal on a schedule. Price changes, status changes and withdrawals propagate instead of being retyped. That is the promise, and it is achievable.
The part that decides whether it works is error handling. A feed that silently drops listings is worse than no feed, because the brokerage believes it is marketing properties it is not.
What “one source of truth” actually requires
The phrase is used loosely. In practice it means three commitments a brokerage has to make and keep:
- Listings are created in Salesforce first. Not in the portal and then copied back.
- Portal back offices become read-only in practice. Not technically, but by agreement — an edit made in the portal is overwritten on the next feed run, which is confusing unless everyone expects it.
- Someone owns feed health. Rejections need a person, not just a log.
The second commitment is where most implementations quietly fail. An agent fixes a typo directly in the portal, the feed reverts it that night, the agent concludes the system is broken and goes back to working in the portal. Within a month the CRM is stale.
How Salesforce listing feeds work
The Listing record
A Listing object holds everything a portal needs, plus the fields that govern whether it is allowed to go out:
- Property attributes — type, community, bedrooms, size, price, furnishing
- Marketing content — title, description, images in portal-acceptable form
- Agent — who appears on the listing, which is not always the record owner
- Permit reference and expiry — the compliance gate
- Publication status per portal — a listing may be live on one portal and withdrawn from another
That last field is the one teams forget. Publication is not a single on-off switch, because portal contracts and listing quotas differ. Model it per portal from the start; retrofitting it later means rewriting the feed logic.
Feed generation
The pattern is consistent across portals, even though the specifications differ:
- A scheduled job selects listings eligible for a given portal.
- Eligibility rules run: active status, valid permit, required fields present, images meeting the portal’s requirements.
- The feed is generated in the portal’s required structure.
- The portal ingests it and returns a result.
- Results are written back to Salesforce as per-listing outcomes.
Step two is the compliance gate. In Dubai a listing cannot legally be advertised without a valid permit number, so a missing or expired permit should stop the listing from entering the feed rather than being caught by the portal. That logic belongs in your system, where you control it. More on the compliance side in tracking listing permits and compliance in your CRM.
Rejections, and why they need a person
Every portal rejects listings. Common causes:
| Cause | Typical fix |
|---|---|
| Missing mandatory field | Make it required in Salesforce, not just in the feed |
| Image below the portal’s minimum quality | Validate at upload, before the listing goes live anywhere |
| Unmapped community or property type | Maintain the mapping table; it changes as portals add areas |
| Permit mismatch with listing details | Correct the listing or the permit — never just resubmit |
| Duplicate of an existing portal listing | Usually a leftover manual listing; withdraw it in the portal once |
Write rejections back to the Listing record and make them visible on a list view somebody checks daily. A rejected listing is an unmarketed property, and the cost compounds quietly for as long as it goes unnoticed.
Status changes and the under-offer problem
Withdrawing a listing is as important as publishing it. A property under offer that stays live generates enquiries your agents then have to disappoint, and buyers remember.
Decide the rule explicitly: does “under offer” withdraw the listing, mark it as under offer where the portal supports that, or leave it live until exchange? There is a commercial argument for each. There is no argument for it being accidental.
Frequency, and why more is not better
Feeds usually run on a schedule rather than instantly. Teams often ask for the highest frequency available, which creates two problems.
First, a half-edited listing gets published. An agent changing a price and then the description leaves a five-minute window where the listing is wrong; a frequent feed will catch exactly that window. Second, frequent republishing of unchanged listings is wasted processing on both sides.
A better pattern: a regular scheduled run, plus an explicit “publish now” action for urgent changes. That gives agents control without making every keystroke a publication event.
Where feeds interact with lead capture
The two directions meet at the listing reference. An inbound enquiry carries the portal’s reference for the listing; your feed is what created that listing. If references are not stored and matched, enquiries arrive unattached to any property and portal performance reporting becomes impossible.
Store the portal reference on the Listing record at publication, per portal. It is a small field that makes cost per lead and cost per deal reporting possible later.
A realistic sequence
Outbound feeds are usually built after inbound capture is stable, because they touch live marketing. A workable order:
- Listing object and data cleanup, with permit fields in place
- One portal, one direction, with rejection reporting from day one
- A period running in parallel with manual listing, comparing results
- Switch off manual listing for that portal — the step teams postpone
- Second portal, reusing the eligibility and rejection framework
Step four is not optional. Running feeds alongside manual listing indefinitely produces two sources of truth and all the confusion the project was meant to remove.
Frequently asked questions
Can Salesforce publish listings to Property Finder and Bayut?
Yes, through scheduled feeds generated from a Listing object. Each portal has its own specification, so the mapping layer is built per portal rather than once.
What happens when a portal rejects a listing?
The rejection should be written back to the Listing record and surfaced on a list view somebody reviews daily. A rejected listing is a property nobody is marketing, and silent failures are the main risk in feed projects.
How often should Salesforce listing feeds run?
A regular scheduled run plus an on-demand publish action works better than maximum frequency. Very frequent runs can publish half-edited listings and waste processing on unchanged records.
Can a listing be live on one portal and withdrawn from another?
Yes, provided publication status is modelled per portal rather than as a single switch. Portal contracts and listing quotas differ, so this comes up quickly in practice.
Should the permit check happen in Salesforce or at the portal?
In Salesforce. A missing or expired permit should stop the listing entering the feed, so the control sits in a system you own rather than relying on the portal to catch it.
What happens to listings edited directly in the portal?
They are overwritten on the next feed run. That is the intended behaviour of a single source of truth, but it needs to be explained to agents in advance or it reads as a bug.
Talk it through
If your listings live in three portal back offices, tell us how many you run and where they are maintained today. Get in touch — the first assessment is free.
Let us look at your listing operation
Tell us how many listings you run and how they are published today. We will come back with scope, timeline and an indicative cost — free, and with no obligation.