# Hierarchy and Inheritance Best Practices

Lifecycle uses a hierarchy model of organizations and applications for configuration management. Configuration is set at the highest required level and inherited downwards.

## Lifecycle Hierarchy Model

| Level | Details |
| --- | --- |
| Root Organization | - default level for reference policies<br>  <br>- can be renamed to your organization<br>  <br>- uses the static ROOT_ORGANIZATION_ID through the API |
| Repositories<br>(Sonatype Firewall) | - container for connect Sonatype Firewall proxy reports<br>  <br>- only for Sonatype Firewall users |
| Organization | - container used to organize application<br>  <br>- free form naming can use prefixes and suffixes<br>  <br>- an internal organization id is set when created<br>  <br>- the "Sandbox Organization" is created by default |
| Application | - a scan point for analysis and reporting<br>  <br>- created with a custom PublicID for scripting and scanning<br>  <br>- free form naming may include version numbers |

The following table displays common considerations for organizing your application hierarchy model. The top three (highlighted in yellow) are the most common.

| Use case | Details |
| --- | --- |
| User access control | - applications by business units to mirror directory service groups<br>  <br>- access is granted, not revoked |
| Policy differentiation | - applications with shared enforcement requirements<br>  <br>- ie. separating legacy from active development<br>  <br>- ie. enable enforcement for critical applications |
| Regulatory requirement | - sensitive applications which need to remain isolated<br>  <br>- deprecated applications where the component data needs to be retained |
| Shared configuration | - common SCM, grandfathering*, reporting, and monitoring configuration<br>  <br>* As part of our inclusive language initiatives, we have renamed this feature to Legacy Violations starting with release 167. |
| Reporting grouping | - grouping applications together that need to be in a shared report |
| Micro-service architecture | - individual microservices built as an overall application |
| Application versioning | - monitoring multiple active application versions in development and production |

Start with an inventory of your applications

- create a spreadsheet of your applications to align with your hierarchy considerations.
- use existing naming as much as possible to help with automation in your build environment.
- The application PublicID should match your build environment variables.
- Renaming and moving applications after they have been created is very time-consuming.
- Use application categories to flag applications with common policy considerations.

### Avoid using a complicated hierarchy

- Start with only the considerations that are most important. Keep it simple.
- Avoid overly complicated configurations as that often does not provide any value and will not scale.
- Avoid creating busy work that does not provide value

### Policies are inherited, they cannot be revoked

- Policies will apply to all applications below where they are created.
- When a policy applies to a subset of the applications, consider using application categories.

### Pilot enforcement using policy action overrides

- Enabled enforcement for the entire enterprise is not always appropriate.
- Using policy action overrides allows you to start enforcing policy actions for a subset of applications.
- Set the overrides on the organization level for all the applications under them.

### Scope policies to an application category when they apply to only a subset of applications

- Keep policies scoped to an application category at the root organization level.

### Create policies at the organization or application level when needing a unique requirement

- Setting policies on an organization or application level doesn't scale over the long run.
- They can lead to duplicative policies and gaps in policy coverage while being confusing to manage.
- Typically, architecture policies only apply to a single organization group.
- Use application categories to scope policies set at the root organization level when you need a different policy for only some applications.

### Using organizations for maintenance tasks

- Organizations may be used as a grouping for mixed maintenance purposes.
  - To_Review → when an application was onboarded to automatic app creation
  - Archive → for when an application is not being scanned but you need to retain the report

### Using organization prefixes for sorting

- The following special characters can be used in organization names to sort them to the top.
  - hyphen (-), period (.), and underscore (_)
  - You may also use a space however, beginning spaces are ignored and not included.
  - You can use something like 'zzz_' to sort the organization to the bottom.
- Keep sub-organizations together using a common prefix.