> For the complete documentation index, see [llms.txt](https://docs.cogram.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cogram.com/organization-administration/continuous-data-export.md). # Continuous Data Export (S3 Push) Keep a copy of your organization's data in an Amazon S3 bucket you own, brought up to date every day, as an archive or as a live mirror. Continuous Data Export (S3 Push) copies your organization's data in Cogram to an Amazon S3 bucket that you own. Every day, and when you select **Run now**, Cogram writes what changed since the last run. You choose one of two export modes for your organization: | Export mode | What happens in the bucket | Use it when | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | **Archive** (mode 1, recommended) | Cogram writes new and changed records and never deletes a file. When a record is deleted, unfiled or refiled in Cogram, its files stay, and its state file says `delete: true`. | You keep your own records, and your own process decides what to delete and when. | | **Mirror** (mode 2) | The bucket is equal to your organization's data in Cogram. When a record is deleted or unfiled in Cogram, Cogram deletes its files and its state file. The files of a refiled record move to its new project. | You want the bucket to show only the current state of Cogram. | In both modes, every run does these things: * New records are written, with their files. * Changed records that are still active are written again. Each file keeps its key, so the new content overwrites the old. * The organization-wide files (`users.json`, the `directory/` files) and each project's `team.json`, `folders.json` and `schedule.json` are written again with the current data. * Archived projects stay in the bucket. Their `project.json` has `archived_at` set. * Every record has a state file that lists its files, its state and its retention (see [The state file of every record](#the-state-file-of-every-record)). What happens to removed and moved records depends on the mode. See [What the archive keeps](#what-the-archive-keeps) and [What the mirror removes](#what-the-mirror-removes). The bucket uses the same structure as a [data export](/organization-administration/data-exports.md), with keys made of IDs (see [How the bucket differs from a zip export](#how-the-bucket-differs-from-a-zip-export)). These exceptions apply: * Projects created as Cogram examples are not exported. * Rendered `report.docx` and `observation.docx` files are written only when you turn them on. * `meeting.docx` shows only the meeting insights that Cogram already generated. The export does not generate missing insights. * An insight the meeting does not have yet, such as key points or the attendance table, shows a placeholder, for example `[Key points are not available]`. * When Cogram generates it later, the next run writes the meeting's minutes again. * The shared meeting link shows `[Shared meeting link is not available]` when the meeting has no shared link yet. Continuous Data Export is in beta and is enabled per organization. If you would like to use it, write to . Use it when you need: * An up-to-date copy of your organization's data in storage you control, for your own records and compliance requirements. * A feed for your own archive, search or analytics tools, with a record of what was removed in Cogram (Archive), or a copy that always matches Cogram (Mirror). In Mirror mode the bucket is not a backup: a record removed in Cogram is removed from the bucket at the next run. If the bucket keeps versions, AWS keeps the earlier versions of overwritten and deleted files. Cogram works the same with or without versioning. ## Before you start * You must be an **owner** or an **admin** of your organization. * Choose the export mode first: the access key needs other permissions in each mode. * You need an S3 bucket used only by Cogram, and an access key that can access only that bucket. Your AWS administrator can follow [Set up an S3 bucket for Continuous Data Export](/organization-administration/continuous-data-export-aws-setup.md). The settings are in the **Continuous Data Export (S3 Push)** section of [Organization Settings → General](https://app.cogram.com/dashboard/settings/admin/overview#continuous-data-export). ## Set up the export 1. Open [Organization Settings → General → Continuous Data Export](https://app.cogram.com/dashboard/settings/admin/overview#continuous-data-export). 2. Fill in the fields: | Field | What to enter | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Export mode** | **Archive** (recommended) or **Mirror**. A new configuration starts with **Archive**. **Copy IAM policy** copies the policy the selected mode needs, with your bucket name and key prefix filled in. | | **Provider** | Amazon S3. | | **Region** | The AWS region of the bucket, for example `us-east-1`. A wrong region fails the connection test, usually with the bucket's real region in the message. | | **Bucket name** | The bucket name only, for example `acme-cogram-export`. Not an ARN or a URL. | | **Key prefix (optional)** | A folder inside the bucket, for example `cogram/`. Cogram manages everything under it. Leave it blank to use the bucket root. Use one prefix for each Cogram environment (see [Keep the bucket for Cogram only](#keep-the-bucket-for-cogram-only)). The prefix cannot start with a folder that Cogram writes: `projects`, `organization`, `workflows` or `_cogram`. | | **Access key ID** | The ID of the key your AWS administrator created, for example `AKIAIOSFODNN7EXAMPLE`. | | **Secret access key** | The secret of that key. Cogram stores it encrypted and never shows it again. To keep the stored secret when you change other fields, leave this field blank. A new **Access key ID** needs its own secret. | | **Include rendered reports and observations** | Also write a `report.docx` for each field report whose report type has a template, and an `observation.docx` for each observation. Off by default: rendering makes runs slower. When you change this setting, the next run is a resync. Turned on, it writes these files. Turned off, Mirror deletes them, and Archive lists them in each record's `delete_files`. | | **Export every day** | Turns the export on. | 3. Select **Test connection**. Cogram writes one small file, `_cogram/connection-test.json`, under your prefix, and lists it. Every test writes the same file again, with a note and the time of the test. * **Archive**: Cogram never deletes, so the test file stays in the bucket. **Connection works** means the key can write and list. You can delete the test file. * **Mirror**: Cogram also deletes the test file. **Connection works** means the key can write, list and delete. 4. Turn on **Export every day**, then select **Save**. When you save connection settings that passed the test, Cogram tests them once more as the saved settings, and the section shows the result under the form. The first run, the backfill, starts within 5 minutes. To start it at once, select **Run now**. ## What Cogram runs, and when | Run | When it runs | What it does | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Backfill** | The first run, and the first run after you change the bucket, prefix, provider or export mode. | Copies everything. | | **Daily** | Every day at 03:00 UTC, and when you select **Run now**. | Writes the records that are new or changed since the previous run, with their state files. Archive: marks removed and refiled records `delete: true`. Mirror: moves the records that moved, and deletes the files of removed records. | | **Resync** | When you select **Resync**, after you change **Include rendered reports and observations**, after a change of the Data retention setting, of the email retention ruleset or of email expiry, and after a Cogram release that changes the bucket layout. | Makes every file again and uploads the ones that differ. Mirror: also deletes the files that no record makes. | | **Verify** | When you select **Verify bucket**. | Lists the bucket and compares it with Cogram's record of it. See [Verify bucket](#verify-bucket). | Only one run is active at a time. The 03:00 UTC run does not start while an earlier run is still going. How long a run takes depends on how much changed. A backfill of a large organization can take hours. A daily run usually takes minutes. A daily run also reads again what changed in the hour before the previous run started, so no change made during a run is missed. A run stops after 50 minutes, or after 20,000 files or 5 GB. It continues on its own at once from where it stopped, after the Cogram work that is already queued. ### Run now and Resync **Run now** starts the next run at once instead of at 03:00 UTC. It is a backfill when no run has completed for the bucket yet, a resync when one is due (see the table above), and a daily run otherwise. **Resync** makes every file again from what Cogram holds now and uploads the ones that differ. Files that did not change are not uploaded again. Use it to bring the bucket fully up to date, for example after you change your meeting template (see [Known limitations](#known-limitations)). A resync of a large organization can take hours. Cogram asks you to confirm before it starts. **Run now**, **Resync** and **Verify bucket** are unavailable while a run is in progress, while the export is turned off, and while it is paused after failures. ### Verify bucket Cogram keeps a record of every file it put in the bucket, and a daily run compares Cogram's data with that record, not with the bucket. **Verify bucket** lists every file under your prefix and compares the list with the record: | Finding | What Verify does | | -------------------------------------------------- | ----------------------------------------------------- | | A file is missing from the bucket. | Uploads it again. | | A file has another size than the one Cogram wrote. | Uploads it again. | | A file that Cogram has no record of. | Counts it as **unknown** and leaves it in the bucket. | Verify never deletes a file and never adds a file to Cogram's record, in either mode. Cogram's own folder, `_cogram/`, is not compared. The run's row shows what Verify found, for example `Verify: 1,204 listed, 2 missing, 1 wrong size, 3 unknown`. Unknown files can be files that you or another tool put under the prefix, or files of an earlier version of a record that Cogram no longer has a record of. Cogram does not delete them. Delete them yourself if you do not need them. Verify does not change the schedule, and a failed Verify does not count toward the pause after failures. In Archive mode, Verify uploads again the missing files of records whose state file is still in the bucket. A record whose state file is gone, and whose state file said `delete: true` or an `expires_at` that has passed, was cleaned up by you: Verify counts it as **cleaned up** and does not upload it again. If the retention of a cleaned-up record gets longer while the record still exists in Cogram, Cogram uploads the whole record again. Any other missing state file is uploaded again, like any missing file. Files that Cogram archived (of records that left, and in `delete_files`) are yours to keep or delete. In Mirror mode, a missing state file is uploaded again like any file. ## The status block and the runs table The section shows where the export stands: * **Last run**: the status of the newest run, when it started, how many objects and how much data it wrote, and how many it deleted. * **Next run**: when the next daily run starts. It shows **Within 5 minutes**, **After the current run**, **Paused** or **Off** when it applies. * **Failed runs in a row**: how many runs failed since the last backfill, daily or resync run that completed. A Verify does not set it back to 0. A save, or a successful test of the saved settings, also sets it back to 0. Below the settings, **Runs** lists every run, newest first: | Column | Meaning | | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Started** | When the run started. **Queued** means it is waiting to start. | | **Kind** | Backfill, Daily, Resync or Verify. | | **Status** | **Pending** (waiting to start), **Running**, **Interrupted** (stopped for now; while the export is on, it continues on its own from where it stopped), **Completed** or **Failed**. | | **Elapsed** | How long the run took, or has taken so far. | | **Written** | Files the run uploaded to the bucket. | | **Deleted** | Files the run deleted from the bucket. | | **Skipped** | Files the run made again but did not upload, because the bucket already holds the same content. | | **Bytes** | How much data the run uploaded. | | **Failures** | Files and records the run could not write or delete. The next run tries them again, and the bucket keeps their earlier files until then. | Large numbers show in short form, for example `1.2M` files or `14.3 GB`. Point to a number to see it in full. A run with an error has an arrow at the start of its row. Select it to show the error. The section refreshes on its own while a run is in progress or due: every 5 seconds while it is pending or running, every minute while it is interrupted or about to start, such as the backfill after you turn on the export. ## When something goes wrong * **A short outage** (your bucket or the network is unreachable): the run is **Interrupted** and continues on its own from where it stopped, after 5 minutes, then 15, then 45, and so on. After five interruptions in a row without progress, the sixth error fails the run. * **A failed run**: the next attempt starts an hour later. * **Settings changed during a run**: a run fails when you save another bucket, prefix, provider or export mode while it is in progress. This failure does not count toward the pause. The next run is a backfill to the new bucket. * **Three failed runs in a row**: Cogram pauses the export. The section shows **Export paused after 3 failed runs in a row** with the last error, and every owner and admin of your organization receives one email with the error and a link to the settings. To resume a paused export: 1. Read the error in the section or in the email. 2. Fix the cause, usually in AWS: the bucket, the key, or the key's policy. 3. If you changed a setting, select **Save**. If you fixed the cause in AWS, select **Test connection**. Any save, or a successful test of the saved settings, ends the pause. 4. Select **Run now**, or wait for the next scheduled run. Cogram sends one email per pause. Ending the pause, removing the credentials, or a completed backfill, daily or resync run re-arms it, so the next pause sends a new email. ### Troubleshooting **Symptom**: The test or a run fails with "Access denied. Check that the access key's policy allows s3:PutObject on this bucket and prefix." **Likely cause**: The key's policy does not allow `s3:PutObject` on the bucket. **Fix**: Compare the policy with the one in [Set up an S3 bucket for Continuous Data Export](/organization-administration/continuous-data-export-aws-setup.md). **Symptom**: The test or a run fails with "Access denied when listing" or "Access denied when deleting". **Likely cause**: The key's policy does not allow `s3:ListBucket` on the bucket, or, in Mirror mode, `s3:DeleteObject` on its objects. **Fix**: Add the missing permission from [Set up an S3 bucket for Continuous Data Export](/organization-administration/continuous-data-export-aws-setup.md). A test that fails after the upload can leave its test file under `_cogram/`. Archive mode never needs `s3:DeleteObject`. **Symptom**: **Save** fails with "Another export mode needs a new prefix". **Likely cause**: You changed the export mode and kept the bucket and prefix. **Fix**: Enter a new key prefix, then save. See [Change the export mode](#change-the-export-mode). **Symptom**: **Save** fails with "This export wrote to this bucket and prefix before." **Likely cause**: You entered a bucket and prefix that this export used earlier. Cogram never writes there again: the files belong to the earlier export. **Fix**: Enter a new key prefix. See [Change the bucket or prefix](#change-the-bucket-or-prefix). **Symptom**: **Save** fails with "Another Cogram organization already exports to this bucket and prefix." **Likely cause**: Another organization in Cogram has a saved configuration for the same bucket and prefix. **Fix**: Use a different prefix. If that export is no longer used, contact . **Symptom**: The test fails with "The bucket does not exist. Check the bucket name." **Likely cause**: A typo in the bucket name, or the bucket is in another AWS account. **Fix**: Copy the name from the S3 console. Enter the name only. **Symptom**: The test fails with "The bucket is in region …, not …". **Likely cause**: The selected region is not the bucket's region. **Fix**: Select the region the message names, then test again. **Symptom**: The test fails with "The access key ID does not exist" or "The secret access key does not match the access key ID". **Likely cause**: The access key was deleted, or the secret does not belong to the access key ID. **Fix**: Create a new access key in AWS, enter both values, then test and save. ## The state file of every record Every record in the bucket has a state file, in both modes, from its first export: * A record with a folder of its own (an email, a meeting, a document, an RFI) has `/state.json`. * A record that is one JSON file with no folder (a chat message, a workflow run, a prompt, an agent) has `.state.json` next to it, for example `chat//messages/.state.json`. * The organization's own files (`organization/`, and `projects/index.json`) share `organization/state.json`. A state file of an email looks like this: ```json { "cogram_record_id": "eml_", "record_type": "email", "state": "active", "state_changed_at": null, "delete": false, "retention_class": null, "expires_at": null, "files": [ "projects//emails//attachments/-quote.pdf", "projects//emails//email.json", "projects//emails//message.eml" ], "delete_files": [] } ``` | Field | Meaning | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `cogram_record_id`, `record_type` | The record: its ID in Cogram, and its type, for example `email`, `meeting`, `document` or `chat_message`. | | `state` | `active`, `unfiled`, `deleted` or `refiled`. For information only, best effort. | | `state_changed_at` | When Cogram found the record in its state. Null for an active record that never had another state. | | `delete` | `true` when the record left Cogram (Archive mode only): its `files` may go. Cogram writes a state file with `delete: true` once, when its record leaves, and doesn't update it afterwards. Its `retention_class` and `expires_at` are those of that moment: for an unfiled or deleted email, null. | | `retention_class`, `expires_at` | The retention of the record. A meeting follows your organization's Data retention setting, counted from the meeting time, for example `meeting-30d`. An email shows your organization's [email retention](/email/email-retention.md) ruleset and the email's class, for example `som-email-v1/short`. Its `expires_at` is null while email expiry is off for your organization. Null with unlimited retention (the default), for the example meeting, for an email without a class or in an organization without a ruleset, and where no retention rule exists, for example for documents. | | `files` | Every key of the record in the bucket, the state file aside. Each key includes your prefix. | | `delete_files` | Keys of removed parts of the record, for example a deleted attachment (Archive mode only). A key stays in the list after you delete it. | A state file changes only when its record changes: a run that finds nothing new about the record does not write it again. ### Clean up an archive In Archive mode, your own process deletes what the state files say may go. Cogram provides a reference script, which you can run by hand or schedule with AWS Lambda: see [Clean up an Archive-mode bucket](/organization-administration/continuous-data-export-cleanup.md). A cleanup script needs to know only where Cogram writes state files, not the rest of the bucket layout: 1. List every key under your prefix whose name is `state.json` or ends with `.state.json`, only in the places where Cogram writes state files (listed in [Clean up an Archive-mode bucket](/organization-administration/continuous-data-export-cleanup.md#how-the-cleanup-works)), and read each file. Skip `_cogram/`, and files with such a name anywhere else, such as under `attachments/`: they are files of a record. 2. If `delete` is `true`, or `expires_at` has passed, delete every key in `files`, then the state file. 3. Always delete every key in `delete_files`. For emails, `expires_at` appears once your organization turns on email expiry, and your cleanup script can remove the email at that date. While expiry is off, it is null, and your cleanup script removes an email only after it leaves Cogram (`delete: true`). The state file of a live record never says `delete: true`. When a record that left comes back, for example an email refiled back to its project or a restored document, Cogram writes its files again under the same keys and rewrites its state file to `active` and `delete: false`. The files go up first, so between the two writes the old state file still says `delete: true`. So read each state file again right before you delete its keys, and do not delete the files of a record that says `delete: true` when one of its files was written after its state file. The reference script does both. Run the cleanup when no Cogram run is in progress; if a cleanup ran during a run, **Verify bucket** uploads the missing files of live records again. The key you gave Cogram may not delete, so the script runs with your own credentials. Once a record's state file is gone, and it said `delete: true` or an `expires_at` that has passed, **Verify bucket** takes the record as cleaned up, and Cogram does not upload it again unless it changes in Cogram. If its retention gets longer while it still exists in Cogram, Cogram uploads the whole record again. ## What the archive keeps In Archive mode, Cogram never deletes a file: | Change in Cogram | What the bucket shows | | -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A record is deleted | Its files stay. Its state file says `delete: true` and `state: deleted`. | | An email is unfiled | Its files stay. Its state file says `delete: true` and `state: unfiled`. | | A record is refiled, such as an email moved to another project | The old copy stays, and its state file says `delete: true` and `state: refiled`. The new project's folder gets a full active copy. | | A part of a record is removed, such as a deleted attachment | The file stays, and the record's state file lists it in `delete_files`. | | A meeting expires under Data retention | `meeting.json` is written again with what stays visible in Cogram (title, time, attendees, project). The minutes, the transcript and the insights stay, and the state file lists them in `delete_files`. The state stays `active`. | | A record comes back (restored, or refiled back) | Cogram writes its files again, then rewrites its state file to `active` and `delete: false`. The state file of a live record never says `delete: true`. | ## What the mirror removes In Mirror mode, the bucket shows the current state of your organization: * Records removed in Cogram are deleted from the bucket, with their files and their state file: deleted records and unfiled emails. * An expired meeting keeps `meeting.json`, written again with what stays visible in Cogram. Cogram deletes its minutes, transcript and insights. * Records moved to another project, such as a refiled email, are written under the new project and deleted from the old one. * Cogram deletes only files that it wrote and that its record proves gone. It never deletes a file that it has no record of. ## Keep the bucket for Cogram only Cogram decides what to upload, and in Mirror mode what to delete, from its own record of the bucket. A daily run does not list the files in the bucket. For this reason: * Use a bucket, or at least a prefix, that only Cogram writes to. Use one prefix for each Cogram environment. * **Warning:** Cogram cannot see an export of another Cogram environment. Two environments that write to the same bucket and prefix are not detected. For example, never point a restored staging copy at a production prefix. * When you save, Cogram refuses only these prefixes: one that another organization of the same Cogram environment exports to, a bucket and prefix that this export used before, the current prefix with another export mode, and a prefix that starts with a folder Cogram writes (see **Key prefix** in [Set up the export](#set-up-the-export)). * Do not add or change files under the prefix by hand or with other tools. * In Mirror mode, do not delete files under the prefix either. In Archive mode, delete only files that Cogram archived (see [What the archive keeps](#what-the-archive-keeps)). A file of an active record deleted by hand does not come back until its content changes in Cogram, or until you run **Verify bucket**. Files added under the prefix stay: **Verify bucket** counts them as unknown. If something changed the bucket, run **Verify bucket** to bring it back in line. ## Change the export mode Another export mode needs a new key prefix (or another bucket). Cogram never writes over the files that the current mode wrote: an archive stays as it is, and a mirror never deletes an archive's files. If you change the mode and keep the prefix, **Save** fails with "Another export mode needs a new prefix". When you save the new mode with a new prefix: * The next run is a backfill that uploads everything to the new prefix. * The files under the old prefix stay as they are. Cogram does not change them again. * The last connection test no longer applies: test the connection again, because each mode needs other permissions. ## Change the bucket or prefix When you save another bucket, prefix or provider, Cogram treats it as a new target: * The next run is a backfill that copies everything to the new location. * Cogram does not change or delete anything in the old location again. The files there stay as they are, as your own copy. * You cannot go back to the old location later: **Save** refuses a bucket and prefix that this export used before. A new access key for the same bucket and prefix is not a new target: the export continues where it was, without a backfill. A new region alone is not a new target either, because a bucket has one region: if you selected the wrong region, select the right one and save. To rotate the key, see [Rotate the key](/organization-administration/continuous-data-export-aws-setup.md#rotate-the-key). ## Remove the credentials Select **Remove credentials** to delete the access key ID and secret that Cogram stores. This turns the export off. Your bucket and everything in it stay as they are. To resume, enter a key again, turn on **Export every day**, and select **Save**. If the bucket and prefix are the same, the export continues where it was. To turn the export off but keep the key, turn off **Export every day** and save. The files in the bucket stay. When you turn it back on, the next run applies everything that changed in the meantime. ## How the bucket differs from a zip export The bucket follows the [data export package layout](/organization-administration/data-export-package-layout.md), with changes that keep every file's key stable. A rename never moves a file: * **Folders are named by ID only.** A project is `projects//`, a meeting is `meetings//`, and so on, without the name suffix. * `projects/index.json` lists every project with its `id`, `name`, `customer_project_id`, `is_personal` and `archived_at`, so you can find a project by name. * **Files are named by ID.** * Meeting attachments: `attachments/-`. * Meeting and observation photos: `photos/.`. * Drawing revisions: `revisions/.`, with the extension of the revision's file. * Submittal, RFI and change order attachments: `attachments/---`, for example `external-review---markup.pdf`. * Document versions keep `attachments/versions/NNN-`. * **Each email has its own folder.** No subject is part of a key. `emails//` holds: * `email.json`: the sender, recipients, subject, dates, the confidential type and the list of attachments. The confidential type is `CONFIDENTIAL` or `CONFIDENTIAL_ARCHIVE` for a confidential email, and `null` for other email. The bucket holds confidential email too, like a zip export. * `message.eml`: the full message. * `attachments/-`. * **One file per item where the zip has one list file.** * Chat messages: `chat//messages/.json`. * Prompts: `organization/prompts/.json`. * Agents: `organization/agents/.json`. * Workflow runs: `workflows//runs/.json`, next to a `workflow.json` that no longer holds its runs. * **A state file for every record** (see [The state file of every record](#the-state-file-of-every-record)). * **Removed records.** In Archive mode, a record removed in Cogram keeps its files, and its state file says `delete: true` (see [What the archive keeps](#what-the-archive-keeps)). In Mirror mode, it has no files in the bucket after the next run. * **A `_cogram/` folder** holds Cogram's own files: * `layout.json`: the layout version, and the configuration, generation and export mode that write the prefix. Every exported file also carries the layout version in its `x-amz-meta-cogram-layout-version` metadata. * `runs/.json`: a summary of each completed run. Cogram also tries to write one when a run fails on an unexpected error. * `connection-test.json`: the file of the connection test, written again by every test. A run does not delete Cogram's own files. ## Known limitations * **Removed parts of a record.** Some parts of a record have no file of their own, for example an action item of a meeting. * When such a part is removed for good, the record's JSON can keep listing it until the record changes for another reason or you run a resync. * When a file of a record is removed, the file goes from the bucket at the next run in Mirror mode. In Archive mode it stays and the record's state file lists it in `delete_files`. The record's JSON can keep listing it in the same way. * **Retention changes.** After a change of a Data retention setting in Cogram (of the organization, a group or a user), the next run is a resync, which writes the new `expires_at` into every meeting's state file. Moving a user to another group does not start one: run a resync yourself. A change of the email retention ruleset, or turning email expiry on or off, also makes the next run a resync. A change of an email's class (archive, unarchive, reclassify) is written at the next run. * **Template changes.** A new meeting template, or a change to your organization's table style, applies to `meeting.docx` files written after the change. Run a resync to write every meeting's minutes again. ## Related pages * [Set up an S3 bucket for Continuous Data Export](/organization-administration/continuous-data-export-aws-setup.md) * [Data exports](/organization-administration/data-exports.md) * [Data export package layout](/organization-administration/data-export-package-layout.md) * [Data export field reference](/organization-administration/data-export-field-reference.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.cogram.com/organization-administration/continuous-data-export.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.