# Overview

To design the policies for your environment, you need to identify all business workflows in your organization and create a framework of policies to match.

You need to consider the following:

- The intent types to which the policy applies.
- The condition, used to further filter and adapt the policy to a dedicated business use-case.
- The approval workflows, which detail the roles and the number of approvals for the request to be approved.


The first step of any policy workflow must be an approval by the user role that creates the intent, as the intent creator counts as the first approver.

Without a suitable maker role assigned to the first step of an approval workflow for the relevant intent, the request cannot be executed.

## Central principles of the policy framework

The central principles of the policy framework are as follows:

- Segregation of roles into makers and checkers:
  - **Maker** roles create intents.
  - **Checker** roles review intents and provide approvals or rejections.
- Dedicated operators by operation type (users in charge of creating transactions are different from users creating policies).
- Segregation of policies by business flow.
- Conditions defined to precisely filter a defined use case.
- Approvals defined according to the level of risk (more complex approvals for riskier operations).


## Scope of a policy

Ripple Custody includes settings to define the scope of a policy within a domain or domain hierarchy. You can use these to supervise intent execution in subdomains from a parent, and also to implement a breakglass policy.

For more information, see also [Breakglass policy](/products/custody/v1.34/get-started/design/policies/breakglass).

The scope of a policy is defined by the following two settings:

- The policy `scope` setting: Whether the policy applies to the current domain (`Self`), to the subdomains (`Descendants`), or to both (`SelfAndDescendants`).
- The domain `governingStrategy` setting: Whether a parent domain forces its subdomains to use the parent domain's policies (`CoerceDescendants`) or not (`ConsiderDescendants`).


For examples of the `governingStrategy` domain setting and the `scope` policy setting, see the request body example in [Run system setup](/products/custody/v1.34/deployment/install/installation#complete-genesis-payload-example).

### Example

This example shows how policy selection occurs in a hierarchical domain setup based on scope settings.

This example specifically applies to policy selection, not to intent execution: all selected policies must be valid and complete the associated workflow before the intent is executed.

In the following parent-child setup:

![](/assets/policy-scope.acd0e5a8fdb3f4ac33810deb3a8913cdd2030654565ff8ba55ec26cf4dc8e200.322370a9.png)

Ripple Custody applies policies, as long as they meet other requirements, such as intent and role type, to intents as follows:

| Scenario | Domain governing strategy | Policies applied |
|  --- | --- | --- |
| **Operator 1** submits intent in **Domain 1** | Any | **Domain 1**: Policy with scope `Self` or `SelfAndDescendants`.**Domain 2**: No policy. |
| **Operator 1** submits intent in **Domain 2** | **Domain 1**: Governing strategy of `CoerceDescendants` | **Domain 1**: Policy with scope `Descendants` or `SelfAndDescendants`.**Domain 2**: No policy. |
| **Operator 1** submits intent in **Domain 2** | **Domain 1**: Governing strategy of `ConsiderDescendants` | **Domain 1**: Policy with scope `Descendants` or `SelfAndDescendants`.**Domain 2**: Policy with scope `Self` or `SelfAndDescendants`. |
| **Operator 2** submits intent in **Domain 1** | Any | N/A, cannot submit intent from a child domain to a parent domain. |
| **Operator 2** submits intent in **Domain 2** | Any | **Domain 1**: If policy with scope `Descendants` or `SelfAndDescendants` exists, it's also applied.**Domain 2**: Policy with scope `Self` or `SelfAndDescendants`. |