States and Transition: The building blocks of Workflows are states

and transitions between states. A state instantiates and acts upon actions that are meant to happen at a certain point in a Workflow.

A transition defines a trigger that executes the transition, and a target

state. Your transition will occur according to the trigger you have

defined, and it will progress the workflow to the next state (or step) in

your business process.

A Vault Workflow is a finite state machine and can be represented as graph.

Actions, Tickets and Tasks:

Workflows drive behavior using actions. Actions can take place before,

during, or after a state, or during a transition, for example:

Calling external services outside of Vault

Call public APIs within the Vault system

Creating new Tasks and Workflows for human interaction

Tickets and Tasks are raised when human interaction is required to

advance or terminate a Workflow

User Interface Generation: Values and configurations defined in a

Workflow can be presented in the Operations Dashboard using

predefined components called UI panels. A back-office user can then

use these UI panels to view information.

Notes :

Humans can interact with Workflows using Tasks

Workflows can be deployed using Configuration Layer Utility, Ops Dashboard and API

Workflows cannot be migrated, we will have to create a new workflow during the implementation

There are two flavours of Step functions, with different characteristics and costs:

Standard: can run ( or be idle ) for up to 1 year, employ an exactly-once model, where your tasks and states are never run more than once (unless a Retry is specified in your ASL), and are best suit to suited to orchestrating non-idempotent actions, you pay by number of state transitions ( not the duration, that as we said, can be up to 1 year!)

Express : can run up to five minutes, are billed by the number of executions, the duration of execution, and the memory consumed and employ an at-least-once model, where an execution could potentially run more than once - making them ideal for orchestrating idempotent actions (high-volume, event-processing workloads such as IoT data ingestion, streaming data processing and transformation, and mobile application backends