# Configuring Cascading Review & Approval for Binder Content (RIM) Cascade Review & Approval for Binder Content allows Vault to move a binder's component documents into a new state and apply new binding rules based on state changes that users initiate on the binder. You can accomplish this by configuring entry actions on lifecycles that apply to binders.
## Configuration Overview Follow the steps below to configure Cascading Review & Approval for Binder Content: 1. Update document lifecycles to select specific lifecycle states for [state types](/en/lr/14560/). This is necessary on any lifecycles used by documents that will be part of binders using Cascading Review & Approval. 2. Update lifecycles that apply to binders in your Vault. In a standard RIM Vault, this is only the _Binder Lifecycle_. Create [entry criteria](/en/lr/12617/) and [entry actions](/en/lr/12399/) with the newly available configuration options. If these don't already exist, create user actions and/or workflows to move the binder through different lifecycle states. ## Configuring Cascading Binder Review & Approval {#enable} To enable Cascading Review & Approval for binder content, configure the various Binder Content entry criteria and actions, as well as document lifecycle state types, according to your organization's requirements: * **_Binder Content_ entry criteria**: _In state type_ and _Not in a workflow_ * **_Binder Content_ entry actions**: _Set binder content state type_, _Set binder content version binding_, and _Set binder content version binding by state type_ * **State types for document lifecycles**: _Reviewed_ and _In Approval_ ### Binder Content Entry Criteria The binder content entry criteria look within the binder that is changing states, at the component documents and sub-binders. Entry criteria ignore component documents within a sub-binder. * **In state type**: Verifies that the component documents and sub-binders are all in the lifecycle state that corresponds to the selected state type. Use this criteria to prevent a binder from moving forward in its lifecycle before its contents are in the correct state. For example, the binder cannot move to _Approved_ until all documents have reached _In Approval_ state. You can select multiple state types for documents to reach in order for the binder to change states. For example, the binder cannot move to _Approved_ until all documents have reached either _Reviewed_ or In _Approval_ state. * **Not in a workflow**: Verifies that the component documents and sub-binders do not have an in-progress workflow. For example, use this criteria to prevent a binder from moving into _Approved_ state while its documents are still in a review workflow. ### Binder Content Entry Actions The binder content entry actions look within the binder that is changing states, at the component documents and then perform actions on those documents. Entry actions ignore sub-binders and component documents within sub-binders. * **Set binder content state type**: Moves component documents to the lifecycle state that corresponds to the selected state type. You must also select the **From State Type** for the component documents. Use this action to "cascade" a state change from the binder to its documents, for example, when the binder moves to _Approved_, the _In Approval_ documents move to _Approved_. You can select multiple state types for documents in order to cascade state change. For example, when the binder moves to _Approved_, documents that are in _Reviewed_ and _In Approval_ state types move to _Approved_. Documents within the binder that are in _Draft_ state remain in _Draft_. If any component documents do not meet their new lifecycle state's entry criteria, the entry action fails for all component documents. * **Set binder content version binding**: For each component document, binds the latest document version in the selected state type to the binder. This change applies to both unbound documents and documents with another version already bound. If a document does not have a version in the specified state type, this action doesn't make any change to that document's binding rule. * **Set binder content version binding by state type**: This action functions like the _Set binder content version binding_ action, but allows you to select one or more state types as a condition. Only documents currently in the state type are bound or re-bound by this action. ### State Types on Document Lifecycles Entry criteria and entry actions use state types in their configurations, rather than specific lifecycle states. This allows a single configuration to apply to component documents in multiple lifecycles. The Cascade Review & Approval feature includes the _Reviewed_ and _In Approval_ state types. You can access the _In Review_ and _Rejected_ state types by enabling the [Batch Approval](/en/lr/36606/) feature. You're not required to set lifecycle states for these state types, but we recommend doing so for a more comprehensive review and approval lifecycle. Within each of the document lifecycles, make sure that you select specific lifecycle states for any of the state types that your configurations use. For example, if a _Set binder content state type_ entry action moves documents into the _In Review_ state type, but some documents have lifecycles without this state type defined, Vault cannot complete the entry action. ## Related Permissions ### View Document on Binder Content When users initiate a state change on the binder, Vault checks to see if they have _View Document_ permission on all component documents and sub-binders. Users who do not have permission on all binder components cannot complete a state change on the binder if it includes any of the above entry criteria or entry actions. There is an exception to this rule if the binder's state change takes place as part of a workflow. When a workflow performs a state change, Vault does not check that the user who started the workflow has permission to view all documents and sub-binders within the binder. State change or version binding on binder content will still occur, even if the user that had triggered the workflow does not have access to the binder content. ### Edit Document on Binder To initiate a binder state change that will trigger version binding on binder content, users must have the _Edit Document_ permission on the binder's target lifecycle state. This is the state the binder will be in when documents are bound or re-bound to it. Like _View Document_ permission on binder content, there is an exception when the state change occurs as part of a workflow. In this situation, the user initiating the workflow does not need _Edit Document_ permission on the binder. [1]: #enable