The way I see it, there are two main ways in which someone would usually want to incorporate the CRM into their site:
- The user might not have a Drupal site and would like to begin one from scratch with the CRM built in.
- The user already has an established Drupal site and would like to build in CRM functionality.
On the face of it, it seems like the first option suits an installation profile, and the second option suits a feature. Whilst I have no doubt that the first option can also be accomplished using a feature, this is raising the entry barriers since a feature is harder to set up on a blank Drupal site than an installation profile.
The most important thing for the end user is ease. I would like, in as few clicks as possible, to be able to go from finding the CRM download page, to having a fully installed CRM ready to use.
I think we have two options here:
- Develop a feature or features for the CRM. This is the easy option in terms of development, but makes it harder for end users.
- Develop an installation profile as well as a feature or features. This will make it easier for a wider range of users, but will take more development.
Are there any options I have missed here? Perhaps there's another way of looking at it.
I think we need someone to step up and begin to take ownership of the deployment side of things. While the separate module development will continue independently, without a way to bring everything together, we just have a bunch of separate modules that require lengthy configuration and setup by hand.
Comments
Is it possible to have an
Is it possible to have an install profile that just installs the features? Then we could do both with relatively little extra overhead.
I think you can, but I'd have
I think you can, but I'd have to investigate further:
I think a major use case is
I think a major use case is being missed... a stand alone CRM which communicates with a website via services for example.
This has 2 major benefits: security and performance.
The CRM has a limited amount of data exposed to the website (should it become compromised) and it can sit on a separate physical server.
Performance wise it means that you can scale the CRM independently from the website... suffering of one does not critically affect the other.
I think this architecture would be essential for enterprise adoption of a Drupal CRM (at whatever point that may be - if ever). Lumping CRM data on a publicly exposed website is not favourable for many organizations though.
(My thinking is that a client module would be installed on the website to expose CRM functionality on the website in this case - this would also allow interoperability with other CMS's, rather than just Drupal).
Good point. How much of this
Good point.
How much of this could be achieved with a shared sign-on between the 'web' and the CRM Drupal installs?
Maybe quite a lot - but won't
Maybe quite a lot - but won't that hinge on whether contacts are users?
Also, some CRM users might not even need access to the website... probably not a huge issue to be worrying about.
In reality, this use case probably won't really affect CRM development... just means that we should be writing a good API and we can expose that via XML-RPC or any other number of appropriate Services module related interfaces. An offshoot project(module) could take front facing code from the CRM and provide it within a module to talk to the CRM backend.
Hope this is making sense :)
What if we had a party and nobody came?
The current plan is to have contacts as either users (plus a party each), where a user exists, or parties where they don't. So users become a hotswappable entity. There's a diagram I included on the architecture wiki page which looks like some alien's representation of the early moon landings, under the "Party" heading, which explains how parties will drop in.
I totally agree. We've been
I totally agree. We've been using Drupal as a stand-alone CRM since 2006. At the same time we have multiple websites (Drupal and WordPress) that generate leads and forward them to the CRM. I should admit thought - it's not a full blown enterprise level CRM, it's mostly a lead management system where leads saved as nodes and being distributed among team members (users). We utilize a few plugins out of the box like calendar to schedule follow ups and next action, comments to keep notes for each lead/contact, CCK to create detailed contact/lead profile etc. I hacked a couple of plugins to follow up with contacts directly from the CRM, as well as send them personalized drip campaigns. It's not the best solution, but it works for a small team of dozen sales people. There is no point of making it a part of a website because we have multiple websites and lead generation venues. It's much easier to funnel leads into the CRM and go from there.
It was a quick/dirty solution that I put together within first couple of months after we started. I made some improvements since then, but it's still the same big and dirty hack that runs on 5.x branch. I need to port it to version 6 + all custom code into features, I guess (I haven't been following latest Drupal inventions). What I'm really interested in is better email campaigns functionality, with tracking options for analytics, as well as being able to track specific contact activities on our sites that they visit. It's gonna be tricky since the contacts are not registered users and they don't have to login, but this information would be awesome for implicit profiling of the leads.