# Dormancy reactivation exception The dormancy process reactivates an account whenever a transaction is posted, unless the transaction uses a processing code included in `dormant_processing_codes`. While this is appropriate for different types of operations, it does not account for variables that only exist outside of the Pismo platform—such as legacy transaction codes or custom identifiers—that should not influence a bank account’s dormancy state. To address this gap, the Pismo platform provides a dormancy reactivation exception feature that allows specific transactions to bypass reactivation based on attributes like metadata or soft descriptors. This capability is designed to support exceptions driven by variables external to the platform but intrinsic to your business rules, while preserving the platform’s standard behavior for all other cases. # Reactivation exceptions configuration Use the `reactivation_exceptions_config` object in the [Create](https://developers.pismo.io/pismo-docs/reference/post-dormancy-config-v2) or [Update dormancy configuration](https://developers.pismo.io/pismo-docs/reference/patch-dormancy-config-v2) endpoints to define attribute‑based rules that let specific transactions bypass dormancy reactivation. This object includes two fields. | Field name | Description | | :--------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `field` | Indicates which transaction attribute the Pismo platform should evaluate to determine whether a transaction is exempt from reactivating a dormant account. The field value can be either `soft_descriptor` or `metadata`, and you supply corresponding values for the selected option. | | `values` | Specifies the values that, when found in the selected field, prevent the transaction from reactivating the account. You can provide any values in this field. The list contains the exact values you expect to receive in either the `soft_descriptor` or `metadata` field, depending on which one you selected. | ## How reactivation exception works This is how you create and apply dormancy reactivation exception. 1. In the [Create](https://developers.pismo.io/pismo-docs/reference/post-dormancy-config-v2) or [Update dormancy configuration](https://developers.pismo.io/pismo-docs/reference/patch-dormancy-config-v2) endpoint, set a value in the field property of the `reactivation_exceptions_config` object. This value can be either `soft_descriptor`—which tells the Pismo platform to check the `soft_descriptor` field in the `credit` or `debit` object, or at the root level—or `metadata`. The request body follows this format. ```json { "reactivation_exceptions_config":{ "field":"", "values":[ "", "", "..." ] } } ``` 2. Specify a value or values in the selected field (either `soft_descriptor` or `metadata`) in the `credit` or `debit` object or at the root level of the following endpoints. * [Post payment](https://developers.pismo.io/pismo-docs/reference/corporate-v2-post-payments) * [Post multi-leg payment](https://developers.pismo.io/pismo-docs/reference/corporate-v3-post-multileg-payments) * [Upload bulk file](https://developers.pismo.io/pismo-docs/reference/corporate-put-bulk-file) (include `soft_descriptor` and `values` fields with specified values in the bulk file) **Notes** * You can configure up to 30 values in the values list. * The `metadata` and `soft_descriptor` fields appear both within the `credit` and `debit` objects and at the root level of the [Post payment](https://developers.pismo.io/pismo-docs/reference/corporate-v2-post-payments) request body. You can use either location to trigger dormancy exceptions defined in the dormancy configuration. * When you set a value for `soft_descriptor`—whether in `credit`, `debit`, or at the root—or when you set a value in `metadata`, that value becomes the one used by `reactivation_exceptions_config`. For example, if `reactivation_exceptions_config.field` is set to `soft_descriptor`, the Pismo platform pulls the `soft_descriptor` value either from `credit`/ `debit` or the root. ## Examples ### Reactivation exception fails Consider an example where values are specified in these fields. | Endpoint | Field | Value | | ------------------------------------------------------------ | --------------------------------------- | ----------------- | | [Create dormancy configuration](https://developers.pismo.io/pismo-docs/reference/post-dormancy-config-v2) | `reactivation_exceptions_config.field` | `soft_descriptor` | | [Create dormancy configuration](https://developers.pismo.io/pismo-docs/reference/post-dormancy-config-v2) | `reactivation_exceptions_config.values` | `001` | | [Post payment](https://developers.pismo.io/pismo-docs/reference/corporate-v2-post-payments) | `credit.soft_descriptor` | `005` | **Result**: The value `005` in `credit.soft_descriptor` does not override the dormancy‑reactivation rule because the code configured in `reactivation_exceptions_config.values` is `001`. Since the value provided in [Post payment](https://developers.pismo.io/pismo-docs/reference/corporate-v2-post-payments) is `005`—which does not match the configured exception—the Pismo platform does not treat it as an allowed exception, and the dormant account is reactivated. ### Reactivation exception succeeds | Endpoint | Field | Value | | ------------------------------------------------------------ | --------------------------------------- | ------------------- | | [Create dormancy configuration](https://developers.pismo.io/pismo-docs/reference/post-dormancy-config-v2) | `reactivation_exceptions_config.field` | `metadata.t_code` | | [Create dormancy configuration](https://developers.pismo.io/pismo-docs/reference/post-dormancy-config-v2) | `reactivation_exceptions_config.values` | `001`, `005`, `006` | | [Post payment](https://developers.pismo.io/pismo-docs/reference/corporate-v2-post-payments) | `metadata` | `001` | **Result**: Since `001` is one of the custom values defined in `reactivation_exceptions_config.values` that blocks dormant accounts from being reactivated, it is applied, and the account remains inactive.