Some customers need to run Flow Connect on their premises (on-prem) for different reasons.

1. Data requirements – Strict data security/privacy/legal requirements where the data is not allowed to leave the premises. For these types of customers, it is essential that everything runs on-prem since they don’t want any connection to the outside networks.
   Some examples:
   • Aerospace & defense
   • Defense manufacturing
   • Healthcare
   • Government and public sector

2. Low-latency requirements - Some customers have low-latency requirements with systems handling a high volume of transactions/executions. Typically, their existing infrastructure/external systems are already on-prem due to the exact reason. For these types of customers, flow connect adds a roundtrip through the cloud to access the data that’s already in their premise. This adds to the latency. It would be beneficial for this customer category to avoid the roundtrip through cloud infrastructure and be able to access their data locally.
   Some examples:
   • High volume manufacturing
   • Retail
   • E-Commerce

3. Intermittent connectivity – some customers do not have stable, always available internet connectivity due to the nature of the work they do. This does not mean they are not connected to internet at all. Rather internet connectivity is not a guarantee. Even if the internet is available, it might not be stable or with very low bandwidth. These customers want to carry on their work while being offline and once they are connected to internet, they want to sync their data/transactions/executions. We can divide this into two subcategories depending on how long they are disconnected from internet.
   a. Short term disconnection
   Typically, the disconnect from the internet lasts from a few hours to a few days. Examples include service technicians who goes into the field to carry out his work, field operations, mobile service units, etc.

b. Long term disconnection
The disconnect is long-term ranging from few months to a year or so. Example includes mining & oil rigs, fishing & maritime, engineering & construction sites, etc.
Suggested approach
The section below describes the approach RnD could take on handling some of the use cases/requirements mentioned above. It’s also important to note that the suggested approach will not cover all the requirements and use cases.
RnD wants to avoid taking a big-bang approach, but instead take a step-by-step approach where we solve one problem at a time and build on it. This would allow RnD to get feedback on the first step before moving on to the next steps.
Definitions & Disclaimers
• Design Time – The part of Flow Connect where the application packages/apps/components are designed and deployed to different environments. Design time also includes defining the connector configuration for the apps. So, Flow Hub, Flow Designer, and Portal Designer falls under design time. Please note that in the suggested approach the design time will always be in the cloud.

Stage 1 – Online on-prem
This solution involves running some parts of the Flow Connect runtime on the customer's local network. This lets Flow apps run machine steps directly on local systems without needing to connect to the internet/Novacura Cloud. The Internet is still needed to login to the flow connect client and to download the Application packages, apps, and components. However once logged in and loaded, the execution will be routed through the customer's local network. The following diagram illustrates the flow of data with this approach on a high-level.
Suitable for:
• customers with low-latency requirements - since the execution occurs locally it is an efficient solution.
Limitations:
• As mentioned previously, Design time will be always cloud only.
• Internet is still needed to authenticate with Novacura Flow Connect and download app packages/apps/components/modules/configurations.
Out of Scope
• On-prem design time
• Web client on-prem (web client delivered from a local on-prem service)
• Integrations

Stage 2 – Runtime on-prem
Stage 2 builds on top of Stage 1 where more services run on the customer's site. The goal of this step is to run flow connect apps without the need to communicate with the Novacura cloud. With this solution,
• Users will be able to authenticate themselves locally
• App packages/apps will be delivered from a service running on-prem
• Execution of machine step will be 100% on-prem (modules and connector configurations delivered from a local service)
Suitable for:
• Customer who wants their apps to work without being connected to the internet for a longer period (Long-term intermittent connectivity).
• Customers who do not want any of their data to be exposed outside.
Limitations:
• Design time is still cloud only.
• Data can be updated on-prem but no syncing back to cloud is allowed.
• An internet connection is needed occasionally to be able to receive updates from the Novacura cloud.
Out of Scope
• On-prem design time
• Integrations
Considerations
Although stage 2 looks very appealing it is an inherently complex solution with many unknowns (the diagram is an oversimplification). It will require a significant amount of work and time to fully implement for production level. There are many unknowns when it comes to different services that will require their own PoC before starting to implementation.

Offline client
Offline functionality makes it possible to work with flow apps without an internet connection for a short period of time. For offline functionality to work it is required that the data needed to execute apps are downloaded beforehand. With offline functionality all transactions that are produced by the apps while offline are put in a queue. Then The transactions are executed automatically in the background when the device has internet access.
Suitable for:
• Field operations, service technicians, etc. who are disconnected from the internet time to time. (short-term intermittent connectivity).

Summary
• Customers who want everything on prem will not be covered with the suggested solutions since design time will always be in the cloud.
• Customers with Low-latency requirements will be covered with Stage 1 of the proposed solution.
• Customers with Long-term intermittent connectivity requirements can be covered with Stage 2 of the proposed solution. However, it is a huge undertaking with a lot of unknows parts.
• Customers with Short-term intermittent connectivity requirements will be covered with offline client functionality.