# Action input parameters

> How Cloud Management Platform (CMP) discovers the values an action needs, and how to shape them

---

Site [llms.txt](/llms.txt)

---

CMP scans the actions you define to determine whether the action needs additional input in order to run. This process is covered in more detail in the documentation for each [action type](/docs/cmp/use/orchestration/actions/action-types/). CMP then prompts users for those inputs, or substitutes pre-designated default values where appropriate.

CMP does not create action inputs for template variables that start with the keyword server, such as **{{ server.ip }}**. For the full list of context keys, see [Action context](/docs/cmp/use/orchestration/actions/action-context/).

Administrators can customize the automatically discovered input parameters, assigning each one a label, description, type, dependencies, and validation constraints. For CMP plugins, input parameter options can also be defined in plugin methods, as described in [Plugin parameterization](/docs/cmp/use/orchestration/plugins/parameterization/).

Action inputs can reference other CMP objects. For example, if you have a post-provision action that adds a server to a load balancer or a backup schedule by hostname, define the default for the *hostname* input parameter as **{{server.hostname}}**.

## Blueprint action context

When an action runs as part of a blueprint deployment, the entire deployment is available to the action context. If a database server is being built by a build item named DB, reference the context of that item in any action by setting an input parameter value to something like **{{blueprint_context.db.server.ip}}**.

Build item names are converted to lowercase; spaces and hyphens are replaced with underscores; other non-alphanumeric characters are removed; and leading and trailing whitespace is stripped.

### Action build item context

A key/value pair mapping the action inputs to the values to use on a given execution.

<div class="alert alert-info" role="alert">


Use double quotes, especially when identifying an action input value, for example `"test"`.
</div>


### Provision server build item context

- **quantity**: The number of servers this item will create.
- **os_build**: The CMP object for the OS build being used to provision the servers.
- **applications**: References to the CMP objects for all applications included in the provisioning.
- **servers**: References to the Server objects being provisioned in this item.
- **server**: A shortcut available when only one server is being provisioned.
- **\<parameter_name\>** for each parameter on the item: The value that will be used for the parameter.
- **\<preconfig_name\>** for each preconfiguration on the item: The value that will be used for the preconfiguration.

### Pod build item context

- **images**: A comma-delimited string of images to install in the container.
- **environments**: The environments selected for the pod build item.

### Load balancer build item context

- **source_port**: The source port that will be used.
- **destination_port**: The destination port that will be used.

### Sub-blueprint build item context

The sub-blueprint context includes everything that would have been available in *blueprint_context* had the sub-blueprint been ordered on its own. If a user orders a blueprint containing a sub-blueprint called Web Tier, which itself contains a server tier and an action, the resulting blueprint_context looks something like this:

```python
{
   "web_tier": {
      "resource_name": "<sub-blueprint resource name>",
      "<sub-blueprint server tier name>": {
          "servers": ["server1", "server2"],
      },
      "<sub-blueprint action name>": {
          "action input 1": "value 1",
          "action input 2": "value 2",
      }
   }
}
```

## Related

- [Action context](/docs/cmp/use/orchestration/actions/action-context/)
- [Plugin parameterization](/docs/cmp/use/orchestration/plugins/parameterization/)
- [Blueprint actions](/docs/cmp/use/blueprints/build/blueprint-actions/)