An example of the way one customer uses embedded FlowWright: one of our oldest customers makes software that automates the receipt and processing of prescriptions at high-volume warehouse pharmacies. These prescriptions need to be scanned, undergo OCR processing, be validated, and then processed according to rules based on the prescription data. Instead of hard-coding prescription use cases that can vary widely, our customer integrated FlowWright to take advantage of high level graphical designed and execution capabilities workflow. The use cases and resulting workflows and decision logic were implemented in a tiny fraction of the time product development methodologies dictated - and result in auditable execution data that can inform rapid modification of business processes for each customer, as needed.
3 Considerations when Embedding FlowWright into your Software
So, how do you embed our workflow product into your software? 
- Analyze: what processes do you want to automate? what forms or objects are created, used, modified, or destroyed? what systems and people interact with your processes?
- What information do you want to collect from or show to end-users?
- What FlowWright features do you want to access from your interfaces and core application? (You will use our .NET or REST API for this.)
Above are the 3 main logical thoughts most customers use when integrating FlowWright into their software product. So, let’s analyze in detail each of the above points:
What scenarios to automate?
Look for workflows that repeat within your code and for workflows that often or always require code changes for each customer. When customers use different workflows and rules/decisions from other customers, then using FlowWright to graphically modify these is both a huge time saver on the front end, but then also a massive asset when trouble-shooting and supporting customers. In addition, code that you need to change, test, and deploy quickly without retesting the whole application also benefits greatly from using FlowWright.
What information should the end-user see within the user interface?
In a typical application, users need to complete manual tasks that are assign by workflow processes. These tasks can easily be displayed and acted on within the customer's application interface. In addition, some FlowWright customers choose to expose workflow design functionality to their own customers - usually a limited set of functionality for designing workflows for only the use cases the OEM software is built to hand. In most cases, OEM user interfaces display no workflow functionality: FlowWright sits invisibly in the background and processes workflows.
What API integrations are required?
FlowWright has powerful, well-documented and intuitive-to-use APIs. FlowWright provides a .Net API and a REST API. The API calls you choose will largely depend on what FlowWright UI functionality you want to flow through to your OEM UI. For example, if you want to show a list of routed tasks for the currently logged in user, then use 2 API calls using the “deRuntime” API. Your application will also need only 3 API calls to kick off new workflow instances in FlowWright.
As you can see above, integrating FlowWright into your software product is simple to outline and easy to implement. All FlowWright customers have been successful with this process.
Learn today on how to integrate FlowWright workflow into your product!
Start your full featured trial version of FlowWright iBPMS and let's customize your free proof of concept (POC).
Why FlowWright?
Platform
Socials
Reviews
