It's easy to think that CRM systems are "just a database," since they hold parametric and text data and handle it more or less transactionally. While parametric CRM data is the core of many a report and dashboard, it's actually not the most important data about the evolving customer relationship. Because parametric data represents only the current state of play, to understand the history means following the sequence of changes in audit trails: quite difficult, and less than enlightening.
The juicier data about the customer relationship, both in marketing automation and traditional CRM systems, is in a sequence of records that are mostly text and are more like a journal than a transactional history. The simplest of these records is a free-form notes record, which is almost invariably entered manually. Notes records track the author, time of creation, time of update, access privileges, a subject line, and a free-form text field. Notes are typically attached to main CRM records (such as lead/contact, account, deal, order, contract, or case). While notes are easy to use, lack of parametric data makes these text records almost impossible to report on. Even so, it's way better for users to put running commentary in notes than in the main record's comments or description field because the notes will be smaller, less likely to be erased, and can be easily sorted by chronology, topic, or author to provide a low-grade thread view of long conversations.
The next level of text-based relationship tracking is the task, meeting, event, or activity record. While each CRM system implements the details differently, these activity records provide more parametric data and structure to a free-form text field. Like notes, these records can be attached to nearly any main CRM object, anything that might require action. Activity records are used to initiate and track pending action items and to record the results of meetings or events. Typically, activity records include fields such as type, priority, status, due date, participants, notification parameters, and pointers to the people or entities to which they relate. Activity records may support document attachments, but it is typically not a good idea to use attachments here, as they can be easily missed by users, effectively buried in the system's object tree. Activity records are typically extensible with a few custom fields and are accessible via the system API. They are rich enough to support simple workflows (e.g., task started, task handed off, task completed), and are sometimes used by applications to record activities or state changes. Consequently, activity records are frequently used for reports, dashboards, and triggers for alerts or workflows.
While activity records are a powerful (and typically underused) functionality, they have limitations. The main actors in activities must be system users, so recording customer initiated actions in an activity is counterintuitive. In a latter-day version of reverse polish notation, recording a customer action as an activity looks like this: "UserName noted CustomerName action." Further, activities are typically one actor and one or two participants, which means that recording group actions is clumsy. When a large group of participants each responds on their own schedule, recording each of these responses as an activity can become ridiculous.