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.
Attributes
Activities carry attributes, 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: A schema further down the hierarchy includes all of the attributes of the schemas above it. For example, an activity built on thecalls schema also has all of the interactions and activities attributes.
The activities schema
Theactivities schema is the root of the hierarchy. It supplies the attributes that every activity needs:
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
Theinteractions schema extends activities and models events where people communicate with each other. It adds:
Interaction records (and anything built on
interactions, including calls and emails) also feed Attio’s Communications Intelligence features.
The calls schema
Thecalls schema extends interactions and models synchronous conversations. It adds:
The emails schema
Theemails schema extends interactions and models sent or received email messages. It adds:
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, includingcallerandoutcome. - A “Marketing emails” activity extends
emails: it uses thesenderattribute on top of the direction and participants every interaction has.
System activities
Attio defines some activities itself. These are called system activities and are marked withis_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:Working with activities over the REST API
Create activities, log activity records and link them to your data by domain,
email address or phone number.