> For the complete documentation index, see [llms.txt](https://academy.any2info.com/any2info-academy/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.any2info.com/any2info-academy/no-code-platform/app-studio/application-design/forms/supporting-footer-tools/workflow.md).

# Workflow

**Category:** Footer

**Version:** 1.0

**Last updated:** May 21, 2026

**Author**: Any2Info

***

### Description

The Workflow Footer is a mini designer that is only available in the **Forms Designer**.

It is used to create, edit, and delete **workflow definitions**. Workflow definitions are exclusively used by **workflow fields**.

A workflow definition is based on an existing **state list definition** created through the **States Footer**. The workflow uses the states from that state list to define workflow progression and to apply the corresponding internal state behavior of each selected state item.

This allows workflows to combine:

* Visual workflow progression
* State management
* User assignment
* Workflow transitions
* Internal message locking/editing behavior

***

### Workflow Structure

A workflow definition consists of multiple **workflow steps**.

Each workflow step contains:

* A translated display value using a **display text**
* A linked state from the selected state list definition

The linked state determines the underlying internal behavior of the workflow step through the selected state item's internal state value.

***

### Workflow Actions

Each workflow step supports three different actions:

| Action   | Description                                                                               |
| -------- | ----------------------------------------------------------------------------------------- |
| Complete | Moves the workflow to another workflow step.                                              |
| Reject   | Moves the workflow to another workflow step, typically backwards or to a rejection state. |
| Assign   | Assigns users without changing the current workflow step.                                 |

***

### User Assignment

Each workflow action supports user assignment configuration.

Depending on the selected assignment type, users can automatically be assigned during workflow execution.

Most assignment types optionally support notifications to newly assigned users.

***

### Assignment Types

#### Default User

Assigns the workflow action to a single predefined user.

***

#### User From Authorization

Assigned users are determined through users configured in groups within the **Authorization Structures** module.

For more information, refer to the Authorization Structures documentation.

This assignment mode supports the option **Chosen by user**.

When enabled:

* The user performing the transition may manually select one or more users during the workflow transition.

When disabled:

* All users contained in the configured authorization groups are automatically assigned.

***

#### Users From Ancestors

Assigns users that are hierarchically positioned above the current user within the Authorization Structures hierarchy.

This assignment type also supports **Chosen by user**.

When enabled:

* The transitioning user may select one or more ancestor users manually.

When disabled:

* All applicable ancestor users are automatically assigned.

***

#### Users From History

Assigns users that have previously been assigned to the current form message during earlier workflow steps.

This assignment type also supports **Chosen by user**.

When enabled:

* The transitioning user may manually select users from the assignment history.

When disabled:

* All previously assigned users are automatically assigned.

***

#### Back Last

Reassigns the previously assigned user.

This is commonly used for returning workflow items to the last responsible user.

***

#### Back To Creator

Assigns the original creator of the form message.

This is commonly used when workflows need to return to the requester or initial submitter.

***

### State Integration

Workflow definitions rely on state lists from the **States Footer**.

Each workflow step references a state item from the selected state list definition. This allows the workflow to use the internal state behavior defined by that state item.

Examples:

* Open
* Closed
* Closed for user

The internal state ultimately determines whether a message remains editable or becomes locked.

***

### Usage

Workflow definitions are exclusively used by **workflow fields**.

Typical use cases include:

* Approval workflows
* Review processes
* Task assignment flows
* Escalation procedures
* Quality control processes

***

### Notes

* Workflow definitions cannot exist without a linked state list definition.
* Workflow fields are the only field type capable of using workflow definitions.
* Assign actions do not change the current workflow step.
* Complete and Reject actions always transition to another workflow step.
* Workflow assignments can optionally trigger notifications to newly assigned users.
* User assignment behavior depends on the configured assignment type and authorization structure.

***

### Changelog

| Version | Date         | Change                               |
| ------- | ------------ | ------------------------------------ |
| 1.0     | May 21, 2026 | Initial documentation version added. |


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://academy.any2info.com/any2info-academy/no-code-platform/app-studio/application-design/forms/supporting-footer-tools/workflow.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
