No announcement yet.

Findings from CRM package reviews

  • Filter
  • Time
  • Show
Clear All
new posts

  • Findings from CRM package reviews

    We conducted a extensive testing and review of the following products and list here a few items which we think can improve the outlook, functionality and maturity of the Espocrm product;

    Products tested
    Yeti - product appear to be a good fork from Vitger. Very cumbersome setup configuration. Dont like customization features.
    SuiteCRM - product is a fork from Sugarcrm. Hopeless documentation. Had to fumble through the software. Loses all the help when we backup and restore. UI for installing personnel very cryptic
    X2CRM - Fantastic product. Setback is support and development seems to have halted.
    Espocrm - Fantastic product, very user friendly. Documentation not comprehensive in many areas and especially the Advance Pack (very skimpy). After review we have the following initial suggestion:

    (1) Lookup Tables so the lookup can be reused and updated easily. The enum datatype is good but can be a real pain in the neck if the look is used in multiple places. Maintenance becomes a nightmare for User Tech Staff.
    (2) Relationship Link between entities should define the linking key field. In creating a link between two entities, the foreign field(s) should be defined in the relationship setup and not hack the code or json files.

  • #2
    1 - do you mean by lookup tables the list option list resources of the enum fields? if so I think we can do this in more simple way, like adding an option to the enum field to pick up another enum options
    also we can add an option to mark this enum as a resource option list, so the later enums can pick it
    2 - up to the relationship, in fact you already can set the relation name: if the relation name you set is packet for example, then the id in php will be packetId and database will be packet_id
    if you set it to mainPacket for ex then the relation key will be: mainPacketId in php and main_packet_id in the database
    This account 's been deprecated, u can find me here:
    wtsapp | 905366891649


    • #3

      Could you let us know which exactly topics of the documentations need adding more details?

      Thanks for your review


      • #4
        Hi Ayman and Yurikuzn

        Thank you for the response. I am preparing a review document on espocrm. I will forward you the shortfalls in espocrm for your consideration before we publish in IT Central Station which has a large number of following.


        • #5

          I am sorry it took me so long to provide our review summary. Please read below and we will be updating this on a regular basis:

          Epocrm Review Summary
          It as fantastic piece of software for a small to medium size corporate. Extremely fast and simple to use and customise. It is a definitely recommended software customer relationship management if you just want to use it out of the box. Some definite good thing about ESPOCRM are

          (1) Support is fantastic, fast and really friendly
          (2) Knowledge of developers are excellent
          (3) Overall structure of the system is well thought.
          (4) Database schema as easily understood
          (5) Major plus point is whatever is documented does work exactly as stated
          (6) Easy to install
          (7) Can be used in many ways other than CRM.

          The problem and frustration arises comes when it comes to customising for a higher level of complexity where it almost always ends up manipulating the code.

          Not withstanding various bugs and glitches, the following are serious shortfalls of the software:

          (1) Lookup tables
          (a) Though the enum field satisfies the simple needs for lookup, it fails when the same lookup is needed in numerous entities. The enum has to be defined each time and that can be really really annoying and totally error prone. What is needed in Espocrm is definition of lookup tables that can used in any area. This is a must in the next immediate releases.

          (2) User Manual and Guides
          The documented user guides are just average level. In many areas especially when it comes to examples of usages. English being what it is, can be confusing and present different views from that of the author. Much of the documentation assumes that a user can sort of "read whats it their mind". This is especially true with formula. Some good help in the form of "tricks". Gives us the feeling the guides are written without consideration of the type of audience. This can be overcome if there are detailed examples the elaborate the feature or function. The difficulty is compounded by the absence of sufficient video based tutorials. One best practise that we can direct the developers is to refer to Joomshaper's site or's Wiki which have things extensively documented.

          (3) Paths and folders for the various storage
          Currently most of the data are stored in the core apps directory (e.g upload). Its takes ages to backup the core folder due the upload folder. We accumulated around 20GB of graphics in there due to the inline images in the emails and mobile phone capture attachments. The are wasteful asset killers. In addition, when cleanup jobs take up hours when we delete these files using the Admin function "Attachments".

          (4) Cleanup options
          Currently when we want to change the expiry days for the cleanup to remove data, we have to go to the code level to do so. That is really cumbersome and presents Audit issues. Our Audit is very concern that such modifications cannot be validated or tested to ensure no malicious codes are injected. In addition, when we develop new entities, we should be able to add cleanup parameters for these entities. Currently, again, the code has to be manipulated. Very unhealthy practice.


          • #6
            i totaly agree :

            (2) Knowledge of developers are excellent
            (3) Overall structure of the system is well thought.

            i can add :
            - bug are resolved in the day and fix proposed by team.



            • #7

              Thanks for the review.

              > (1) Lookup tables

              Regarding enum fields. This can be solved this way:


              Opportunity's lead source and Lead's source fields have the same options but they are defined only on Lead side.

              > (3) Paths and folders for the various storage

              I don't understand what exactly you mean. To store attachments in different locations depending on their type? The reason is that some attachments should be in backup, others should not?

              > (4) Cleanup options
              > we have to go to the code level to do so.

              It's possible to specify cleanup expiration periods in data/config.php. All this params can be added to config, the name of params is the same as property names in the class.
              Last edited by yurikuzn; 10-17-2019, 09:04 AM.


              • #8
                Hi Yuri,

                Thank you for your update on my review. The following are my feedback:

                (1) Look Tables
                Hacking the code can achieve anything but that defeats the flexibility, extensibility and maintainability of the system. Hacking the code each time the enum is needed in a new area is serious security risk. I evaluated the X2CRM which has this feature built in very beautifully.

                (2) Paths and Folders
                In the current system, attachments are stored under the data->upload and data->upload->thumbs folders. These folders are located in the same main application folder. The location of these folders should be defined in the config.php and should be define-able by the type of attachments. Eg. we could define a folder for xlxs files and another folder for image files.

                (3) Cleanup Options
                This too should be define-able in the config.php for easy maintenance instead of hacking at the code.

                I hope these help. Espocrm is a wonderful software but the design appears to be greatly in need for flexibility, security and functional re-usability. This is evident by the dependability on code developer.
                Last edited by murugappan; 10-30-2019, 12:53 AM.


                • #9

                  (3) Cleanup Options
                  > This too should be define-able in the config.php for easy maintenance instead of hacking at the code.

                  There is no code hacking needed. All params can be defined in config php.
                  Last edited by yurikuzn; 10-30-2019, 06:34 AM.


                  • #10
                    Hi Yuri,

                    All i can find in the data->config.php is as per screencap below. Can you tell me where in the Config.php i can find these settings?

                    Attached Files


                    • #11

                      You need to append to the file

                      PHP Code:
                         'cleanupAttachmentsPeriod' => '5 days',
                      'cleanupDeletedRecordsPeriod' => '10 days'
                      Param names the same as names here