Workflow automation

Easy-to-use visual workflow automation system. With Automation Flows, you can spend less time customizing integrations. Create tasks, connect services and save your valuable time.

Automation Flow Module is a workflow engine together with a web user interface that allows you to create business processes in an easy-to-use drag&drop UI without writing a single line of code.

What is the Automation Flow Engine?

Automation Flow is an API workflow automation application. It allows you to use APIs, connect them together and create simple or sophisticated business logic visually and without having to deal with all the API complexities.

Use Automation Flow Engine to:

  • automate your workflows
  • enhance your web and mobile apps with cloud APIs
  • create & embed IVRs and other voice and SMS apps
  • power your apps and workflows with AI
  • move and transform data between cloud apps
  • prototype new business ideas

Example of a Lead Prospecting Flow


Example of an IVR Flow

The Automation Flow Engine provides features that are critical to workflow applications:

  • Error handling. Errors are handled gracefully, logged and actions repeated when possible.
  • Message-passing. Data messages are delivered once and only once between connected components in a workflow.
  • Custom components. Components in a workflow are seen as black-boxes by the engine and their behaviour can be completely customized (they can call either external APIs, internal APIs, do some processing or scheduling).
  • Quotas and Limits. Automation Flow Engine can throttle the processing of components to make sure API usage limits are respected.
  • Authentication. Automation Flow Engine supports industry standards for authentication out-of-the-box (API keys, OAuth 1, OAuth 2). All tokens are automatically refreshed when necessary.
  • Monitoring. All transactions and data passing through Automation Flow Engine are logged. Get real-time insight into all activities.

What is a flow?

A flow represents a business process that reacts to events, transforms incoming data, makes decisions, performs actions, stores data and/or loads data to external systems.



For example, a flow can represent a process that sends an SMS to a user, waits for their reply, checks the sentiment of the user's message and creates a ticket in your online ticketing support system if the answer is negative.

Flows is designed in the Automation Flow Engine drag&drop visual Flow designer on the SnatchBot platform.


Example of a Sentiment Analyse Flow, with alert on Slack.

What is a Component?

Components are the building blocks of the Automation Flow Engine. Each component in a flow reacts to incoming messages, processes them and produces outgoing messages. User can wire components together to define complex behaviour and workflows. Usually, components call external APIs but they can also do some internal processing, logic or scheduling.



Take the example above. There are three components in the flow. The first one (Timer) we call a trigger because it does not have any input ports and so the component generates outgoing messages based on its internal logic. In our case, the Timer component sends messages to its output port out in regular intervals that the user can specify in the UI. As soon as a message leaves an output port, it travels through all the connected links to input ports of other connected components. In our scenario, when a message leaves the out port of our Timer, it goes to the location input port of the GetCurrentWeather component. As soon as the GetCurrentWeather component receives a message on its input port, it starts processing it. In this case, it requests current weather information from the API. Once a response is received from the API, the component continues to send the result to its output port weather.



Note that the location for which we're requesting the current weather can be specified by the user in the UI. The process then repeats for all the other connected components until no message is generated on an output port or there is no other component connected.

Note that the location for which we're requesting the current weather can be specified by the user in the UI. The process then repeats for all the other connected components until no message is generated on an output port or there is no other component connected.


Inspector panel

To make our example flow complete, it is important to note that any component can be configured using data generated on output ports of any component back in the chain of connected components. In our example, our SendChannelMessage component sends a message on Slack channel #qa-messages with text containing the city, humidity, pressure and temperature as it was received from the weather API. The user configures the flow in the designer UI simply by selecting placeholders (variables in the SnatchBot Automation Flow engine jargon) that will eventually be replaced when the flow goes to the running state and the actual data is available.

Components have some important properties that we should mention before diving into the details:

  • Components don't know about each other. All components are totally independent and loosely coupled. They only react to incoming messages and produce outgoing messages. The linkage between components is not internal to the components themselves but rather a mechanism of the Automation Flow Module and its protocol.

  • Components are black-boxes to the Automation Flow Module. The module does not know and also does not need to know what components internally do and how they are implemented. It only wires them together through ports and makes sure messages are always delivered and in the right order.

Component Definition

Components in Automation Flow Engine are structured into "services", "modules" and "components" hierarchy. Each service can have multiple modules and each module can have multiple components. For example, "Google" service can have "Gmail", "calendar" or "spreadsheets" modules and the "Gmail" module can have "SendEmail", "NewEmail" and other components:


Services, modules and components hierarchy

This hierarchy is reflected in the directory structure of component definitions. Typically, services and modules are structured in two ways. Either the service itself appears as an "app" in Automation Flow Engine or modules are separate apps.

For example, in the case of Google, we have separate apps for each module (GMail, Calendar, Analytics, ...):


But in the case of Twilio, we want to have one app and all the actions/triggers as different components of the Twilio app:


Component View

Fields available are:

nameName of the app Provider.
labelThe label of the app Provider.
categoryBy default, components shipped have divided into two categories "applications" and "utilities".
descriptionDescription of the app Provider.
iconApp icon of the app Provider.

Fields meaning

Description of your component

The description is displayed in the Designer UI inspector panel like this:


Component Description

Next Steps

Manage 3rd party accounts connected anywhere in your flows.