Contacts as Drupal users
Whats the thinking behind making every contact in the database an actual Drupal user who could potentially log in to your CRM installation?
THe current roadmap suggests profile2 is a blocker as its needed for storing CRM contacts. I can't see anything documenting the reason to have all my CRM contacts as Drupal users with a profile.
Whats wrong with storing the contacts as their own entity, and using email address as a unique ID for linking activities to them (such as logging emails against a specific contact) ?
Based on use of other hosted CRM systems i've never had all my imported contacts turned in to user accounts for them to log in to *my* CRM.
- Login to post comments
Comments
AFAIK, that is NOT the
AFAIK, that is NOT the thinking. The whole point of having an independent CRM entity is that it allows us to track a person who is not a user.
profile2 does NOT have to assume that profiles are attached to users. A profile can be attached to any entity, in theroy. (This is an area where some work still needs to be done, but the module is engineered to support it, AFAICT.)
Having everyone as a user was a problem for ubercart that we, and DrupalCommerce, are trying to avoid.
Contacts, Customers, users, profiles, etc, are all potentially separate entities. The job of the Contact/CRM entity is simply to ties all of these things together, so we can do things like ask "What is this person's mailing address" without having to know if that person is a user or not, and whether that address field was populated by an E-commerce transaction, or a a data import, or whatever.
Also, it's worth noting that
Also, it's worth noting that given fine-grained access control, if someone does choose to configure their CRM to give every contact a user account, that doesn't imply that the user has permission to access the CRM.
I just wanted to clarify, since your last paragraph seemed to assume that having a user account somehow meant the user had access to the CRM. This is Drupal, not Salesforce.
What were the issues with
What were the issues with having everyone as a user in UC/Drupal Commerce?
I'm trying to see why every person shouldn't be a user.
In my opinion they should, for the simple reason that access to the crm can then be granted without any additional work or duplication of data.
It might be worth seeing what data you want to track per role e.g. Contacts, Customers, users, profiles to see if there is any duplication.
Currently I'm just trying to get my head round this whole problem.
Isn't it possible to have
Isn't it possible to have users with profiles without the authenticated user role? That way they would be equal to anonymous users.
No, all logged-in users have
No, all logged-in users have the authenticated role.
In any case, the issue is not so much about roles or access control as it is about data architecture.
A user, by definition, is a person who logs into the system. So storing data about people who do not use the system in a user object is violating the intended purpose of the object.
It can be debated whether it's truly 'wrong' to do this, but IMO, it's a better design to have one object that represents 'what we know about a person' and another, separate object, that represents access credentials, and have a relationship defined between those two objects.
This allows, for example, a CRM object that represents a Company, and multiple people who have their own credentials for logging in, and manipulating data for that company. Or conversely, you might have one set of access credentials, for a parent, who manages CRM data for several children, who are separate 'contacts' related to a single user.
I agree with Matt. A person
I agree with Matt.
A person should be an independent record in the dbase.
Joachim described differently on IRC though.
Which brings me to my next question - whats the point in writing a whole module (Profile2) in order to record custom fields of data about a person. Smells like a CCK node to me - why complicate things by creating additional dependancies?
Same reason
We're avoiding nodes for the same reason, mainly, although the case is much weaker.
It could be argued that a 'node' by definition is a piece of web content. So when web content needs to contain information about a person, it should be a reference to profile. Imagine a directory where you have a 'family' node type with references to profiles for each of the family members.
Also, it can be argued that we don't want profiles as nodes for performance reasons. A site might reasonable have a contact database of a million people that adds hundreds of people per day, but only a few pages, with new content rarely added. We don't want to slow down the whole website due to profile records.
Better to allow an optional node wrapper around profile data (content_profile-7.x), if the node APIs are truly needed for a particular site.
If joachim is truly suggesting that all contacts should be users, then we don't see eye-to-eye on that, and I hope he'll join this discussion so we can sort it out. Maybe there are good reasons I haven't thought of.
Contacts as User
I agree with @matt2000. He is definitely on the right track. I like the idea of of using a wrapper around credentials.
I think a solution of using records, nodes and users together is the way to go as there are several different levels of contacts that need to be addressed.
We currently use MS-CRM and have a database of 500,000+ contacts and add 1000+ leads each month. However, only a handful of those contacts are active customers and only a handful of leads get converted to contacts. Leads would definitely be better suited for DB records as the volume can be significant. However, I think at some point the amount of data and complexity of the relationships would be better suited for nodes or users.
From a sales standpoint here is a summary of contact types.
Leads- prospect completed a simple call to action, but is not yet in the buying cycle. Basic Info: Name, email, address, phone.
Opportunity- Lead that has indicated some buying interest. responded to phone call or email and provide some additional information: Purchasing Time-line, Product needs, budget.
Contacts- Opportunity that is working toward a buying decision. more complete information, quotes or proposal have been sent.
Customers- Contact that has completed a purchase. order history, future needs.
Account- Group of related customers.
Contact Owner- User (Salesperson, Account Manager) with permissions to view and make changes to contact record, Campaigns, Tasks, and Emails.
Business Unit- Group of Users with permissions to view and make changes to Contacts meeting certain demographic criteria or assignment to a user or account.
Well, if the issue wasn't
Well, if the issue wasn't confusing enough already, we now have fieldable users in core:
http://drupal.org/node/873118
What about a contact construction kit?
I'm new here, but just started reading about the Drupal CRM from Copenhagen, and very excited to see interest in a CRM project, As a prior user of CiviCRM that dropped it and opted to try to just use the tools available in Drupal, I'm excited to see this project taking shape. I'm a designer, a very novice developer, just so you know where I'm coming from on here. Just a few thoughts on the subject:
Profiles do allow custom fields in D7, but you can still only have one profile type. This is not an ideal solution to me because this would mean you have one form, and sometimes different types of contact will have different fields. One workaround may be to come up with a field that tells the contact type, then exposes only form elements for that user type. Of course, this may also mean that a larger block of contacts are queried than necessary, and it does appear each would have to have a user name.
With a node & node wrapper, you could create all types of content types with different fields, and you wouldn't have a bunch of null fields, although I think there would need to be a way to change the type of contact profile, and if some fields are dropped (or if they were not consistent) then you'd potentially lose some data - workaround could be an option to choose field assignment (and an option to drop field) upon change to another type.
Node profiles could also allow you to create an option of whether or not a contact is a user via user reference, etc. I'm not familiar with profile 2, but it still sounds like it's dependent on the user (I'm currently using content profile for management of user profiles.)
Regarding whether to use a straight database or nodes for long contact lists, I'd still lean towards reliance on the node object for each contact. The node is a incredibly flexible object. It seems you could create a cached simplified array to query against then creating an array without the node object if performance is a concern, with the list referring to the NID - that would still allow the ability to use other modules with contacts that rely on nodes for display, etc.
Whatever is used, I think there would be a tremendous benefit to having a "contact construction kit" - a form that simplified the creation of profiles, as well as views for them, with standard field names and options for commonly used profile fields. People could create a new contact type simply by checking the fields they need, have a field to establish one and two-way relationships to specific fields in other contact types, and whether to create a referenced user & what role they should have.
EDIT: I just saw the post about moving to groups.drupal.org, and it sounds like there are quite a few modules in development to resolve concerns about using profile.