Staging draft Work in progress · For review; coverage and acceptance incomplete

Classification, retention and final disposition

Classification gives a record a consistent place in the organization's filing structure. Retention defines a period measured from filing and an eventual archive or close outcome. These rules help records teams understand what should happen to preserved work, but a configured rule is not proof that the organization has approved it or that every required control is operational.

Availability: this page explains the implemented backend rules. Registration can obtain classification choices, but the inspected application does not establish a connected classification editor, retention-policy editor, disposal queue or disposal action. There are no verified screen steps for those operations here. Confirm the supported administrative process and readiness with the platform team.

Keep the concepts separate

Concept Purpose What it does not establish
Record category Identifies the kind of record, such as incoming correspondence. A security permission or a physical folder.
Classification plan Maps record categories to a filing location, numbering scheme and retention code. That every configuration entry is valid or that the retention policy exists.
Classification location Gives the record a code and a readable hierarchy, such as Correspondence / General. Access to all records under that heading.
Numbering scheme Supplies the official reference format used during registration. That the record has already been filed.
Retention policy Defines a positive period in days, months or years and the final archive or close outcome. An independently verified legal requirement or automatic deletion schedule.
Dossier Groups related records about a matter, person or case. A shared retention policy inherited by all those records.

See dossiers for grouping and record intake and registration for the intended registration journey.

How the classification plan affects work

The active plan associates each supported record category with a classification location, a numbering scheme and a retention code. Registration and filing use that configuration. Missing or invalid configuration can stop the work even when the document itself is acceptable.

A newly encountered organization with no plan can receive the built-in starter plan when the relevant operation resolves filing rules. The starter includes correspondence, procurement-contract and personnel categories. It does not cover every conceivable business record type. An organization that already has plans but no active plan does not receive another starter plan automatically.

A classification plan can be saved while containing errors. Examples include a missing parent in the hierarchy, a circular hierarchy, a filing rule pointing to a missing location, or a record category with no numbering scheme. Any retained configuration error prevents the plan from resolving filing rules, including for another category that appears correct.

The current save operation replaces the complete plan configuration. It is not a change to one row in isolation. Administrators need a complete, reviewed configuration and a recovery process before making changes. Do not assume omitted entries will be preserved or that a successful save means the plan is ready to use.

Filing starts the retention calculation

Registration assigns the official reference and responsibility; filing records the classification placement. These are separate stages. For the retention behavior described here, the relevant starting date is the current filing placement's date—not upload, arrival, registration, case closure or employment separation.

The record keeps the saved classification code, path and retention code. The system then looks up the policy associated with that retention code. A code can be present without a matching usable policy having been established for the organization. In that situation, the expected retention calculation or disposal operation may be unavailable.

Creating a starter classification plan is not proof that all its referenced retention policies have been created for that organization. Personnel-record creation has its own default-policy preparation; an edited classification plan can still select a different policy. The personnel-file guide explains the staff-record journey and its current limits.

Understand the eligibility date

Eligibility is calculated by adding the policy's period to the current filing date. For example, a record filed on 15 January 2026 under a seven-year policy reaches its calculated date on 15 January 2033. This is an illustration of the calculation, not a recommended retention period.

Years and months follow calendar arithmetic. Eligibility is not a number of completed workflow tasks, an upload-age counter or proof that a review has taken place. A block on final disposition prevents an otherwise old-enough record from qualifying.

Calculations use the current policy definition. Changing its period can change the calculated date for records already linked to that code; changing its final outcome can change what a later execution does. The record does not retain an independent copy of every policy version when it is filed. Review the effect on existing records before changing a policy.

The backend can calculate a queue for an explicitly supplied date. A future-date assessment is planning information, not evidence that those records are eligible today. The current implementation's date and policy-activation controls still need operational reconciliation before this action is accepted for use.

What the disposal queue means

The general queue considers records with a current filing placement, matching retention policy and no recorded disposal execution, in its supported filed, archived or historical stages. Personnel records are excluded from this general queue.

Rows can include records whose period has not elapsed or whose disposition is blocked. Presence in the queue is therefore not permission to proceed; the eligibility result and the record's circumstances must be checked separately. An empty result does not prove that every organizational record has completed its retention obligations.

A previous-file import starts without ordinary filing placement, classification or retention assignment. Its historical status alone does not make it ready for final disposition. See pre-system files for import's actual results.

The queue is also not evidence that an automatic disposal job is running. The inspected implementation exposes an explicit operation, with no matching scheduled execution or connected user action established by this documentation.

Archive or close is not document destruction

The implemented final outcomes are:

  • Archive: records the final disposition and sets the record's stage, custody and filing state to Archived.
  • Close: records the final disposition and sets those states to Closed.

The operation creates an execution record containing who acted, when, the record and policy references, filing and calculated eligibility dates, outcome and any notes. The current path rejects a second execution for that record and provides no undo operation.

Neither outcome deletes document bytes in the inspected execution path. Do not describe it as shredding, storage erasure or proof that originals have been destroyed. Organization-wide data deletion and storage cleanup are separate mechanisms, described in Records evidence and organization data.

The stored execution preserves its recorded dates and outcome. A later policy change can make the current policy display differ from that execution evidence. Keep the distinction when explaining why an older action occurred; the execution is not a complete versioned copy of the policy.

Blocks, access and recovery

The record model supports a block with a reason, actor and time, and disposal checks that block. The inspected application does not establish a connected action for applying or clearing it. Do not assume a sample “hold” control or a policy's inactive label proves that disposal is prevented. The missing management and enforcement behavior needs resolution before operational use.

Situation Responsible next step
Registration or filing reports invalid configuration Ask the records administrator to reconcile the complete active plan, including errors outside the current record category.
A retention code has no policy Confirm the intended policy for that organization; do not substitute a period based only on the code's name.
A policy needs to change Review affected existing records and the resulting dates/outcomes before using the supported administrative process.
A record is blocked Preserve the reason and follow the organization's authorized review. Do not bypass the block by recreating the record.
A disposal result is uncertain Reconcile the existing execution and record state before repeating the operation. Keep the original request and returned reference if available.
Queue and record information differ Check the assessment date, current filing placement, policy changes and whether an execution already exists.
Someone requests proof of document destruction Obtain evidence from the actual authorized deletion process; an Archived or Closed label is insufficient.

Business owners should approve their classification and retention rules, verify who may maintain and execute them, and establish evidence for exceptions and recovery. Built-in examples and a successful calculation do not establish legal compliance, complete preservation or a deletion commitment.

Zerohive documentationStaging draft · 22 Oct 2026

Search documentation

Search guides, platform concepts and tasks.

↑ ↓ to move Esc to close