Enterprise Software optimize

Get to know Daylite CRM for Macs

Vincent Danen introduces the Mac CRM package, Daylite. While it is relatively expensive, it's a complete, reliable, and stable application that he thinks is well worth the cost.

Vincent Danen introduces the Mac CRM package, Daylite. While it is relatively expensive, it's a complete, reliable, and stable application that he thinks is well worth the cost.

---------------------------------------------------------------------------------------

For business, a good CRM (Contact Relationship Management) system is imperative. Choosing or finding a good CRM, however, can be a daunting task. There are a number of available options: local/single user use, multi-user via a Web application, or native multi-user via an application.

Each has its pros and cons. A local/single user CRM only allows information for a single user so shared information in an organization is out of the question. There are a number of applications like this, or applications that work together to provide a solution (such as iCal and AddressBook). Web-based solutions such as SugarCRM or Zimbra also exist; the advantage of these solutions is that they are cross-platform -- your data is available regardless of what platform you, or your colleagues, use.

The last type is where the Daylite program falls: a native OS X application used exclusively for OS X. In an environment where everyone is using a Mac, this is one of the best solutions. Daylite provides a comprehensive CRM environment for Mac users: multi-user, shared calendars, shared contacts, delegated tasks, notes, multi-user projects, and more. Daylite comes in two components: the Daylite application itself (that can work as a single-user CRM if you are so inclined and need something with more power than iCal or Address Book) and Daylite Server, which is the central point of data storage for multiple Daylite clients.

Daylite has a number of points against it, however. It is expensive; every connection to the database requires a license. If you have an organization where 20 people will be using Daylite at once, you need 20 licenses. For Daylite itself, one license costs $179CAD (approx. $167USD); for a Daylite Productivity Suite license (which includes a very useful plugin for use with Apple's Mail client), it will set you back $229CAD for a single user license. Another con is that it is not cross-platform -- Daylite only runs on a Mac.

The benefits that Daylite brings, however, may make it worth the cost, and if your organization is using Mac exclusively or primarily, then Daylite is very much worth looking into. For one, Daylite offers an online/offline mode that allows you to transition from using the online database to an offline database with a simple command. This allows you to take your Daylite database with you as long as your computer is with you. Any changes you make to Daylite when you don't have a connection to the server is committed to the local copy of the database and when you transition back online, all of your changes are synced to the server. So if you don't have Internet connectivity, you can still get access to your calendar, contacts, tasks, and so forth -- something you can't do with a Web-based service.

If carrying your laptop around isn't ideal, and you have an iPhone or iPod Touch, purchase the Daylite Touch application. This puts Daylite in your pocket; all of the information available in Daylite is available in Daylite Touch: tasks, calendar, contacts, opportunities, projects. You can add and edit everything in Daylite Touch and have it sync to the server, immediately reflecting changes in your desktop Daylite and that of your co-workers.

Daylite also offers real-time synchronization with Apple's Address Book and iCal. This allows for other applications to link with Daylite easily: if you have a given task management application, for instance, and it has the ability to sync with iCal, those changes will replicate to Daylite. Syncing iCal and Address Book with, for example, Google Apps, will replicate Daylite data to that service.

Unlike other local applications that use custom backends like SQLite, FileMaker, or other database types, Daylite uses PostgreSQL: a reliable, proven, and fast open source SQL database. It offers automated backups so you can ensure your data is backed up on a daily basis, or whatever your schedule demands. Restoring from backup is simple and reliable. (I know; I've had to do it once or twice.)

Daylite is industrial strength. It is reliable. The cost is higher than others, but having looked at other applications, none of them offer the expandability or reliability that Daylite does. I've been using Daylite for years on multiple systems, integrating it with different software, and have recently started to use Daylite Touch. The only time I have encountered reliability issues with Daylite is with the Snow Leopard upgrade and all of those issues have since been worked out. Daylite is rock-solid and well worth the price of entry.

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

3 comments
gmeader
gmeader

SQLite is also a reliable, proven, and extremely fast open-source SQL database. It is however not suitable for multi-user transaction processing with more than a few users. http://en.wikipedia.org/wiki/SQLite

vdanen
vdanen

I'm sure you didn't read the whole thing (thanks for the nit-picks though!). "Unlike other local applications that use custom backends like SQLite, FileMaker, or other database types, Daylite uses PostgreSQL" Reading that in context, considering Daylite is designed to handle more than one user, and can handle a *lot* of data, your assertion of SQLite not being suitable for multi-user transaction processing with more than a few users is entirely accurate and is exactly the reason why Daylite *doesn't* use SQLite. SQLite would absolutely fall over with Daylite, and while PostgreSQL might be overkill for a single-use situation (which is entirely feasible), it makes sense from a development perspective: why use SQLite and PostgreSQL depending on the circumstances, when one will work well enough for both (and importantly, not fall over when pushed to extreme usage)?