> For the complete documentation index, see [llms.txt](https://docs.akamas.io/akamas-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akamas.io/akamas-docs/3.5.0/reference/construct-templates/using-workflows.md).

# Workflows template

Workflow are defined using a YAML manifest with the following structure:

```yaml
name: "insert_workflow_name_here"
tasks:
# these are the tasks that will be executed sequentially to complete a trial (configure the system under tests with the parameters optimized by Akamas )
- name: "insert_here_name_of_task"
  # an operator specifies which type of task should be used
  operator: "insert_here_which_operator_to_use_for_the_task"
  # each operator accepts different arguments necessary to specify how it should behave
  arguments:
	...
```

with the following properties:

| Name                    | Type    | Value Restrictions            | Required | Default | Description                                                                        |
| ----------------------- | ------- | ----------------------------- | -------- | ------- | ---------------------------------------------------------------------------------- |
| name                    | string  | -                             | yes      | -       | The name of the task.                                                              |
| operator                | string  | -                             | yes      | -       | The operator the task implements: the chosen operator affects available arguments. |
| critical                | boolean | -                             | no       | `true`  | When set to true, task failure will determine workflow failure.                    |
| alwaysRun               | boolean | -                             | no       | `false` | When set to true, task will be executed regardless of workflow failure.            |
| collectMetricsOnFailure | boolean | -                             | no       | `false` | When set to true, failure of the task will not prevent metrics collection.         |
| arguments               | list    | Determined by operator choice | yes      | -       | Arguments list required by operators to run.                                       |

The full list of Operators and related options is provided on the [Workflow Operators](/akamas-docs/3.5.0/reference/workflow-operators.md) pages.

### Example

A workflow for the java-based renaissance benchmark application

```yaml
name: renaissance-optimize

tasks:
- name: Configure Benchmark
  operator: FileConfigurator
  arguments:
    source:
      hostname: benchmark
      username: akamas
      password: akamas
      path: launch_benchmark.sh.templ
    target:
      hostname: benchmark
      username: akamas
      password: akamas
      path: launch_benchmark.sh

- name: Launch Benchmark
  operator: Executor
  arguments:
    command: "bash launch_benchmark.sh"
    host:
      hostname: benchmark
      username: akamas
      password: akamas

- name: Parse Output
  operator: Executor
  arguments:
    command: "bash parse_output.sh"
    host:
      hostname: benchmark
      username: akamas
      password: akamas
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

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

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.akamas.io/akamas-docs/3.5.0/reference/construct-templates/using-workflows.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.