> ## Documentation Index > Fetch the complete documentation index at: https://docs.attio.com/llms.txt > Use this file to discover all available pages before exploring further. # Activities > Event-based data logged against your records While [objects](/docs/objects-and-lists) store facts about your customers, activities store things that *happen* involving them: a phone call, a site visit, a webinar attendance. Each of these events occurs at a specific point in time and involves one or more of your records. For example, an outbound renewal call with Acme on the 14th of August is a single event. In Attio, it would be stored as one activity record, linked to the Acme company record and to the person records of everyone on the call. ## Activities and activity records Activities follow the same mental model as objects: * An **activity** is a data type, just like an object. It defines what kind of event you are logging (e.g. "Phone calls" or "Site visits") and which attributes each event carries. In relational database terms, an activity is roughly a table. * An **activity record** is a single instance of an activity, just like a record is a single instance of an object (e.g. one specific phone call). In relational database terms, an activity record is roughly a row in a table. Attio provides one system activity, phone calls, and you can create your own custom activities. ### Attributes Activities carry [attributes](/rest-api/attribute-types/attribute-types), exactly like objects and lists do. Every activity starts with a set of attributes supplied by its schema (see below), and you can add your own custom attributes on top, e.g. a "Location" attribute on a "Site visits" activity. ## Schemas Every activity extends a **schema**. A schema is a common set of attributes that multiple different activities can use. Schemas ensure that similar kinds of events are structured in the same way: every interaction has a direction and participants, every call has an outcome, and so on. Schemas build on each other in a hierarchy: ```mermaid theme={"system"} flowchart TD activities["activities"] interactions["interactions"] calls["calls"] emails["emails"] activities --> interactions --> calls & emails ``` A schema further down the hierarchy includes all of the attributes of the schemas above it. For example, an activity built on the `calls` schema also has all of the `interactions` and `activities` attributes. ### The activities schema The `activities` schema is the root of the hierarchy. It supplies the attributes that every activity needs: | Attribute | Type | Description | | - | - | - | | `title` | Text | A short, human-readable summary of the event. | | `timestamp` | Timestamp (required) | When the event happened. | | `linked_records` | Record reference (multiselect, required) | The records this event is logged against, e.g. a company and a deal. | Since every activity extends `activities`, every activity record also shows up on the activity timeline of each record it's linked to via `linked_records`. ### The interactions schema The `interactions` schema extends `activities` and models events where people communicate with each other. It adds: | Attribute | Type | Description | | - | - | - | | `direction` | Select (required) | One of `Inbound`, `Outbound`, `Internal` or `Unknown`. | | `participants` | Record reference (multiselect, required) | The people and workspace members who took part in the interaction. | Interaction records (and anything built on `interactions`, including `calls` and `emails`) also feed Attio's [Communications Intelligence](https://attio.com/help/reference/attio-101/productivity/communications-intelligence) features. ### The calls schema The `calls` schema extends `interactions` and models synchronous conversations. It adds: | Attribute | Type | Description | | - | - | - | | `end_timestamp` | Timestamp | When the call ended. Together with `timestamp`, this gives the call's duration. | | `caller` | Record reference | The person or workspace member who initiated the call. | | `outcome` | Select | One of `Answered`, `Left voicemail`, `Busy`, `No answer`, `Wrong number` or `Declined`. | ### The emails schema The `emails` schema extends `interactions` and models sent or received email messages. It adds: | Attribute | Type | Description | | - | - | - | | `sender` | Record reference (required) | The person or workspace member who sent the email. | In addition to the attributes above, every activity has the system attributes `created_at` and `created_by`. They are set automatically and cannot be written to. Note that `created_at` (when the activity record was logged in Attio) is distinct from `timestamp` (when the event actually happened). ## Extending a schema When you create an activity, you choose exactly one schema for it to extend: `activities`, `interactions`, `calls` or `emails`. Choose the schema that most specifically describes your kind of event: * A "Site visits" activity extends `activities`: a visit happens at a point in time and involves records, but it isn't a conversation. * A "Support chats" activity extends `interactions`: it has a direction and participants, but no call-specific or email-specific fields. * A "Demo calls" activity extends `calls`: it uses the full set of call attributes, including `caller` and `outcome`. * A "Marketing emails" activity extends `emails`: it uses the `sender` attribute on top of the direction and participants every interaction has. The activity receives all attributes of the chosen schema, including those the schema inherits from its own parents. These inherited attributes appear on the activity like any other attribute, but they are managed by the schema: you cannot modify them or add select options to them. Custom attributes you create on the activity itself remain fully editable. The choice of schema is permanent. An activity cannot switch to a different schema after creation, so if you are unsure, prefer the more general schema and add custom attributes for the rest. ## System activities Attio defines some activities itself. These are called system activities and are marked with `is_system_activity: true` in the API. The first system activity is `phone_calls`, which extends the `calls` schema without adding any further attributes. You cannot modify system activities, but you can read and create their activity records over the API. If you're building an integration, create your own custom activity rather than writing to a system activity. Prefix its slug with your app's name, e.g. `{app_name}_site_visits`, to avoid conflicts with other apps and with future system activities. ## How activities differ from objects Activities intentionally stay close to the object model, so most of what you know about records applies to activity records too. The differences: | Objects | Activities | | - | - | | Attributes are freely defined per object. | A fixed schema supplies the base attributes; custom attributes are added on top. | | Records can be added to [lists](/docs/objects-and-lists) as entries. | Activity records cannot be added to lists. | | Records have a `web_url` pointing to their page in Attio. | Activity records have no `web_url`. | Create activities, log activity records and link them to your data by domain, email address or phone number. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.