Glossary



TermDescription
Action Block(s)Workflows are made up of Action Blocks, which are blocks users can click and drag into place to build workflows. Action Blocks can be the first action of a workflow, the final action, or somewhere in between among other action blocks. There are numerous blocks available for different purposes, and Action Blocks generally make API calls and are available for the entire Integration Repository. From the Workflow Editor screen (accessible by either clicking on an existing workflow or creating a new workflow), the available action blocks are displayed on the right of the page.

Workflows

Workflows are graphical scripts which allow users to automate complex tasks with ease. The scripts are made up of blocks called Action Blocks, which can be dragged into place and are configured for integrations. For more information, see the Workflows page.
Workflow ActionsWorkflow actions are different actions one can perform on a workflow by clicking the three vertical dots under the "Actions" column of the Workflows tab on the row of a workflow from the Pliant Platform. From here, one can open (invoke workflow editor view), start (execute), export (download), clone (copy), rename, or delete a workflow.
Workflow Editor

This drives the user experience allowing him or her to use Action Blocks in a logical sequence to create a workflow.

Instance(s)

A Pliant instance is a single installation of the Pliant platform. This instance can live in the cloud (public or private) or also on-premise when required. A Pliant instance can consist of a number of separate Kubernetes pods and nodes but will run under the same license and have a single set of configuration data. 

Integration Repository

This comprises the list of all the integrations loaded into the Pliant platform. These contain the API calls (or other methods) which Pliant uses to interact with the asset. Each integration in the repository has its own list of Action Blocks, which can be used to build a workflow.

Real-Time Execution Engine,

Worker,  

Remote Worker

Compiles the code created by the user in the workflow and then makes the appropriate API calls. Since this is the “working” engine of the Platform container that is most often replicated to handle scale. A single instance can compile and execute about 3500 API calls per second. Pliant can scale containers to meet any size automation.

Event Processor

Allows Pliant to receive inbound information and then take automated action. This provides customers with closed-loop automation capabilities. In addition, every workflow that is created on the Platform becomes its own RESTful API which is accessed through the Event Processor.

Jobs

Jobs are workflows scheduled to run automatically. They are available for view and edit in the "Jobs" tab at the top of the page.

Jobs Actions

Job Actions are available by clicking the three vertical dots under the "Actions" column of the "Jobs" tab. From here, one can edit a job or delete a job. Creating a job is accomplished by clicking "+ Create" on the top right of the page.

Job State

The "State" column on the Jobs New tab allows users to enable or disable jobs. A job switched toward the "Enabled" position will run, while a job switched away from the "Enabled" position will not run.

Folder

Folders enable users to group workflows together on the platform.

Folder Actions

Folder actions are different actions one can perform on a folder by clicking the three vertical dots under the "Actions" column of the workflows tab on the row of a folder, NOT a workflow. From here, one can open a folder to view its contents (child folders and workflows), export (download the folder), or delete the folder.

Roles

Roles are defined for each user dictating what actions they are allowed to take in your particular instance of Pliant. For more information, see the Roles Management New page.

DashboardThe Dashboard is the first view upon entering the platform. It is also accessible via the "Dashboard" tab and the Pliant logo.
Logs

Past executed workflows are logged in Logs. This also tells whether the workflow executed successfully (resulting in a Successful Log Entry) or if the workflow failed on execution (resulting in a Failed Log Entry).

Filter

Filtering allows users to easily find a particular workflow, log or job. Users can "search" for the name of a particular Job, Log or Workflow instead of parsing through several pages.

Permissions

Permissions dictate the actions a user is allowed to take e.g. what workflows they may execute, which action blocks they have access to, etc.

Users

A User is assigned a username, first name, last name, and a password. They may use their credentials to log into a Pliant instance. Users have roles which determine what they are allowed to do within their Pliant instance. Users also have a specific timeout period, and when reached, they will be required to log in once again for security.

Successful Log Entry

A log entry generated after a workflow executes successfully. These successful workflow executions will have a checkmark (✓) in the first column titled "Success" on the "Logs" tab.

Failed Log Entry

A log entry generated after a workflow fails in execution. These failed workflow executions will have an "X" in the first column titled "Success" on the "Logs" tab.

Integrations

Integrations are functionalities provided by users of the Pliant system in the form of action blocks. Users can utilize these integrations and API's by dragging and building workflows from action blocks.

High Availability

Maintaining uptime in the event of a host failure. Pliant High Availability consists of a Highly Available Kubernetes cluster comprising a minimum of 3 master nodes located in 2 or more physical locations with a network that has <10ms latency between any two points. This model allows for rapid and automatic recovery from any single node failure, and continuous operation of Pliant at your site.

Disaster Recovery

(Also called site recovery) The purposeful failover from the main site to a recovery site. Pliant DR assumes that there is a primary Pliant instance running as a highly available Kubernetes cluster. In a DR scenario, another identical cluster is configured in a remote location, and the primary cluster can automatically replicate its data to a read-only copy in the backup cluster. In the event of a disaster, the backup cluster can be promoted to active status and take over all functions of the deceased cluster.