Here's a quick place to gather together everything we've been working on.
The typepad at http://lullapad.com/glZYuoOlfS has a number of ideas, questions, and problems.
The dabbleboard has a diagram of the loosely adopted data structure for contacts: http://www.dabbleboard.com/draw?b=Guest787879&i=0&c=a5599c284d4863ceb9d6...
joachim's sandbox for the party module, which aims to provide the base 'contact' type: http://drupal.org/sandbox/joachim/1260650
rlmumford's sandbox for the 'Cloud CRM': http://drupal.org/sandbox/rlmumford/1260546
Please add further resources below, but discussion of these resources or the information they contain is best done separately.
Random Assortment of Issues discussed:
- What in Drupal Speak should be the basic unit of the CRM. We seem to be set on "Parties". These parties would contain things such as Users or Contacts or other kinds of entities that could contain other things. This means that the party could contain a database that is in an external website such as salesforce. The Party itself definitely needs to be some form of entity so that other areas of drupal could use it. However, exactly how much information this entity should contain is still up for discussion.
-
- We could make it so that a party is an entity itself that "contains" a bunch of other entities (such as Organisation Entitiy, Contact Entity, User, etc)
-
- We could make it so that each party contains a complete way of doing CRM. (Such as Salesforce, Project2 based CRM, Allie's CRM, Kyle's CRM). This means that each party would not represent on real user, but would just be an entity that would relate to each other. UI's would be tasked with bringing these things together.
-
- We could do the above as a kind of "Smart Group". We make a Party that is a smart group of all the entitiyes mentioned above. For example if we had a Person "Alice". All the seperate entities "Alice's User", "Alice's Contact info" "Alice's Saleforce information". would be related by the relation "Is the same". We would make some way of doing smart groups that meant we could do this quickly and well. (There is reason to do this method of "smart groups" for all groups. So instead of having a group "Company" we have an entity called "company" in the CRM. All it's employee entities are then related to that company entity with the relation "Is an employee". Instead of groups we just call everything that is related)
-
- Favoured We could make each "Party" a relation itself (as in a relation entity according to the relation api). Every other entity will just be related to that.
-
- Further Discussion is here: http://groups.drupal.org/node/171454
-
Allie is worried that with all the competiting forms of CRM floating around that there will be issues with data being incompatible. She wants someway that we can define "CRM primitives" that mean a field in Drupal knows what kind of field it is so that it could interact with other software. For example a text field with a name would have something that tells it, and the migrate module that it is a "name field". Further Discussion is in this wiki page. http://groups.drupal.org/node/171459
-
How do we sort out the Name field? There is an issue that names are currently full text with no way of knowing if its a surname or first name. However this gets more complicated as names can be different (multiple middle names) and from different cultures (Chinese and Korean names deal with generation differently, some middle eastern names include a complete least of geneology). This is an issue for CRM as people tend to input "Full names" but want to sort by things like "Surname" so we need a system so that Drupal knows what is the surname and all the possible metadata. We decided to research how other people have solved this problem.
-- rivimey here: I think if we can do some sort of computed field; names can be read as fullname or firstname/surname etc, but the underlying storage breaks it up. Don't forget that sometimes you get "generational qualifiers", nicknames, titles (Revd, Sir, Esq., and so on).