Domino Interface

Public vs Private In the digital automation market, which includes workflow and business process automation, there are literally dozens of no-code or low-code platforms available as public cloud solutions. They range from products like Zapier to Tray.io. In general, they all provide easy-to-use interfaces for assembling cloud services together in order to automate processes. Some are geared towards individual users and some towards enterprise businesses. However, aside from the ones intended for individuals or very small businesses, they may require some significant setup, configuration, and administration. Public cloud-based solutions have a number of advantages for process automation. You can sign up and get access to these services within minutes and have a new process up and running in a relatively short time. However, the majority of these solutions operate by routing your data (and the subsequent responses) through a series of different cloud services. Not only is your process de

The world of data processing is far different than it was 10 years ago.  More and more of it is being done externally by highly specialized service providers. This enables companies to utilize the best available services -- without having to reinvent the wheel -- and incorporate those services into their core business processes. The resulting approach is also more agile, enabling companies to respond quickly to ever-changing business needs. You can think of your business users as your subject matter experts. They are the ones who have first hand, daily experience with your data and processes. In a perfect world, they are the people who would be designing your processes, and in today's environment, that means taking full advantage of external services. Your IT administrators are the gatekeepers. They are charged with protecting your business from threats and maintaining the security of your data. The last thing they want to see are your business users exposing the company's data

In the last post, we discussed the use of flow-based programming for creating user interfaces. In this post, we introduce the ActionStream, which is the the foundational flow-based component in iPhora. A workflow process consists of series of nodes that are connected together. iPhora AppBuilder supports many different types of nodes, including task nodes, notification nodes, and branching nodes, as well as a wide range of action nodes. A sequence of actions that are connected together is referred to as a flow. During our 20+ years of experience in automating processes, we encountered many situations where the same repetitive flow occurred within different processes.  Therefore, it would be beneficial if it were possible to reuse the same flow in multiple processes and applications. This led directly to the development of the ActionStream, which is a reusable sequence of action nodes, in other words a reusable flow. Originally, ActionStreams were just a way to quickly implement custom c

In general, for non-software developers aka business users, an Application is one single object that they download and install onto their device whether a phone or laptop. It may also be a solution that they can access from their web browser. It may contain a series of screens that they navigate between as they use it.  The Application most likely includes many components working in unisons some in the background and some generating the visual interface that they see. The Application may have many screens and visual design elements. For example, you might have a dashboard that shows aggregated data, a grid that list documents, or a form that users will use to fill out data.  Many solutions layout out the different screens using a tree structure that shows the relationships between screens.  Usually, you build the connections between the pages by selecting actions within a screen. For example, in Microsoft Power App. the tree structure looks like: However, we wanted a more visual and in

By trade, I am an Electrical Engineer with a specialty in Microwave Engineering. And as part of my education, I had to take courses in process and industrial engineering which involved process optimization and automation. I hated these two courses and naively thought I would never ever use the information that I learned in these two courses. I only had interest in the technical aspect of engineering and with my first job out of college that is what I did. Never did I ever thought that I would spend the past 20 years focused on stuff that I hated in college. The concepts of iPhora came out of issues that we encountered as we rapidly grew another business many years ago from which spawn our business process automation business which we have been doing for the past 20 years. For the past few years, we have been transforming our consulting service platform into a commercial off-the-shelf product that focuses on the business user as the target audience. We would like to introduce iPhora Aut

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a