# Parameter and Parameter Value Inheritance

In simple terms Projects have Parameters and Environments have Parameter Values. These are important concepts to grasp as we describe CloudTruth's inheritance model.

## Project and Parameter inheritance

Parameters are created at the project level where each project can have any number of child projects. The parameters created in any higher-level (parent) project will naturally be inherited by any lower-level projects (children). These inherited parameters will be references to the upper-level project parameters unless they are manually overridden.

Inheritance is always in effect until a parameter's environment values have been explicitly set. Once an environment value has been set, it no longer inherits its value from the parent project or environment as these values are static until any environment overrides have been removed.

### Overriding Project Parameters

Lower-level project parameters can be overridden in order to manipulate a parameter's environment values in a child project. Overriding a parent project's parameter explicitly attaches the parameter to the child project and exposes the ability to modify the parameter's environment values.

## Environment and Parameter Value Inheritance

Once a project parameter has been overridden we can now manipulate the parameter's environment values. Initially, each environment's parameter value will be inherited from the parent project's parameter environment values:

<figure><img src="/files/g3pn5OIbOsLTlKjt9jwd" alt="" width="563"><figcaption></figcaption></figure>

In this instance, we modified each parent project's parameter environment value. This causes an implicit inheritance from the parent project's parameter for each environment. Selecting each environment will update the Value Source indicating the value's referenced source location.

From here, we can now modify any environment value to suit our needs. Depending on the desired outcome, we can reset the inherited values to the default value or edit the environment values individually.

### Resetting all child environment values to a new 'default' value

In a child project, we can 'reset' or override the inheritance by editing the parameter's default environment value. This will update any implicitly inherited values from the parent project's environment values for each child environment and inherit the new default value. However, this only applies to those environment values in the child project which have not explicitly modified. Those values will remain the same as they are not inherited from the parameter's default value:

<figure><img src="/files/SYWl11iZQYv90WZMHX6W" alt="" width="563"><figcaption></figcaption></figure>

In the image above, we've edited the `default` environment's value resetting each child environment to inherit from the `default` environment. Notice the ValueSource has now changed from indicating the value being inherited from the parent project to now inheriting from the child project's default environment.

### Editing individual values

Selecting a non-default environment, then editing it's value will explicitly set the value for that environment and it will no longer inherit its value from the parent environment:

<figure><img src="/files/oXdKuuVRFjLg6U3gW5cf" alt="" width="563"><figcaption></figcaption></figure>

Here, we've modified and explicitly set the `development` environment's value, note how the other environments are still inheriting from the `default` environment. Any changes to the `default` environment's value will not affect the `development` environment's value.

To return an environment's value back an inheriting state, we can remove the environment override by editing the environment's value and clicking the `Remove Environment Override` button. This  will remove the overridden value where the environment will now reference its parent's environment value.

<figure><img src="/files/WTmLLgq86kwyoIyl8jFk" alt="" width="563"><figcaption></figcaption></figure>

### Editing a parent parameter's name

There may be an instance where a parent-level parameter may need be renamed. This is tricky where inheritance is concerned and comes with some items to consider:

* If the parameter is overridden in a child project, the child project's parameter becomes a new parameter at the child project's level and remains unchanged as well as the child project's descendants.
* Any child project's directly in the inheritance line will still reference the parent parameter with the new name.

Here we have an edited parameter name in a top-level parent project (note the INHERITED FROM is empty):

<figure><img src="/files/iAwDmlgJKDOR4L3DBC1I" alt="" width="563"><figcaption></figcaption></figure>

This parameter was overridden in the child project, which now displays the original parameter's name along with a new inherited reference to the modified parent parameter:

<figure><img src="/files/5CJ7wZWbwMKIF07SZIQB" alt="" width="563"><figcaption></figcaption></figure>

The original parameter has been decoupled from the parent project effectively creating a new parameter within the child project. This new child project parameter has no default or other environment values at this point. To use this parameter, new values will need to be assigned.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.cloudtruth.com/configuration-management/parameters/parameter-and-parameter-value-inheritance.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
