Fashti / Integrations
Connect what you already run
Fashti is an intelligence layer, not a replacement. Onboarding connects to the systems your team already uses, so there is no migration to plan and nothing to rip out.
01 The model
Your systems stay the systems of record
Fashti holds no authoritative copy of your portfolio. It assembles a working view, acts on it, and writes the result back where it belongs.
Read for context, act in the channel, write the outcome back
This matters more than it sounds. A platform that insists on owning your data makes itself expensive to leave and difficult to trust, and it forces a migration before you have seen a single result. Fashti takes the opposite position on purpose.
Your CRM remains where leads live. Your property management system remains where tenancies and the ledger live. Your document storage remains where signed agreements live. Fashti reads what it needs, applies your rules, handles the conversation, and writes back the lead note, the booked viewing, the work order, the document or the payment reference.
The practical consequence is that your team keeps working exactly where they work now. Nobody is asked to check a second system to find out what happened.
If Fashti were switched off tomorrow, every record it created should still be in your systems, readable by your team, with no export required. That is the standard an operational layer should be held to, and it is the one we build against.
02 Systems
The categories Fashti connects to
We connect to the software a property team actually runs rather than publishing a wall of logos. Your specific tools are confirmed at the assessment stage, before anything is agreed.
Portal and listing feeds vary a great deal by market and by the arrangement you hold with each portal. We work with the feeds and forwarding your existing listings already produce rather than claiming direct partnerships we do not have.
03 How a connection works
Scoped, reversible and visible
Every connection follows the same five steps, whatever the system is.
-
01
Authorise
Access is granted by someone on your side, through the system's own authorisation flow where one exists. We ask for the narrowest permission that does the job, and we document exactly what each connector can see and change before you approve it.
-
02
Read only first
Every connector begins without write access. Fashti builds the portfolio model, reconciles it against what you expect to see, and surfaces anything that does not line up. Write access is granted per system, later, once the read side is demonstrably correct.
-
03
Map the fields
Your custom fields, lead stages, repair categories and unit naming conventions are mapped explicitly rather than guessed at. Where two systems disagree about the same unit, the conflict is shown to a person instead of being resolved silently in favour of whichever replied first.
-
04
Write back
Writes are limited to the record types agreed during mapping. Each one is attributed to Fashti in the target system, so your team can always tell what was automated and what a colleague did by hand, and every write is logged with its trigger.
-
05
Monitor
Connections fail in the real world: credentials expire, interfaces change, a provider has an outage. When a connector cannot reach a system, the affected workflows pause rather than operating on stale data, and your team is told which ones and why.
04 When there is no interface
Not everything connects, and we say so early
Plenty of property software has no usable interface for third parties. Pretending otherwise produces a project that fails three months in, so we deal with it at the assessment stage.
The assessment lists each of your systems and states plainly whether it can be connected, partially connected, or not connected at all. You get that list before any agreement, not after.
A system that can be read but not written to still removes most of the work. Fashti uses it for context and routes the write to a person as a clearly described task, which is slower than a direct connection but considerably faster than today.
Where a system offers only periodic file exchange rather than a live interface, we use it, and we are explicit about the lag that introduces. A figure that is four hours old is labelled as four hours old.
If the systems in play make the outcome you want unachievable, the honest answer is to say so rather than sell an engagement that will disappoint. We would rather lose the work than deliver a connection that quietly degrades.
05 Leaving
What happens if you stop
Worth knowing before you start, which is why it is on the integrations page rather than buried in an agreement.
What stays with you
- Every lead, note, viewing and work order written to your systems
- Every document filed to your storage, including signed agreements
- Full conversation histories, exported in a structured format
- The complete audit trail for the period Fashti was running
How it ends
- Workflows are switched off individually or all at once
- You revoke the connector authorisations from your own systems
- Open items are listed and handed to your team, not abandoned
- Data held by Fashti is deleted on the schedule in your agreement
06 Questions
About integrations
How long does connecting take?
Typically three to five working days for a standard stack, assuming someone on your side can authorise access when we ask. Field mapping usually takes longer than the connection itself, particularly where a CRM has been customised over several years, which is normal and worth doing properly.
Will it create duplicate records?
Matching rules are agreed during mapping and tested against your real data before any write access is granted. Where Fashti cannot confidently match an inbound contact to an existing record, it flags a possible duplicate for a person rather than creating a second one or merging on a guess.
Does our team need to work inside Fashti?
Only for the exception queue and the reporting views, and only for the people who want them. The rest of the team carries on in the CRM and the property management system as they do today, and sees Fashti's work there because that is where it is written.
What if we change CRM next year?
The connector is replaced and the field mapping is redone. Because Fashti holds a working view rather than an authoritative copy, changing an underlying system is a reconfiguration rather than a migration, and your workflows and rules carry over.
Can you connect to something built in house?
Often, if it exposes an interface we can authenticate against and read from. Internal systems are assessed individually and we give a direct answer about effort and feasibility rather than a maybe.
Start the conversation
Send us your stack
List the systems your team runs and we will tell you which connect cleanly, which connect partially, and which do not connect at all. That answer is free and it is specific.
We read every message and reply within one business day