--- title: How Data starts work and archives completed cards url: /docs/data-worked-example --- # How Data starts work and archives completed cards A table's settings and Data's built-in automation do different jobs. The settings say which behaviour you want for that table. The automation contains the steps that carry it out. Data makes this distinction visible with two processes: starting an agent assigned to a row, and archiving a card after it has spent the chosen number of days in a Done state. This example follows those supplied processes using a fictional team's work list. ## The example list Imagine a team tracks work through **To do**, **In progress** and **Done**, with an assignee column for the person or agent responsible. They want completed cards to stay visible for three days, then move out of the active list. Those names and the three-day period are example choices, not a separate feature you add or Data's universal defaults. A Done state means a stage designated as an end of the table's process; it does not have to be literally named “Done.” The archive rule needs a table with a configured process, permission to change its settings and Automations available. Data does not offer this rule for records that another feature alone is responsible for retiring. For those records, use the owning feature's controls. ## Choose the waiting period in the table The table's process settings supply the archive rule. The supported period is 1–365 days; clearing the rule turns automatic archiving off for that table. For this example, choose three days. The period is measured from when the card entered its Done state, not from its most recent ordinary edit. Adding a note to a completed card does not restart the clock. The setting applies to that table. Another table can use seven days, or no automatic archiving, without needing its own copy of Data's built-in automation. ## Follow the supplied archive process ```mermaid flowchart LR entered["Card enters a Done state"] --> wait["Wait until the card is due"] wait --> archive["Archive the card"] ``` The wait is part of the visible process. It uses the due time Data calculated from the card's entry time and the table's rule. At the archive step, Data checks the card again. It acts only if the card is still in the relevant Done state, the rule still matches and the card is due. The result is an archived card, not a deleted record. Archived cards can be restored. The action performs those checks itself. The graph does not need an extra decision step asking whether the row changed or whether archiving is still allowed. ## What if something changes during the wait? | Change | Effect on the pending archive | |---|---| | Someone edits an ordinary field, such as a note | The same Done stay and due time remain. The archive action uses the current record when it acts. | | The card leaves Done | The old archive attempt leaves it alone. | | The card leaves Done and later returns | The return is a new stay with a new entry time; the earlier attempt cannot archive it on the old schedule. | | The waiting period changes | An attempt carrying the old due time leaves the card alone. The rule schedules eligible cards against the new due time. | | The rule is cleared | The table stops starting archive work, and an older waiting attempt leaves the card alone when it resumes. | | The card has already been archived | Another attempt does not archive it again. | Enabling or changing a rule can include cards already in Done. They wait only for the remaining time under the new rule; a card already due may be archived without another full three-day wait. Older cards outside the scheduler's supported backfill limits are not guaranteed to be picked up. “Left alone” is useful information. It can mean the process correctly respected a later change, rather than that something failed. ## Start work from an assignment Data's built-in automation also has **Start assigned agents**. Its supplied stage contains one action: **Start the assigned agent's work**. An assignee column decides whether putting an agent on a row should start work. With that setting off, the cell records the assignment but starts no one. The agent must also be available and permitted to do the work; recording an assignee does not grant those permissions. When the setting is on and the assignment changes, the action receives that assignment. Before starting, Data checks that the same agent is still assigned. An outdated assignment cannot start work for the previous agent. Repeated processing of the same assignment refers to the same task rather than creating another one. A normal edit to the row is not a new assignment, so it does not by itself start the agent again. Assigning a person is also not an instruction to launch an agent task. ## Decide what happens when work changes hands The assignee column has two related choices: - **When someone else is put on a card:** stop the earlier agent's work, or let it finish. Letting it finish does not let its result take over the replacement assignment. Stopping it does not undo actions it already completed. - **When the agent finishes:** leave the card where it is, or move it to a configured stage, subject to the table's transition rules. Who is assigned and where a card is in its process remain separate facts. A task from a superseded assignment cannot later move the current card as though it still owned the work. ## Change a value or change the process? Use the table's settings when you want a different waiting period or different assignment behaviour. Edit the built-in automation only when you want to change the sequence itself and have permission to do so. For example, Data permits a customized archive process to change the card's assignee before archiving it. That is an additional action in the process, not another archive-period setting. It is not part of the supplied two-step archive graph. Changing Data's shared stage can affect all tables it serves. Review that scope before publishing. Existing runs keep the code they began with; their actions still respect current permissions and state. ## What this example shows The table stores the record and its settings. The built-in automation makes the work visible. Reusable actions enforce the rules even when another process calls them. That separation lets you change a business process without rebuilding record storage, copying the same automation for every table or adding permission checks by hand. Read [Built-in automations](built-in-automations.md) for the wider picture, or see [Data's built-in automation](/docs/features/data/automations/data) in Help's library.