Distributed SuiteCRM implementations?

Hello All,

I am researching approaches to use that will allow for a set (2) of Suite CRM instances to be maintained in a substantially synchronous state, with one being a subset of the other. The subset system will contain the most updates, and will nee to be exported and imported into the master system. Is this a database function or an application function? My gut tells me application, given that transactional integrity is maintained there. Are there any tools that support this directly?



That whole “subset + imports and exports” concept sounds hard to implement with SuiteCRM. I don’t know of any simple way (if anyone knows, please tell us!).

I don’t know if my scenario is anything like yours, but for the typical situation with one company running several different (and not communicated) sub-companies, I put everything in one instance of SuiteCRM, and hide each sub-company from the others using SecuritySuite settings (the security permissions system that comes with SuiteCRM).

The top managers see everything, the local managers and employees see only their records.

Then I do have replication but that is for disaster-recovery purposes. It’s simple and fully automatic (just VM’s cloning themselves to different hosts), because it requires no application level transactional synchronizations.

I don’t know if any of this helps, I’m basically checking with you if you REALLY need to distribute the data; it’s better if you could avoid it altogether. Can you?

Unfortunately no, my requirements are not satisfied with the use of Security Groups (I wish they were!). Sounds like maybe an opportunity here :slight_smile:

And when re-synching with the master, would you require two-way, record by record synchronization?

Or would it be enough to just import the entire database to update the master?

If it’s the former, I’m pretty sure you would have to write the code to do it, and given the complexity of the database, I’m pretty sure you would give up and try a different architecture… unless you can limit the scope to just a few tables.

no, fortunately there is no requirement for a bi-directional sync, only one way. however, I don’t think a simple database export/import will work, as there is traffic in the master than we don’t want to lose, but rather add to. imagine a customer in the master environment, distinct from one in the subordinate, which is managed purely in the master environment. we want to fold in the customer (and all records) from the subordinate environment, while retaining the customer in the master. a naive full export sub/import master would either overwrite the master records or duplicate subordinate records, would it not?

If I’m not mistaken, none of this is possible out-of-the-box, and I don’t think there are any tools to help.

If you use SQL dumps the entire database overwrites the other database. Not good.

I would still try to do it from the database, export a few tables and then append them on the master. It’s probably wise to limit the scope as I said, because when you say “the customer (and all records)” that’s a lot of stuff. Probably you can narrow it down to 4 or 5 tables that you really use.

It appears that mysql will support skipping or overwriting of records that are duplicates, as outlined here:


Here is the link to the manual. You can specify whether to replace existing records.

–replace, -r

The --replace and --ignore options control handling of input rows that duplicate existing rows on unique key values. If you specify --replace, new rows replace existing rows that have the same unique key value. If you specify --ignore, input rows that duplicate an existing row on a unique key value are skipped. If you do not specify either option, an error occurs when a duplicate key value is found, and the rest of the text file is ignored.

The question then is does SuiteCRM use unique key values that are known to mysql. My guess is that it does not, as that would preclude easy portability, right? Even if it does, I always HATE mucking around with a complicated application database schema “under the covers”, as its almost always the case that SOMETHING is happening within the app that needs to be maintained in order for ref. integrity to be maintain. Kinda like cheating on one’s SO; never a good idea :slight_smile:


Sorry for replying to an old thread. I’ve actually had to look at this just recently and found your suggestion while doing a search. I’m curious how you achieved this result, did you have to create many custom fields or did you just repurpose / relabel existing fields. I presume you used something like a combination of Roles and Security Groups to achieve multiple companies under a single parent database.

Did you ever write it up?

Hi I don’t understand what you mean about fields. Perhaps you can explain which part of my suggestion you’re interested in so I follow your rationale.

If this is about mixing four different “sub-companies” within a single SuiteCRM installation, I did it simply based on Security Groups permissions. I wouldn’t do it like this if they were really separate companies, I just did it because it’s four schools owned by the same people. They don’t need to see each other’s data, but they’re also not complete strangers.

Hi pgr,

Thanks for the reply, I had it in my head you had somehow implemented multiple distinct companies on a single database/host.

I’ve a situation where I have multiple small independant organisations that have been merged under a parent. I was looking at ways to give the parent global access for reporting etc., etc., while keeping each entity isolated and independant.