Monaco configuration YAML file - list of type fields

• Latest Dynatrace
• Reference
• 11-min read
• Updated on Oct 27, 2025

The type field in the configs YAML file defines the Dynatrace configuration type.

The list of type fields

api type field

The type field api can be defined as follows.

configs:
  id: [...]
  type:
    api: synthetic-monitor
  config:
    [...]

or

configs:
  id: [...]
  type: synthetic-monitor
  config:
    [...]

For more information, see supported API types.

Some of the api type configuration have a parent-child relationship with another configuration. Such a configuration requires a scope field that points to the parent configuration. Define scope as value, reference, or environment.

In the example below, a mobile application and related key-user actions are configured, and the configs id references the mobile application.

configs:
- id: mobile-application-id
  config:
    name: my-mobile-app
    template: mobile-app.json
    skip: false
  type:
    api: application-mobile
- id: MyKua
  config:
    name: myKeyUserAction
    template: kua.json
    skip: false
  type:
    api:
      name: key-user-actions-mobile
      scope:
        type: reference
        configType: application-mobile
        configId: mobile-application-id
        property: id

settings type field

The Settings API are defined by their schema, scope, and an optional schemaVersion.

The type field settings can be defined as follows.

configs:
  id: [...]
  type:
    settings:
      schema: builtin:davis.anomaly-detectors
      schemaVersion: 1.0.2
      scope: environment
  config:
    [...]

You can define the scope parameter as value, reference, or environment. Setting the scope to environment allows the creation of a settings configuration for the entire Dynatrace environment.

A Dynatrace entity has many settings made, so referencing another configs id is a useful way of configuring entities after you've created them via the Dynatrace Monaco CLI.

In the example below, a web application is configured, and then the settings for this application are made. The rum.web.enablement settings scope references the web application MyApp.

configs:
- id: MyAppId
  type:
    api: application-web
  config:
    name: My Sample Web Application
    template: application.json
    skip: false
- id: MyApp_RUMSettingsId
  type:
    settings:
      schema: builtin:rum.web.enablement
      scope:
        type: reference
        configType: application-web
        configId: MyAppId
        property: id
  config:
    name: MyApp_RUMSettings
    template: rum-settings.json
    skip: false

Another useful parameter is insertAfter. This parameter enforces a specific ordering of single Settings 2.0 objects.

In the example below, if the insertAfter is set, Dynatrace Monaco ensures the settings object is deployed:

Since Dynatrace Monaco CLI version 2.23.0+ specific Settings 2.0 objects allow the definition of a more granular permission scope to specify read or write access to single settings objects, using the permissions parameter.

The permissions parameter supports the allUser field:

An example is shown below.

configs:
  - id: security-jira-connection
    config:
      name: 'Security: Jira Connection'
      template: jira-connection.json
      skip: false
      parameters:
        […]
    type:
      settings:
        schema: app:dynatrace.jira:connection
        scope: environment
        permissions:
          allUsers: read

automation type field

Since Dynatrace Monaco CLI version 2.6.0+, the automation type is supported. The automation type configurations represent Workflows related resources.

The type field automation can be defined as follows.

type:
  automation:
    resource: workflow # or business-calendar, or scheduling-rule

The resource field specifies the desired automation resource. Each resource requires distinct OAuth permissions. For more information, see Monaco API support and access permission handling.

An example is shown below.

configs:
- id: myRemediationWorkflow
  config:
    name:
      value: ‘High Prio Incident Remediation’
    parameters:
      [...]
    template: remediationWorkflow.json
    skip: false
  type:
    automation:
      resource: workflow

To use this parameter, the OAuth client needs to have the scope automation:workflows:admin configured.

To get the scope automation:workflows:admin configured

By default, the Dynatrace Monaco CLI uses this flag when accessing the API. If it fails, the operation is repeated without the flag, but you can only access the workflow created by your own user.

bucket type field

Since Dynatrace Monaco CLI version 2.9.0+, the bucket type is supported, and it represents the configurations of the data storage management in Grail with custom Grail buckets.

The type field bucket can be defined as follows.

type: bucket

It does not require any additional fields.

An example is shown below.

configs:

# this is the new custom bucket
- id: my-bucket-id
  config:
    name: My awesome bucket
    template: bucket.json
    parameters:
      retention_days: 372
  type: bucket

# this is a new setting to define the rule what data shall be stored in the previously defined custom Grail bucket
- id: log-bucket-rule
  type:
    settings:
      schema: builtin:logmonitoring.log-buckets-rules
      scope: environment
  config:
    name: My custom rule
    template: log-bucket-rule.json
    parameters:
      phrase: My phrase to look for
      bucket:
        type: reference
        configType: bucket
        configId: my-bucket-id
        property: id

document type field

Since Dynatrace Monaco CLI version 2.15.0+, the document type is supported, and it represents the API for Dashboards and Notebooks.

Since Dynatrace Monaco CLI version 2.18.0+, the document type also represents the launchpad.

The type field document can be defined as follows.

type:
  document:
    kind: dashboard # other possible types: “notebook” or “launchpad”
    private: true # optional field specifying the visibility of the document

The optional field private specifies whether a document is not visible. If not specified otherwise, the document is public by default, which means everyone with access permissions can see it.

Depending on the user’s credentials, Monaco may not be able to redeploy all downloaded documents in certain situations. This situation happens when documents are publicly accessible, but the Monaco user does not have ownership rights. In other words, the Monaco user does not own the document. For more information on sharing documents or changing their owner, see Dashboards, Notebooks, or Launchpads.

For more information, see Configuration as code sample repo

openpipeline type field

deprecated

Since Dynatrace Monaco CLI version 2.15.0+, the openpipeline type is supported. openpipeline configuration manages the data ingestion and processing of data from different sources.

The type field openpipeline can be defined as follows.

type:
  openpipeline:
    kind: bizevents # id of openpipeline configuration (for example, "bizevents", "events", "logs", "spans", or "metrics")

The kind field specifies the id of a pre-existing openpipeline configuration. Monaco can retrieve and update configurations, but can't create or delete new ones.

segment type field

Since Dynatrace Monaco CLI version 2.19.0+, the segment type is supported. Segments are used to structure and filter data for tailored views in Dynatrace.

The type field segment can be defined as follows.

type: segment

It does not require further fields, but can be referenced in other configurations to filter visualized data accordingly.

An example is shown below.

configs:

- id: segment                # configures the desired segment
  type: segment
  config:
    template: segment.json

- id: dashboard              # creates a dashboard that references a segment
  type:
    document:
      kind: dashboard
      private: true
  config:
    name: Log Dashboard with Dynatrace Segment
    parameters:
      segment_id:            # references the previously created segment within a dashboard
        configId: segment
        configType: segment
        property: id
        type: reference
    template: dashboard.json

slo-v2 (Service-level objective) type field

Since Dynatrace Monaco CLI version 2.22.0+, the slo-v2 type is supported.

Configure and monitor service-level objectives with Dynatrace, based on Grail and utilizing DQL are managed via the type slo-v2.

The type field slo-v2 can be defined as follows.

type: slo-v2

This type does not require additional fields.

An example is shown below.

configs:
- id: custom-sli          # An SLO based using a custom DQL query as SLI
  type: slo-v2
  config:
    name: custom-sli
    template: custom-sli.json

- id: sli-reference       # another SLO using an out-of-the-box template (aka reference)
  type: slo-v2
  config:
    name: sli-reference
    template: sli-reference.json

accounts

To define the accounts for which Monaco configures Account Management resources, you need to create an accounts section in the configuration file.

The following example defines a single accounts object containing account-related information. The name property specifies the account name, my-account, which can be referenced using the Monaco CLI command's --account flag.

accounts:
- name: my-account
  accountUUID: 12345678-1234-5678-1234-123456789012
  oAuth:
    clientId:
      name: OAUTH_CLIENT_ID
    clientSecret:
      name: OAUTH_CLIENT_SECRET

Account resources

Using Monaco, you can define users, service users, groups, and policies as dedicated types.

Account-level configuration is usually distinct from environment-level configuration. It changes less frequently; existing commands like monaco deploy ignore any account configuration that may be defined in a manifest file.

A dedicated monaco account deploy command needs to be used instead.

The example shows how Monaco represents account management resources locally, with examples defining users, service users, groups, and policies.

users: # users define one or more users bound to different groups
- email: monaco@dynatrace.com
  groups:
  - Log viewer # default group
  - type: reference
    id: my-group
    # id: specifies a custom group. The ID must match a group defined in groups. Custom groups need to be referenced (vs. default groups)

serviceUsers:     # supported with Monaco CLI v2.23.0+
- name: Monaco service user # name: must be unique. Otherwise, an originObjectId is needed
  description: Description of service user
  originObjectId: 3037325d-6475-4adf-a14d-93d1c862f9e9 # (optional) only needed if the user’s name is not unique
  groups:
  - Log viewer # default group
  - type: reference # custom group my-group needs to be referenced
    id: my-group

groups:
- name: My Group
  id: my-group
  description: This is my group

  account: # specifies permissions and policies to which the group is bound on the account level.
    permissions:
    - account-viewer
    policies:
    - policy: Environment role - Access environment

  environments: # specify the permissions and policies to which the group is bound on the environment/tenant level.
  - name: abc12345
    permissions:
    - tenant-viewer
    policies:
    - policy: Environment role - Replay session data without masking
    - type: reference
      id: my-policy

  managementZones: # classic Dynatrace only
  - environment: abc12345
    managementZone: Management Zone 2000
    permissions:
    - tenant-viewer

policies: # defines one or more policies for the selected group
- name: My Policy
  id: my-policy
  level:
    type: account
  description: abcde
  policy: |- # contains any policy rules of this particular policy.
    ALLOW automation:workflows:read;