Workflows

This is the editor interface for using Action Blocks in a logical sequence to create a workflow.

A Pliant instance is a single installation of the Pliant platform. This instance can live in the cloud (public or private) or 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. 

This comprises the list of all the integrations loaded into the Pliant platform. This contains 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 that 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. 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.

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 can be accessed through the Event Processor.

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

Job Actions are actions one can perform on a Job. A Pliant user does this 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.

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.

Folders allow users to group workflows together on the platform.

Folder actions are different actions one can perform on a folder. A Pliant user does this 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 dictate the actions each user is allowed to take in your particular instance of Pliant. For more information, see the Roles Management New page.

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).

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

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.

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 this is reached, they will be required to log in once again for security.

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.

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 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.

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.

(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.