I understand that in SuiteCRM 8.x you can create both email and newsletter campaigns which we will definitely use.
However in addition to using email and newsletters we also post marketing collateral to our target, leads and contacts. Is there a concept of a letter campaign within SuiteCRM where you can design letters and mail merge them with target lists which are printable ?
Or would you export target csv files and do a traditional mail merge with Microsoft Word to produce letters etc… ?
Have you seen the PDF templates module? You could have designed templates and print several of them at once from the Contacts list view “bulk actions”.
Thank you for pointing out the PDF Templates. module.
I was running SuiteCRM 8.4.1. Sadly none of the list view “bulk actions” did anything in this release.
Luckily SuiteCRM 8.4.2 has just been released which incorporates a fix for the non working list view “bulk actions”.
I have now upgraded to 8.4.2.
For a lead, contact and account, list view “bulk action” now brings up the “print as pdf” list.
Unfortunate there is no list view bulk action “print as pdf” for targets. Is this a bug or an omission and how can it be fixed ? We send printed material to our targets
What I would really like is a unified or simplified contact table structure. The contact record would then have a type flag i.e. target, lead, contact or others etc… Changing the contact type would be as simple as changing the contact record type flag in the record. There would be no need for separate target and lead modules as we have now.
At the moment target, lead and contacts records are stored in different tables. And when a target changes to a lead then to a contact, the data and relationships are copied in between different tables. And from your last post you say the functionality is different too… What a waste of time, effort and code.
The number one rule of any database design is “don’t duplicate data” as its very difficult to keep it synchronised. I have read other threads talking about data being left behind in target and lead tables when converted which are unresolved.
Is it worth starting a new thread to discuss this unified contact structure in the developer section ?
Looks like there is no alternative but to use the leads module at this point in time.
The basic idea is: you don’t have to (and shouldn’t) use the Targets/Leads/Contacts separation unless it makes sense in your case. You have 3 levels at your disposal, use 1, 2 or all 3, depending on the way you prefer to work in your company.
For some people it’s very useful to have all of them, so they can keep a clean Contacts list (their clients), work with Leads (potential clients going through qualification or sales pipelines), and spam huge mailing lists of Targets with marketing messages, with very low mutual commitment.
You can easily add a custom dropdown field to the Contacts module to have things the way you want. I actually did that exact kind of thing in a system I set up years ago. Then you can use filters in list views to keep in sight only the ones that you’re interested in a given situation or stage.
What I would really like is a unified or simplified contact table structure. The contact record would then have a type flag i.e. target, lead, contact or others etc… Changing the contact type would be as simple as changing the contact record type flag in the record. There would be no need for separate target and lead modules as we have now.
I don’t know if that’s such a good idea. The point of the different databases is that you may have tens of thousands of targets. You may have thousands of leads and hundreds of customers.
You also don’t need very many fields for a target beyond name, email address and maybe source. They are typically used for mass email campaigns to non-qualified leads (like a list purchased or scraped from the internet). Leads would be a more involved contact type where you would start to gather more information. You would need additional custom fields for LEADS. Still not as many as a contact.
A CONTACT is someone who you may have many custom fields with. As well, as relationships to accounts, opportunities, etc. etc. If a TARGET had to have the same level of detail for tens of thousands of records there is a speed implication here. CONTACTS are few in number as compared to TARGETS and require much more detailed info in terms of fields and relationships. I can totally see why the original developers separated these out. A typical user would spend a lot of time in contacts and accounts where you really want the speed. Leads and targets are typically used to send email campaigns so it doesn’t really matter if list view is slower.
Another thing to consider is if you’re trying to measure conversion rates. You want a DB of leads that were converted so you you can measure. If you just change them to a “contact” you’re going to lose visibility.
I’ve worked on SQL databases with millions of records on Unix platforms. The simplest way to fix database performance issues is to put plenty of memory in the machine and use SSD’s or NVME storage.
I agree a unified contacts table could have tens of thousands of records. Firstly the backend sql engine caches regular search queries in memory. And secondly you would put an index on the column which identifies the contact type flag i.e. target, lead or contact.
Did you know that exisitng targets, leads and contact tables have a deleted flag which means records are not deleted but are merely marked as deleted And there is an index on the deleted column to speed up searches. That seems to work fast enough. Therefore ten’s of thousands of unified contact records should not be a problem either.
And if you do have million of records and the local database base is not fast enough then redirect the connection to a local or cloud database cluster.
Don’t need many fields:
If you compare the target, leads and contact module detailed views they are very similar in structure Why have separate tables. You can have one table and you fill in the fields you need. The database would have fewer tables which may improve search times. Duplication of data is ridiculous in this day and age.
Target, Lead and Contact Relationships:
Any campaigns, call, meeting, task etc…. linked to either a target or lead I want to retain when its converted in to a contact. Again a unified contact scenario would work well as these items are already linked to the contact. Just change the contact type flag from target to lead or contact.
Target, Lead and Contact Conversion Analytics:
I am definitely all in favour of producing these analytics but you don’t need to store the data in separate tables to produce the analytics. In a unified contact scenario when someone changes a flag from target to lead add one to an analytics total table stored in the database. Why keep the old target data to produce analytics.
At the moment you can’t even convert a target into a lead in V8.4.2 unless you switch into classic mode therefore there is a lot of work to be done on V8.x.
Certainly with unlimited resources you can do anything no disagreement there. I think you’ll find a huge portion of the users are on shared hosting or similar with very limited resources both in terms of memory and processor capability. The scenario you describe could potentially impact speed for these users.
Re: version 8, I personally stick with version 7 for all production environments. The target conversion process works without issue.
PS -there’s a cron job that runs in the background at the end of the month that removes all the deleted records if you enable it.
Yes I can definitely see your point of view and I understand that users running on shared hosting platforms with limited hardware resources would have a performance issue if tables had a thousand records or more.
SuiteCRM has great potential but its disappointing to hear that the database structure and code is being designed to allow it to be run on low performance hardware platforms even though computer hardware is relatively cheap these days either on-premise or in the cloud.
My current goal is to evaluate SuiteCRM 8.x to see if it can provide enough basic CRM functionality for our initial needs and if it can I will invest a significant amount of resources to build some additional custom modules and custom databases .
After spending some time testing 8.x recently I have discovered that SuiteCRM 8.x does had limited functionality compared to 7.x which is also disappointing. It’s a shame the developers don’t focus on making 7.x and 8.x functionally the same before embarking on interface design changes and adding new features etc ….
Looks like I will have no option but to take @pgr’s recommendation to use leads and avoid targets on V8.x because of the extra functionality it provides.
This is not a performance issue at all, this is by design. A CRM with 3 levels is better than a CRM with 1, in generic terms. There’s actual theory written about this, sales pipelines, etc.
For you, it might be different. Use the modules that fit your work flow, don’t use the ones that don’t.
The concept of targets, leads and contacts in any CRM is crucial in my opinion. My posts don’t say anything to the contrary.
I was suggesting or debating a different way of structuring the database to reflect that concept. Open source projects in my experience welcome such debate. And the debate went on to discuss performance related issues.
I had hoped that SuiteCRM 7.x and 8.x were functionally the same but there are differences of omission.
I had hoped to use the newer SuiteCRM 8.x and targets and leads and contacts in my workflow.
However 8.4.2 cannot currently do the following whereas 7.x can which limits which modules I can easily use sadly:
You cannot enter three line street addresses in targets, leads and contacts unless you make custom modifications.
You cannot convert a target into a lead unless you switch to classic mode.
In the target module the Print as PDF feature in not available.
The first two are discussed in different posts in the forum.
I will continue my journey with SuiteCRM 8.x as I believe it could be one of the best open source projects out there. I will just have to live with its current limitations until I’m up to speed with code development and then I will make customisations to fit our workflow as necessary.
In the meantime I appreciate the communities help.
Hey @Andrew_C many of the problems you describe are unique to Version 8. Version 7 is the long term stable version and doesn’t have the issues you’ve described above. I just checked and you can enter multi-line addresses in Targes and Lead (it s is a single field though). You are correct about Print to PDF for Targets, that functionality does not exist in SuiteCRM 7 either. However, adding PDF functionality to any module is a pretty straight forward coding task. I’ve added PDF functionality to custom modules in the past many times. There are many posts in the forum on how to do this.
Hope that helps, based on your issues so far, you might wat to consider sticking with version 7. You can check the road map but it should be supported for another year or so and by that time many of the features of 7 might be incorporated in version 8.
I totally agree with @pstevens here, I never advise using v8 before testing each and every bit of functionality that you need is there. There’s still a long way to go to get to feature parity in v8.
I did my due diligence on version 8.0.3 when it was first released way back and my first impression was that it was abysmal so I put my project on hold and waited for over a year for progress.
More recently I have been doing my due diligence on version 8.3 onwards and in its current form (8.4.2) it is still not a production ready CRM in my opinion.
I read the new version release notes and I despair. The developers are adding new features and tinkering with look and feel while the feature set is way behind V7.x. Bug fixes also take a long time to be actioned and released. And the development documentation is out of date.
I know that V7.x works much better and I have spun up an instance on my development platform recently, however I’m not keen on investing significant time and resources on building some major custom modules on top of 7.x and then migrating them over to 8.x at some point in the distant future.
While writing this post I’m loosing confidence that V8.x will become production ready in a reasonable amount of time for my purposes. I don’t mind waiting a month or two but if its another year that becomes a non starter for me sadly and I will have to look at alternative platforms.
If you have any influence with the developers please ask them to get V8.x production ready ASAP. I don’t mind investing time to test and find bugs if the developers would allocate resources to fix them quickly.
Version 8.4 is as production ready as any v7, there is absolutely no document saying it’s not a production ready version.
When a major version number grows, the feature set also changes, people are presented with new options and methods, there’s a learning curve. That’s how it goes for all software.
@abuzarfaris well you can’t solely rely on the outdated readme file. Each v8 minor release was preceded by a BETA version, and the official release is a production version.
Thanks for posting the readme to the thread. I’m a seasoned software developer and the readme file is a trusted document detailing any issues or problems with the release and it confirms my suspicion that 8.x is not production ready. Shame on the developers if the file is not being kept up to date.
Am I correct in thinking that you have recently submitted a thread stating that an upgrade to 8.4.2 stopped you from logging into your SuiteCRM instance and that you had to take the drastic action of restoring from a backup ? Its worrying that a such a serious problem got through beta testing.
Seasoned SuiteCRM users constantly recommend using 7.x over 8.x which is not a vote of confidence for its functionality sadly.
No I don’t personally believe 8.4 is production ready. However I have decided to persist with 8.x and test it feature by feature myself… If I encounter any problems along the way I will attempt to fix them and post details and or solutions in the community.
I understand individual opinions regarding a given state of production, and also understand the importance of the accompanying readme file. But that is not the sole source of information, and in many cases it has some outdated information.
That’s why there are official docs, release notes, and so on.
Now, about the seasoned SuiteCRM users, I’ve already addressed that:
Some people have been around v7 for so long they’re not going for the new major. I also remember some people not wanting to update from Red Hat EL6 because EL7 had Systemd instead of InitV. Where are they now?
The major difference between v7 and v8 is the new SuiteCRM Core, parts of the SugarCRM 6.5-community legacy code now being at a legacy folder.
If I am to start dwelling on a CRM now (which is kind of my road) I’m not going for an old version, which is no longer in active development. I’m not going to learn options and methods that are already marked obsolete.
About the update to 8.4.2 you did see good. Well, drastic … it was expected. One backups up before updates in the event the update breaks normal operation or presents major issues that require the restore. But in this regard I could also say all previous updates (within v8) worked as should. So accounting for all patch-updates from 8.0.0 to 8.4.2 that’s 16 successful updates and 1 failed update, which rounds to a 6% error rate so far. So far, as more successful updates will bring this number down.
But I agree with you, there should be more testing, that issue shouldn’t have happened, so on.
In the end, most of the topics we’re addressing here are only a topic because of SalesAgility themselves, that still haven’t been able to envolve the community (despite the community interest). There’s power and knowledge on the community that is available for harness and will simply be wasted by inaction. This serves for community submitted code, fixes, communication (these questions about production ready/development should be clearer).
But if you look at my profile here, I have a bunch of issues that have been reported and haven’t been addressed. That’s what drives people away from the beta-testing. Lack of structure. Lack of communication. Lack of support.
9 out of 10 someone’s providing support via the forum, is a user giving support not someone that works for SalesAgility (including the “forum team” - not necessarily affiliated with SalesAgility).
huge mailing lists of Targets with marketing messages, with very low mutual commitment.
