> ## Documentation Index
> Fetch the complete documentation index at: https://developer.affinity.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Schema changes to the Affinity Data Share

## October 15th, 2026

* Added the `subject` column to the `emails` table (`v1_0` schema). The column is NULL by default. To fill it, an Affinity admin opens the Snowflake or Databricks configuration under **Settings** → **Integrations** and selects **Include email subject lines**. The setting applies to every data share the organization has. Subjects appear on the next refresh after the change is saved, and every email in the organization gets a new `last_updated_at` so incremental pulls pick them up. Affinity encrypts email subject lines at the application level. Choosing to include them removes that layer for the share, though the data stays encrypted at rest and in transit. A subject is also NULL when a participant's privacy settings withhold it, even for an organization that opted in. See [Data Access](https://developer.affinity.co/pages/data-share/data_access.md) for details.

## September 22nd, 2026

* Values inside a `custom_fields` array are now in a defined order. A field that holds more than one value stores them as a JSON array, and that array now matches the order Affinity shows, oldest value first. Before this change the order was arbitrary and could change on each refresh, so the position of a value carried no meaning. The values themselves did not change. This applies to the `custom_fields` column on the `persons`, `companies`, and `list_entries` tables (`v1_0` schema). To find which fields hold more than one value, read `value_type` on `fields_metadata` - a type that ends in `-multi` holds an array.

## September 11th, 2026

* Added Affinity's smart activity fields as columns on the `persons`, `companies`, and `opportunities` tables (`v1_0` schema): `first_email_date`, `last_email_date`, `first_event_date`, `last_event_date`, `next_event_date`, `first_chat_message_date`, `last_chat_message_date`, and `last_contact_date`. These match the First Email, Last Email, First Event, Last Event, Next Event, First Chat Message, Last Chat Message, and Last Contact fields shown in Affinity, so there is no need to derive them from the `emails`, `meetings`, `calls`, and `chat_messages` tables. An event is a meeting or a logged call — the underlying field does not distinguish the two — and `next_event_date` is the only column that looks forward. `last_contact_date` is the most recent of `last_email_date`, `last_event_date`, and `last_chat_message_date`. An entity with no recorded activity has NULL in every column. These are current values, not a history of changes. Opportunity values are the combined activity of the people associated with the opportunity. Because these columns now live on the entity itself, new activity updates the entity's `last_updated_at`, so a person, company, or opportunity appears in an incremental pull when only its activity changed.

## September 1st, 2026

* Added the `persons_value_changes`, `companies_value_changes`, `opportunities_value_changes`, and `list_entries_value_changes` tables (`v1_0` schema). Each row is one tracked change to a field value: `field_id` identifies the field (join to `fields_metadata.id`), and `value` carries the new value for an add or update, or the removed value for a delete. Changes to global fields appear in the table for the entity they were made on. Changes to list-specific fields appear in `list_entries_value_changes`, scoped to the list entry, and reach their entity through `list_entries_persons`, `list_entries_companies`, and `list_entries_opportunities` — so the full history for one entity is the union of both. Only fields with change tracking enabled record changes.

## July 22nd, 2026

* Added the `is_restricted` column to the `opportunities` table (`v1_0` schema). This boolean indicates whether the opportunity is marked as restricted in Affinity.

## June 22nd, 2026

* Added the `is_current` column to the `companies_persons` table (`v1_0` schema). This boolean indicates whether the person–company association represents the person's current company.


## Related topics

- [Version Migration](https://developer.affinity.co/pages/changelog/version-migration.md)
- [Previous Changes](https://developer.affinity.co/pages/changelog/previous-changes.md)
- [Gemini](https://developer.affinity.co/pages/mcp/gemini.md)
- [Versioning](https://developer.affinity.co/pages/external-api-v2/versioning.md)
- [Copilot](https://developer.affinity.co/pages/mcp/copilot.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.