Table of contents
About the Project
The aim of this project is to create a set of CRM/ERP features for tiki, these will include a contact manager, relationship manager as well as various contact based activities such as Calls, Notes and Tasks.
The core CRM functions will be built on the contacts module and will leverage form existing tiki features, such as:
How we plan meet our goals
At the heart of a CRM, ERP and many other groupware solutions are people and companies, therefore we plan to start by building a contacts system, similar in concept to outlook and then build on this with additional CRM functionality.
Important Note: Although the activity functionality is key to a CRM it is not deemed part of the contact module/application/feature, but should be implemented as a separate tiki feature. I will probably use trackers for this, although it would be nice to create some kind of shared scheme/table. This would allow me to list all the entries in the table base on my contacts id [Source (e.g. contacts) | Source Record id| Destination (e.g. trackers) | Content Id (tracker 21)]
Good news finally we think we have a db structure to work with, any comments about the design would be appreciated as it is a bit of a compromise, in that we have broken third normal form (duplicate attributes) but for performance reasons. The design was intended to be flexible as possible in-order to allow ldap mappings, in that all entities (people, organizations) and their units (departments, holiday home) could be defined using attribute sets. However after some testing we came to the conclusion that the performance hit would be to great on large data sets, so we duplicated primary attributes in the entity table. It is also questionable whether or not we should have separate tables for attribute sets and relationships, the main difference being other entities can participate in relationships. Referee to db section for information on how to obtain the schema and software.
The project is really still in the design stage, so please feel free to contribute. We intend to get the core contacts working over the next fee weeks, and will start implementing additional CRM features once the contacts module is stable. At this stage is CRM functionality is not part of the tiki CVS, once the feature is functional it will be left to the core tiki developers as to whether they want to distribute CRM as part of tiki.
Everyone is welcome to help and make suggestions in whatever way they fell they can.
CRM Road Map
People and Team Members
Just me at the moment but eveyone is welcome!
Competition and Standards
Their are many groupware and standalone php based solution that offer some of the capabilities that will be present in tiki CRM, here is a short annotated list of some of the solutions I have played with.
LDAP Specific References
Please see LDAP
The addition of relationships make that database design more complex than originally anticipated, which in turn is going to makes csv, vcard and ldap import/export more complex.
How to exploit the functionality provided by the following tiki features from contacts?
Watches (uid | event | object | hash | title | type | url | email)
ActionLog (Create | Delete etc) ModifiedOn | PageName | User | IP | comment
ProgCont (pid | contentId | publishdate | data)
This section describes the current database design for the CRM engine. The schema was created using DBDesigner4 which is available form http://www.fabforce.net/products.php the XML data file is available Contacts.xml (96.56 Kb) and can be used to directly create and modify the database tables.
The following ERM show the high level relationships between the tables.
The following section describes each of the entities show in the erm.
The entity table is used to store the primary contact details for either a person (default when imported) or Organisation (e.g. company, school etc.).
We did toy with the following concept, but decided that the performance hit would be too high, by replacing the entity definition (currently first last middle name) with a single description/name field and move the (first last middle name etc) into the attributes table. This would allow the system to be extended with any number of new entities for example projects etc. Although this type of definition is very flexible it is at this point deemed to abstract to be comprehend easily, even by the system developers.
The unit table is used to holds an entities paper address and phone contact details as well as providing a link to one or more, email, and url entities. Each unit has a name that describes the unit (e.g. Home, Office, Beach House, Sales Dept, etc.) and should be viewed as a container-link for url, emal as well as to other entities (relationship and roles) which have defined attributes.
Note: in the future we may replace the unit definition with a single description/name field and move the fields into the attributes table. This would allow the system to be extended with any type of unit definition. Although this type of definition is very flexible it is at this point deemed to abstract to be comprehend easily, even by the system developers.
CRM Unit EMail
Provides a list of email address and associated parameters for each email address, such as usePlain Text, use public key etc. Email will display a dialogue to select the primary email address; it’s setting as well as a list of other email addresses for this contact entity.
Note: could use tiki_user_email table for this.
CRM Unit URL
Provides one or more url details, including any login id and password required to access the url. The url will display a dialogue to select the primary url (e.g. website), it’s account and password information, as well as a list of other website for this contact entity.
Note: This would be the ideal place to store net meeting and other real-time connection information. We could use directory Links (aka featured links) for this feature. Directory could be extended with comments, attachments and a picture to represent the category and or site. User_bookmarks is should be integrated with directory. Tiki_category_sites used by directory should be renamed directory_sites_category as it appears to be part of tiki categories. We could extend the directory with uid and password and use the directory instead. Although we may have an issue with updates as directory cats are assigned directory admin?
The synchronization table holds the information required to connect to external systems in-order to exchange packets of information between distributed entities.
This table will also be use to hold the configuration information for the following:-
The crm_unit_url table also serves a very similar role. IMO the best thing is to create a similar solution to tiki-send-obejcts but with the addition of an interval setting and perhaps a name and description field. We also want to be able to select multiple servers for communications for each crm_folder.
Note: tiki currently provides similar functionality in the following features, it appears that many of these could be merged into a single comms lib.
CRM Sync List
Provides a means to allow each folder to be synchronized with one or MORE systems.
CRM Attribute List
Attributes are simply a set of user-defined fields that can be associated with an entity as well as each of its units. Each attribute set can also be associated with one or more participants in-order to form links between entities; these relationships are described using attributes.
CRM Attribute Definition
The role definition table is based on the tracker table and is used to define a role and its attributes.
The role definition table is based on the tracker table and is used to define a role and its attributes. Definition allows you to add, remove and configure a relationships attribute set, for example.
CRM Attribute Fields
The role field’s table is based on the tracker field’s table and is used to define each of the attributes associated with a role.
Note: need to extend the current table to include
CRM Attribute Instance
The role instance table is based on tracker item table and is used to map the field values to a specific role.
Note: may add notes and attachments tables in future.
CRM Participates List
Provides a list of entities for this relation id.
The activities table is a link table that links items stored in other tiki tables, and is used to store all of the actives for this entity; the default view mode is chronological order. Activities can be assigned to other users and reminders sent to that user.
CRM Folders provides a convenient way to group entities and can be mapped to tiki user groups. Preferences and permissions can be applied on a folder-by-folder basis.
Note: When importing records we need an option for automatically creating accounts base on the above. Also refer to Tiki User Groups and Permissions.
CRM Category List
Tiki categories will be used to classify instance objects (e.g. a specific crm entity), we should allow the user to assign an entity to one or more categories. This table provides a lookup list of the tiki categories that this contact has been assigned to and is used to assign a single contact to one or more tiki categories. Categories can be used in association with folders, for example you may wish to define a folder for partners and add the contact information for each business partner, each partner can then be associated with one or more categories, for example life insurance, mortgages etc.
Note: we should be able to set permissions for categories for example who can view meeting, birthday, phone call, travel time, sick, on vacation, private, etc.
CRM Global Preferences
The global preferences table will hold configuration information that is global in nature, this table has yet to be refined.
Issues, Possibilities and Comments
Issues, Possibilities and Comment
The following table are not show, but may be included later
Tiki Theme Control
How do we add crm as a tiki section?
Determine telephone call location based on ip location, this presumes that all number are entered in the correct international format. We also need to add the following: Dialing prefix (e.g. Calling Card #)
Modules and Blocks
The following block/modules can be used to navigate contact entities and can be assigned in the same ways as tiki modules.
GUI and Views
Global /Navigation View
The global view is nothing more that a header with a number of command which are consistent across all views
The list view is used display, sort and find entities, there are currently four tabs one for each of the following lists [People | Organizations | Relationships | Activity]. The administrator should have the option of specifying which fields are included in the list view.
Each list will provide the functionality to select and manipulate multiple, entities can also be sorted using any of the fields defined. Some field values may have shortcut links, for example if the email field is shown you can click on the email address which will launch the email app as specified by the contact preference.
Each list page will have a footer which will display the current page, number of pages, page 1…n, first, last, next and previous as well as the number of records and the first and last record currently display on the screen. The record creation date and the record last modified by xxx on date. May add link to select all.
The properties view is used to navigate and edit an entity and its associated properties. This screen(s) is split into two regions (top and bottom) the top region is used to display the entities properties (details, events and relations) and the bottom region is used to display the entities activity in chronological order (notes, tasks, calls etc).
Figure 1 - Mockup Example Screen
Person’s properties are split over four tabs, primarily to allow space for the activity log to be shown.
Note: Where are we going to put the entity notes (a single notes field) and digital ids (public key). Notes are specific to this contact and are not linked to activity, the main reason they are included is so information is not lost when importing contacts. However this field may be useful if you want to add notes about this contact e.g. take station road train to Bakersfield and wait for Fred. Alternatively we could create a note item in the activity list for this contact and mark it as the primary/sticky note!!
The summary view provides a read only view of the person. The view is a combination of user-selected data from the other tabs, details, events, relationships and other.
Provides the details for this person
Events are simply a convenient way of adding and viewing calendar events for a specific contact and will use the existing tiki group calendar, and can be used to define activities such as:
Other Calendar Options
Used to view and define relationships for this contact, relationship can be defined as
Organization screen layout follows the same conventions as found in the person properties. Organization properties are used to define the various attributes that describe the organization, such as department’s etc. People may be linked/mapped to each department or roles but the details of that person are store in the person.
The events property view will follow the same conventions as those found under both people and organizational events.
The relation’s property view will follow the same conventions as those found under both people and organizational relations.
Please feel free to add you comments and suggestions here!
Some random thoughts and comments:
(2) Here is a start to a list of closed-souce competitors:
We still need to do some work on defining the boundaries between CRM and ERP as there is an ERP group. However I belive Tiki CRM will traget the first three, at least for now. I firmly belive tiki will mature into a solution which can compete with the bottom three over time (probably the next 12-18 mths), and hopefully we drag expand CRM functionality as tiki grows.
(4) I think integration with other CRM/ERP/groupware applications needs to be thought through, particularly for small businesses who use standard off-the-shelf packages (i.e. Quickbooks) to manage their businesses. Tiki CRM/ERP should be able to share information with the likes of Quickbooks, MS Money, etc.
I agree, and I know Ben Tallman has created a CRM module (more Sales Force Automation) and integrated it with Quickbooks. However I do not think his code is GPL.
Saying that I think Quickbooks intergration should be part of the ERP tiki group, and this project should focus on CRM features. I am in the process of updating this page to reflect this.
lets think ..... any ideas?
These are my thoughts:
1. Streamline Database Integration for these modules in this order:
Every time you enter a Bookmark or Add USER....
Bookmark (company URL)