# Document State Types & Special States

For each document lifecycle, there are state type definitions which must be linked to a configured lifecycle state. The linked states then have some specialized behaviors. For example, Vault doesn't allow users to delete a document in its lifecycle's _Steady_ state. Learn about [state type rules below][0].

## State Types

The following standard state types are available in all vaults:

* **Starting State**: Depending on your configuration, either all documents or some documents start in this state. This state is typically called _Draft_ or _In Process_, but could be _Approved_ if the lifecycle includes only approved documents. With some configurations, documents will start in _Planned_ state. Learn about [_Planned_ and _Starting_ states below][1].
* **Steady State**: Documents that are in production and available for use have this state. This state is typically _Approved_ or _Effective_.
* **Superseded State**: Documents that have been archived or replaced by a new version. This state is typically _Archived_ or _Superseded_.
* **Obsolete State**: Documents that have reached the end of their lifecycle or have retired document numbers. This state is typically called _Obsolete_ or _Retired_.
* **Deleted State**: Documents that are not available for use but should not yet be fully deleted.

### Document Workflow State Types

<a href="/en/gr/50498/">Document workflows</a>
 use an additional set of system state types. These are specifically designed for multi-document workflows to move documents to new lifecycle states based on the _Content Action_ document workflow step.

* **Multi-Doc Workflow: Pre-Approval**: Documents are currently in a pre-approval state.
* **Multi-Doc Workflow: Approved**: Documents in the workflow that are approved.
* **Multi-Doc Workflow: Rejected**: Documents have failed the review process and are rejected.

### Batch Approval State Types

An additional set of state types is available on Vaults that use <a href="/en/gr/36519/">Batch Approval</a>
. These are needed for the Batch Approval feature to move documents to new lifecycle states based on actions on related _Batch_ object records.

* **In Review**: Documents that are currently in review. This state type has no special behaviors.
* **Rejected**: Documents that have failed their review process. This state type has no special behaviors.



### Clinical Operations State Types

Clinical Operations Vaults include the following standard state types, which do not have any specialized behaviors but can be used in document workflows:

* **Delete Requested**: Documents to evaluate for deletion.
* **Soft Delete One Version**: Intended for documents where the current version's access is restricted, but the document remains in the Vault and can be restored.
* **Soft Delete All Versions**: Intended for documents where all versions' access is restricted, but the document remains in the Vault can be restored.
* **Inbound Transfer**: Documents transferred from another vault via a <a href="/en/gr/53358/#connections">Vault to Vault connection</a>
.
* **Received from SiteVault**: Documents transferred from a SiteVault vault via <a href="/en/gr/64231/">Veeva Site Connect</a>
. This state type is only available in vaults with Veeva Site Connect enabled.








## How to Define State Types {#how-to-define-state-types}

State type definitions can be set up and edited from the lifecycle details page. To see or edit these definitions, navigate to **Admin > Configuration > Document Lifecycles > [Lifecycle]**. To modify these settings, you must have a security profile with the _Admin: Lifecycles and Workflows_ permissions.

## Rules for State Types {#rules}

There are rules and specialized behaviors built into Vault for specific state types.

**Starting State**:

* All new documents and binders (except _Planned_ documents) have this state automatically.
* The new document version created by the **Create Draft** action has this state automatically.

**Steady State**:

* Users cannot delete documents in this state. (Users with the **Power Delete** permission may override this rule.)
* If using the entry action option **Set previous steady state to superseded**, when a document changes status, all versions of the document currently in this state automatically move to the superseded state.

**Superseded State**:

* If using the entry action option **Set previous steady state to superseded**, when a document changes status, all versions of the document currently in the steady state automatically move to this state.

**Obsolete State**:

* When a document moves to this state (via the **Make Obsolete** action or another custom action), all versions of the document also move to the obsolete state. Vault only applies entry criteria and entry actions to the latest version of the document.

**Deleted State**:

* The _Deleted_ state type is not tied to any special behavior in the current release, but will be used in future features.

## About Starting State & Planned State {#planned_starting}

For the Vault as a whole and for each lifecycle, Admins can decide whether certain documents start in _Planned_ state or in the lifecycle's _Starting_ state. For documents to begin in _Planned_ state, the following must be true:

* In **Admin > Settings > General Settings**, the **Create new documents as Planned** feature must be enabled.
* For the document's or binder's lifecycle, the standard _Planned_ state must be active.

When the above are true, Vault follows the rules below when creating documents or binders:

* Placeholders: Begin in _Planned_ state
* Binders: Begin in _Planned_ state
* Documents created from document templates: Begin in _Planned_ state
* Documents created from binder templates: Begin in _Planned_ state
* Documents created from uploaded file: Begin in _Starting_ state
* Documents created as CrossLinks: Begin in _Starting_ state

If your Vault does not have the **Create new documents as Planned** setting enabled, only documents created through binder templates will use _Planned_ state. Even with the setting enabled, any document or binder with a lifecycle that does not include _Planned_ state will use the _Starting_ state instead.

 [0]: #rules
 [1]: #planned_starting