# Restriction management

The [Dormancy](https://developers.pismo.io/pismo-docs/reference/post-dormancy-config-v2) feature includes enhanced restriction management capabilities, giving you greater flexibility and control over how account restrictions are applied when accounts transition into and out of dormant status.

These improvements enable you to define rules that adapt restrictions based on an account’s existing state, control how restrictions behave during reactivation, and ensure that transactions and dormancy checks follow your operational and compliance requirements.

Advanced restriction management includes the following features.

| Feature                                                                   | Description                                                                                       |
| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| [Restrictions](#restrictions)                                             | Apply conditional restrictions when an account becomes dormant, based on its current restriction. |
| [Reactivation with last restriction](#reactivation-with-last-restriction) | Decide whether an account should retain its last restriction upon reactivation.                   |

These improvements make restriction handling more context‑aware and customizable, reducing the need for manual intervention and helping ensure compliance with business rules across different regions and operational scenarios. For details, refer to [Create dormancy configuration](https://developers.pismo.io/pismo-docs/reference/post-dormancy-config-v2).

These subsections describe each capability in detail, explain how it works, and provide examples for implementation.

# Restrictions

The `statuses` field in the [Create dormancy configuration](https://developers.pismo.io/pismo-docs/reference/post-dormancy-config-v2) endpoint is an array of status objects that you use to define the statuses related to dormancy. Each status object contains a restrictions array field that allows you to define conditional logic that is applied when the account status changes to `DORMANT`.

The Pismo platform checks the account’s current restriction using the field `current_reason_external_id`.\
If a matching condition is found in the `restrictions` array, the account is assigned the corresponding `new_reason_external_id` when it becomes dormant. If no condition matches, the account receives the default restriction defined by `reason_external_id`.

## Example

### Default behavior

After 30 days of inactivity, an account transitions to `DORMANT` with the restriction `reason_external_id` = `CREDIT_ONLY`.

### Conditional override

If an account is `NORMAL` and restricted as `DEBIT_ONLY`, you can configure the system so that when it becomes `DORMANT`, it receives `NONE` instead of the default `CREDIT_ONLY`.

<Callout icon="📘">
  **Note**

  You can add as many restrictions as necessary to meet your business needs.
</Callout>

### Impact of `reason_external_id`

This table summarizes how `reason_external_id` impacts different financial transactions.

| `reason_external_id`                 | Debit posting allowed | Credit posting allowed | Forced credit allowed | Forced debit allowed |
| :----------------------------------- | :-------------------- | :--------------------- | :-------------------- | :------------------- |
| `DEBIT_ONLY`                         | ✔                     |                        | ✔                     | ✔                    |
| `CREDIT_ONLY`                        |                       | ✔                      | ✔                     | ✔                    |
| `ALL`                                | ✔                     | ✔                      | ✔                     | ✔                    |
| `NONE`                               |                       |                        | ✔                     | ✔                    |
| `CREDIT_ONLY_NO_FORCE_DEBIT_ALLOWED` |                       | ✔                      | ✔                     |                      |
| `DEBIT_ONLY_NO_FORCE_CREDIT_ALLOWED` | ✔                     |                        |                       | ✔                    |
| `ALL_NO_FORCE_ALLOWED`               | ✔                     | ✔                      |                       |                      |
| `NONE_NO_FORCE_ALLOWED`              |                       |                        |                       |                      |
| `FORCE_CREDIT_ONLY`                  |                       |                        | ✔                     |                      |
| `FORCE_DEBIT_ONLY`                   |                       |                        |                       | ✔                    |

# Reactivation with last restriction

The `reactivation_with_last_restriction` field allows you to control whether an account, once reactivated from a dormant status, must retain the restriction it had before becoming dormant.

If you set `reactivation_with_last_restriction` to `true`, the account returns to `NORMAL` status with the same restriction it had before dormancy; otherwise, the account is reactivated without any previous restrictions, unless another rule applies.

## Example

If an account was `NORMAL` with a restriction of `DEBIT_ONLY` before becoming `DORMANT`, setting `reactivation_with_last_restriction` =` true` ensures it returns to `NORMAL` with `DEBIT_ONLY` after reactivation.