FlowWright's workflow designer is a fully graphical web based designer for designing workflow definitions. The workflow designer is in its 3rd generation, and is built using the latest technologies such as HTML5 for powerful features and performance. v9.5 of FlowWright completely changed the underlying graphics library to provide many new enhancements and features.
Our users are using FlowWright to process over 1 Million+ workflows daily around the globe, today's processes will not be efficient tomorrow and here's why.
As many Enterprise organizations implement Micro-services, they either have non-working or satisfactory implementations of Micro services. This is a trend we have seen the last 2 years within our customer base. What companies are truly looking for is a workflow solution to re-architect their Micro-services architecture/solution.
Even though EDI is a very old file format, specially in the medical payment transaction processing industry, it's a very commonly used format. The healthcare industry has yet to move to newer technology as XML or JSON, therefore still uses EDI files.
FlowWright engines are architected as worker processes or robotic workers that perform work for workflow processes. Whether the engine is processing workflows, forms, ESB events, they are all processed by robotic workers. Robotic workers are designed for performance, but they are also able to return all resources used by the worker such as CPU, RAM any other resources back to the Operating System (OS).
FlowWright Forms are very common within the workflow processes. Forms are meant to be routed to display information or capture information from a user. But, did you know Forms also can have decision logic, validation or business logic built into the form itself? We explain why that is important below.
Just like physical engines, software engines today perform most of the heavy lifting within a software application. Software engines are typically running on a server, consuming many resources, spawning many threads, processes and executing code to perform functionality for the end user. We discuss the type of engines below in greater detail, and what you need to know.
Documenting your business processes is just as important as actually applying automation to your processes. There are several reasons why you should always document what your team is doing when creating and editing processes; we summarize some things to consider below.
Sub-workflows or sub-processes are key part of any workflow process. Instead of ending with very large processes, you should always break them down to smaller chunks and make sub-processes to ensure things remain clean. We explain why this is an important step.
As you may know, you can build custom steps to do anything that you want them to do, and use them within workflows. Many of our customers build custom steps to perform certain functionality within workflows, but what about the validation of these step inputs? We explain how it works here.
