|Action Block(s)||Action Blocks 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. 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 are graphical scripts that allow users to automate complex tasks with ease. The scripts are made up of Action Blocks which can be dragged into place and are configured for integrations. For more information, see the Workflows page.|
|Workflow Actions||Workflow Actions are actions one can perform on a Workflow. A Pliant user does this by clicking the three vertical dots under the "Actions" column of the "Workflows" tab on the row of a workflow. From here, one can open (invoke workflow editor view), start (execute), export (download), clone (copy), rename, or delete a workflow.|
This is the editor interface for using Action Blocks in a logical sequence to create a workflow.
|Flow Layout||This is a view in the Workflow Editor that shows the workflow as a flowchart.|
|Sequence Layout||This is a view in the Workflow Editor that shows the workflow as a linear sequence of blocks.|
|User Flow, User Block||An Action Block that consists of another 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.
|Integration Package||A compressed/zip file containing definitions for Action Blocks and Authentication Key types that can be imported into the Pliant Integration Repository|
|Integration Library||A section of the Pliant Support Portal where a user can download Integration Packages|
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.
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.
|Dashboard||The Dashboard is the first view upon entering the platform. It is also accessible via the "Dashboard" tab and the Pliant logo.|
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.
|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 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.