Flows
Flows
Introduction
With Flows, your instance can have multiple workflows, or flows, which are made of blocks that represent essential parts of the data-extraction process. In addition to Classification, Identification, and Transcription Blocks, you can work with various functionalities.
Flow Blocks
With the introduction of flows, we have created the following types of blocks to help you customize your flows to meet your teams’ needs. To learn more about any of these blocks, or for assistance in adding them to your flows, contact your Hyperscience representative.
Modifying Custom Code Blocks
Not available in SaaS instances You cannot modify Custom Code Blocks in SaaS instances of Hyperscience. Contact your Hyperscience representative for assistance. To give you more flexibility in your implementation of Hyperscience, we introduced additional customization options.
Flow Settings
As part of our efforts to give you more precise control over your Hyperscience processes, we’ve made many of our settings configurable on the flow level. You can access these settings by clicking on Flows in the left-hand sidebar.
Managing Flows
The sections below describe how you can manage flows in your instance of Hyperscience. Note that you may need Hyperscience’s assistance to complete some of these tasks.
Connecting Flow Blocks to Other Flows
While there are many ways to customize individual flows, you may also want to configure custom behavior outside of a flow for submissions processed through certain blocks. For example, you may need to send submissions' state-change information to your other applications.
Testing and Debugging Flows
With our testing and debugging tools, you can see more information about why a particular submission failed. You can also learn more about how flows are constructed and use what you've learned to build and test your own flows with our Flows SDK.
Flow Runs Page
When a submission is processed in Hyperscience, its flow-execution information can be viewed in the Hyperscience application. This information can be used to determine why the number of submissions ingested is greater than the number of submissions expected.
Defining Automatic Block-Retry Policies
In order for a submission’s processing to be completed, each block in its flow must finish its task successfully. If a block fails, the submission becomes halted, which may cause the submission to breach its SLA. When you define automatic retry policies, you enhance the reliability of your submission processes.
Document Processing Flow in V39
In v39, the new Document Processing flow included in the instance differs from the one included in previous versions. Specifically, it's a flow group rather than a single flow. For more information about flow groups, see Connecting Flows to Other Flows.
On-Error Flows
When a failing submission has exhausted all of its flow blocks’ retry attempts, it will have a Halted status and a Failed flow run. To alert members of your organization of the Failed flow run, you can choose an on-error flow for each of your flow configurations.