# Document-MailEditor

## Basic configuration

The configuration must start with a version specification. You specify the version like this:

```yaml
version: 1.0
```

### Save and Send

You can specify a workflow which should be executed if a user presses the action `Save and Send` within the Mail Editor. If a workflow is specified, the `Save and Send` action will be visible for the user, otherwise the user won't see the action.

For each document class within your application, you can specify a separate workflow. A configuration looks like this

```yaml
version: 1.0
config: 
- class: Document
  sendWorkflow: Test
```

The config contains a list of elements, each of them starting with the `class` specification.&#x20;

* `class`: with this option you define which class you want to configure the workflow for. The value is the key of the class.
* `sendWorkflow`: this value specifies the workflow which executes the send process. You specify the workflow by entering the workflow key.

{% hint style="info" %}
You can specify more than one class in the configuration.&#x20;
{% endhint %}

## Application Hierarchy

If you have an application hierarchy, all configurations are evaluated. The priority is always:&#x20;

1. Current Application
2. Parent Application
3. Parent Parent Application
4. ....

### Examples

* You are in the application `App1`, which is a child of the application `AppParent`
* You have two workflows, `Workflow1` and `Workflow2`, both living in `AppParent`
* In `AppParent`, you have specified that `Workflow1` is used for your document class `Documents`

#### Overwriting the specified workflow

To use `Workflow2` in your App `App1`, you simply add a configuration inside `App1`saying that `Workflow2`is the sendWorkflow for your document class. If a user now uses your app, `Workflow2` is used. If a user uses `AppParent` directly, the application will use `Workflow1` as the sendWorkflow

#### Un-setting the workflow

If you don't want to use any sendWorkflow for your document class, you simply add a configuration inside `App1` , add your document class and don't specify any workflow. This would look like this:

```yaml
version: 1.0
config:
- class: Document
```

With this setting, you are removing the configuration any parent app might have specified before.&#x20;

#### Use the same workflow

If you don't want to overwrite the configuration, simply don't add an entry with the corresponding class key.


---

# 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.tivity.one/building-an-application/application-setup/advanced-settings/document-maileditor.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.
