Skip to main content
Version: 0.6

Workflow step policy

The Workflow step policy, is an optional policy, which can be provided in the Implementation manifest in an Action step. This policy can be used when:

  • an Implementation depends on another Implementation and an Interface cannot be used,
  • the Content Creator wants to prefer some Implementation in the Action steps.

This policy can be only provided by the Content Creator and cannot be changed without uploading a new Implementation manifest. Other policies can overwrite it, when a different policy has a higher priority. To check the default policy priority order see this section.


The following YAML snippet presents an Action step in the Implementation with a Workflow step policy:

- - capact-action: postgresql.install
name: install-db
capact-when: postgresql == nil
rules: # Configures the following behavior for Engine during rendering Action for this step
- interface: # Rules for Interface with exact path
path: cap.interface.database.postgresql.install
- implementationConstraints: # Enforces that the cap.implementation.bitnami.postgresql.install is selected
path: "cap.implementation.bitnami.postgresql.install"

NOTE: Instead of providing the full Interface path you can use the alias from the Interfaces imported in the Implementation:

- interfaceGroupPath: cap.interface.database.postgresql.install
alias: postgresql
- name: install
revision: 0.1.0
- - capact-action: postgresql.install
- interface: postgresql.install

NOTE: You cannot inject TypeInstances in the Workflow step policy. Manifests can be used by any Capact installation, and it is not possible to predict the ID a TypeInstance will have in a given Capact environment.

In this case the policy will enforce that the cap.implementation.bitnami.postgresql.install Implementation will be selected, if no other policy is overriding this setting.