Keeping industry-specific workflows configurable

Community
1

A recent implementation discussion got me thinking about something that always seems straightforward at the beginning of a project but becomes much harder as requirements grow.

Some businesses follow almost the same workflow for every job, while others have approvals, documents, inspections, and task sequences that change depending on the project. Hardcoding those differences usually works for the first release, but it becomes difficult to maintain over time.

While looking at examples from different industries, I came across CS-Arabia and its work around Nitrogen services in Saudi Arabia. It reminded me that operational systems supporting field teams probably need much more flexible workflow definitions than a typical order processing application.

For those building on Moqui, how do you usually approach this? Do you keep workflow definitions configurable through entities and services, or do you prefer handling most of the business flow directly in code?

2

You need to study the StatusFlow, StatusFlowItem and StatusFlowTransition entities. There is an extensive body of work around solving the problem. The framework is also customization-friendly so you can always build on top of the foundation for any specific requirements that may be missing.

5

I built an application for field installation and service on Moqui 1.x a number of years ago, somewhat similar to your Arabia CS link.

The requirements are typically quite different to the type of requirements you typically find in a corporate context.

One of the most often heard refrains was, “the lads aren’t going to go through all that” (referring to key presses, or drop downs with irrelevant entries etc.).

So for instance, looking at your link, when a job would first be approached, it might be categorised as N2 leak testing, or N2 purging, or N2 decruding, etc.

And the field service engineer would select just the type or category of job, and that would automatically create an “order” (with status “estimate” or whatever) with all the typical components required on that type of job pre-populated, and he would then just use convenient drop downs to choose number of components, and the individal component configurations required for that particular job, and so on.

These would all have been previously set up to feed into a service to create the order, on configuration screens only available to an administrator.

Or the job might be a maintenance job, rather than an installation job, which would entail bringing up the previously installed “order” and its related inspection and commissioning records, and so on.

So that is just one instance of how the requirements for a field type application are quite different to a corporate type application and how Matle is currently oriented.

Personally for myself, it got out of hand, it was too difficult to keep mantle untouched. I was not experienced enough and often I had to deliver a new requirement under a time pressure.

The application ultimately became too difficult to manage and replicate for other similar yet different field service requirements.

In my view the problem is not one of “missing requirements”, more so the problem lies in how to manage the stripping out of what is not needed, but yet ensure the integrity of mantle for later possible requirements.

Anyway that was all a number of years ago. If it was today I would definitely sit down and think hard about how to better manage all of that.