long-running processes, instance correction & re-routing (admin side)

[JacoFourie]

Hello Imixs community,

First, a bit of background: I have worked with Oracle Workflow for the last 25 years. Although Oracle deprecated it as a standalone workflow product some time ago, we never found anything that matched its power in terms of flexibility and control. Now, Imixs Workflow looks very promising, with many of the features a mature workflow engine needs.

However, I have a concern and would like to understand how Imixs handles certain administrative or “rescue” scenarios for long-running processes.

Use case / concern

We have processes that may run for weeks or even months (or suspended for extended periods). During that time, business rules or data may change. A common example:
• Suppose a user approval limit was 1000 when the process started.
• Later, during the life of the process, that limit is raised to 2000.
• But when the process instance reaches the decision point (branching logic), the stored instance variable still reflects 1000, so the instance takes the “1000 route” — which is now incorrect given the updated rule.

In an Oracle Workflow world, we would have admin tools to intervene: adjust instance data, rerun or roll back to a prior step, then let the process take the correct branch with the updated data. We cannot realistically ask a user to cancel and restart a multi-week instance. Realistically, we’d expect administrators to:
1. Inspect the active process instance
2. Modify one or more instance variables (e.g. the approval limit)
3. Resume / re-execute from just before the decision point
4. Let the process now flow down the correct branch (i.e. as if the data had been that new value originally)

If things “go off the rails,” we want to put them back on track without losing the work already done.

My questions
1. Does Imixs support “instance repair” / “instance correction” / “rewind & resume” semantics — i.e. can you go back to a prior task or event boundary, adjust data, then continue with the correct branch?
2. If not out of the box, does Imixs provide administration APIs or tools (or plans) to support this kind of intervention?
3. Are there best practices (patterns) for long-running process resilience in Imixs, especially to handle cases where decisions may need to change mid-life?
4. Are there any caveats, limitations, or risks (e.g. transactionality, audit consistency, side effects) when intervening in a live instance?

Bonus context: I see that Imixs has an AdminP mechanism — a background administration process for batch jobs, etc.  Also, there is an Imixs Admin Client web UI for editing or deleting workitems / entities via the REST API.  These tend to focus on index rebuild, renaming, upgrades, bulk updates, cleanup etc. But I have not seen documentation about rolling back or resuming a branch based on updated data.

Also is there a grapical view of the process of what path it took.

Here is an example of the admin tool in Oracle Workflow

Here you vcan see I can Expedite a node and force it down any path I want. This option is only avilable to Admins

I’d really appreciate guidance or clarification from the project maintainers or those with deep Imixs expertise.

Thanks in advance

[rsoika]

Hello @JacoFourie and welcome to the Imixs community!
Thank you for your detailed question. Your Oracle Workflow experience brings valuable perspective. Let me explain how Imixs approaches these scenarios differently – in a way that often eliminates the need for administrative intervention.

The Key Architectural Difference
In Imixs Workflow, business rules live in the process model, not in instance variables:

• Business data (e.g., investment amount: $1500) is stored in the workitem
• Business rules (e.g., approval limit: 1000 or 2000) are defined in the model
• When a workitem reaches a decision point, it evaluates against the current model

Your approval limit scenario:

• Change the limit in the model from 1000 to 2000
• All waiting instances automatically use the new limit when they reach the decision point
• No administrative intervention needed!

Model Version Support
Imixs Workflow supports multiple versions of process models running simultaneously:

1. Automatic model version detection: When you deploy a new model version, Imixs automatically detects this
2. Flexible continuation: You can configure whether existing instances should:

• Continue with their original model version (for strict audit compliance)
• Automatically migrate to the new model version (for rule updates)

3. Long-running process support: Processes running for weeks, months, or even years are fully supported and handle model evolution gracefully

This design means that for your specific scenario, you simply update the model (change the limit from 1000 to 2000), and all pending instances will automatically use the new rule when they reach the decision point. No instance repair needed.

So to answering your question:

Does Imixs support "instance repair" / "rewind & resume"?

The Imixs philosophy is different: by keeping rules in the model rather than in instances, most scenarios that would require instance repair in other systems are handled through model updates instead.
The model-based architecture eliminates most scenarios requiring this.

Of course you have multiple ways through the AdminP Feature, the REST API and the Imixs Admin client for background batch operations on workitems.

Important: For audit-compliant processes, direct instance manipulation should be the last resort. Model updates handle most rule-change scenarios.

Some Best Practices for Imixs-Workflow

• Keep rules in the model, data in workitems
• Update models when business rules change
• Use AdminP/Admin Client only for exceptional data corrections

Regarding graphical visualization: Imixs-Workflow Metrics provide a powerful way to collect and visualize any business metric. For example you can use Application specific Dashboards or use Tools like Grafana to monitor your workfows:

Happy to discuss specific scenarios or implementation details!

[JacoFourie]

Thank you very much for the warm welcome and the detailed explanation, I really appreciate it.

I think there may have been a slight misunderstanding regarding two parts of my question:

1. Graphical Process View

When I mentioned “graphics,” I wasn’t referring to business dashboards or metrics, but rather to a graphical view of the actual process path, similar to what I showed in my original question.
In Oracle Workflow, we can visually see the exact path that a process instance took through the model (with green lines showing which transitions were executed).
Is there something similar in Imixs — a way to see the path a specific process instance followed through the model diagram?

2. Data Correction and Re-routing Example

Let me clarify my earlier example with a more practical scenario.

We have multiple external systems feeding data into our workflow system. Sometimes, one of these data feeds can fail — life happens.

For example:
• On 01/01/2025, my manager is Bob.
• On 03/01/2025, I get a new manager, Joe.
• However, the feed that updates reporting structures fails, so in the workflow system, my manager is still recorded as Bob.
• On 05/01/2025, I submit a travel claim, and the workflow routes it to Bob, when it should have gone to Joe.

When Bob receives the task, he logs a ticket saying it should have gone to Joe.
An administrator then investigates, realises the feed was broken, fixes the data feed (so the structure is now correct), and now needs to:
1. Remove the incorrect worklist entry for Bob.
2. Tell the process to continue from the step before the manager selection, so that the correct route (to Joe) is taken.

This is obviously a simplified example — in practice, we have systems in place to detect these situations — but it illustrates the kind of administrative control we need.

So my question is:
Is there a way for an administrator to fix the data and then rerun or continue the workflow instance from a specific point, or even to force it down a particular transition if necessary?

Does that make sense in the context of how Imixs works?

⸻

3. Some Context About My Background

I’ve been an Oracle Certified Professional (OCP) for many years, working daily with Oracle tools.
In my current role, we are migrating our internal processes to the Oracle APEX built-in workflow engine. There’s also a plugin called Flows for APEX that provides BPMN 2.0 support, but we’ve decided to use Oracle’s built-in workflow engine instead.

Interestingly, the built-in APEX Workflow also did not have the administrative side initially — Oracle ended up building that for us after seeing the same “real-world” need for admin control in long-running business processes.

For reference, APEX Workflow now includes the ability to resume workflows from any activity, and it also visually shows the path a process took through the model:
👉 Oracle APEX 24.2 – Resume Workflows from Any Activity

⸻

I’m exploring solutions outside the Oracle ecosystem for process automation — ideally something open, flexible, and modern that I could pair with technologies like Flutter for the user interface.

Imixs looks very promising in that regard, and I’m really interested to understand how it handles these advanced workflow administration scenarios.

Thanks again for your time and detailed feedback — it’s much appreciated.

Best regards,
Jaco

[rsoika]

Hello Jaco,
Thank you for the clarification and for sharing more about your background and requirements. Let me address both points:

1. Graphical Process Path Visualization

You're right – Imixs does not provide a graphical process diagram with highlighted paths like Oracle Workflow's green lines showing which transitions were executed. This is by design: our modeler is completely separated from the runtime environment. The BPMN 2.0 modeler is used purely for model creation and maintenance, while the actual process execution happens in the workflow application runtime.
However, Imixs provides a comprehensive History Feature that serves a different but important purpose: audit compliance and business documentation. The history may look like this:

05. May 2021 (10:12) - M. Melman: Process created and forwarded ⇨ Anna
05. May 2021 (10:13) - M. Anna: Process reviewed and rejected
      Comment: wrong department code!
06. May 2021 (10:14) - Ralph Soika: Data corrected and forwarded ⇨ Logistics
07. May 2021 (10:15) - M. Alex: Technically reviewed and released
      Comment: ok
15. May 2021 (10:15) - M. Gloria: Process reviewed and approved
17. May 2021 (10:16) - M. Melman: Delivery completed

This provides a complete, revision-safe audit trail of who did what and when – which is typically what end users and managers need. While we could theoretically integrate our open-source OpenBPMN platform to display model details in the browser, we believe this would overwhelm end users with technical model details that aren't relevant to their work.
Question for you: In your daily operations, who actually uses the graphical path view? Is it primarily administrators during troubleshooting, or do business users regularly need this?

2. Your Manager Routing Scenario

I think there may still be a slight misunderstanding about how Imixs handles this. Let me address your specific example:
Your scenario: Data feed fails → Manager data is wrong (Bob instead of Joe) → Process routes to wrong person → Admin needs to fix and re-route.
How Imixs solves this:
The key is that Imixs doesn't store "my manager is Bob" in the workitem. Instead:

The workitem stores: "userId: jaco123, amount: $500"
The model defines: "Route to current manager of userId"
At routing time, the system (Imixs Microkernel architecture) looks up the current manager in real-time

So if your manager changes from Bob to Joe, the next routing automatically goes to Joe – even if the process started when Bob was your manager. No admin intervention needed.
For your specific failure scenario: If the organizational data feed fails and hasn't updated yet, you can:

a) run a scheduled event to maintain updates in backgroud
b) use the Imixs Event Processing to react on data changes in realtime with full transaction support
c) Fix the data feed / organizational structure by using the Admin Client to reassign the workitem from Bob to Joe (simple REST API call)
The process continues normally

No need to "rewind" or "replay from a specific step" – you just correct the assignment and continue forward. This is a standard administrative operation we support.

Administrative Control in Imixs

To be clear: Yes, Imixs provides administrative tools (AdminP, Admin Client, REST API) to modify workitem data and reassignments.

However, our philosophy is:

• Design the model to be resilient to data changes (don't store decisions in instances)
• Use admin tools for data corrections, not for process re-routing
• Handle organizational changes through the model and the microkernel architecture, not through admin interventions

This approach provides better audit compliance because you're not manipulating process flow – you're correcting data errors.

Your Migration Context

It's interesting that Oracle APEX Workflow didn't support you with the admin controls initially and needed to be added by custom features. That suggests that different workflow philosophies exist in the market.
I'm curious: In your APEX migration, how often do you actually need to use the "resume from any activity" feature? Is it primarily for:

1. Handling external system failures (like your example)?
2. Correcting process design errors in production?
3. Other scenarios?

I think I would try to solve this with a event-log-streaming approach. Understanding your actual usage patterns would help me provide better guidance on how Imixs would fit.

Your Flutter + Open Source Plans
Imixs paired with Flutter sounds like an excellent combination! Our REST API is well-documented and provides full access to all workflow operations. We'd be very interested to hear more about your project:

• What kind of processes are you looking to automate?
• What's your typical process duration and complexity?
• Are you considering cloud deployment or on-premises?

Feel free to reach out directly if you'd like to discuss implementation details or specific scenarios in more depth.

best regards
Ralph

[JacoFourie]

Hi Ralph,

Thank you again for the detailed and thoughtful response — I’ll reach out to you via your formal business channel to continue the discussion in more depth.

Just to give you a bit more context from my side:

In my day job, I work for a enterprise with around 3,000 employees. We began building our internal workflow system roughly 25 years ago, using Oracle Forms as the front end and Oracle Workflow as the state engine. We chose Oracle Workflow because it was included with the Oracle Database at no extra cost.

In 2003, Oracle discontinued Workflow as a standalone product. It still exists inside Oracle Financials (E-Business Suite), but since the engine itself is written entirely in PL/SQL with a Java applet front end, we kept using it for years because it was reliable and free. Oracle later introduced their BPM Suite as the successor, but it was expensive and not really a good fit for our needs.

🔗 Oracle BPM Suite

Fast forward to recent years — as Java applets are no longer supported in browsers, we had to modernise the user interface. Around 2018, we began migrating to Oracle APEX, which offered a responsive, web-based low-code environment.

That’s when I discovered Flows for APEX, which adds BPMN 2.0 capabilities directly into APEX. It’s a fantastic project, and I even worked with their team to help introduce features I am asking you about such as Suspend, Rewind, and Resume — which they released in September 2025.

🔗 Flows for APEX 25.1 Features

However, when Oracle decided to build its own native workflow engine directly into APEX, they stopped funding the Flows for APEX project. As a result, the Flows team introduced an Enterprise Edition, where organisations can pay for support to help fund further development.

Even though Flows for APEX is excellent, it’s still a plugin, and we’ve been very cautious about using plugins after bad experiences in the past. For example, we once relied on a plugin that provided combo box functionality; when the developer abandoned it, we were stuck — the plugin broke after an APEX upgrade, and we couldn’t move forward until we paid a third-party company to fix it. Oracle later added its own native combo box, but that experience made us much more conservative about plugin dependencies.

Oracle’s built-in APEX Workflow is still evolving — they recently added parallel execution paths and gateways, and the new “resume from any activity” feature (which I mentioned earlier) has made a big difference. It’s definitely a journey, but a positive one.

⸻

My Remaining Question About Re-Routing

I still don’t fully understand how Imixs handles a process that has already taken an incorrect path.

Let’s say a workflow routes a human task to the wrong user because of incorrect data. In our case, that means a record has already been created for that user, and any other tables have been updated to wrong way, an entry also now exists in the worklist table. To fix the issue, that worklist entry would need to be removed, and the process instance would need to be re-run from a specific point — after the data has been corrected — so that the correct route is taken.

Otherwise, how would the engine know to take a new path unless someone explicitly instructs it to do so as it is waiting for a user task to complete in the wrong worklist?

From what I understand so far, the admin could use the API to reassign the task, but what about cases where the route logic itself must be re-evaluated after a data fix? Is there a supported way to trigger a re-evaluation from a given point, similar to how “resume from activity” works in APEX Workflow?

⸻

On the Graphical Path View

As for the graphical view, I completely understand your reasoning about not exposing model complexity to end users. However, in our experience, the graphical path view is extremely useful for both business users and administrators.

In Oracle APEX Workflow and Flows for APEX, you can visually see:
• The exact path the process has already taken (highlighted), and
• The upcoming steps it still needs to go through.

This has proven invaluable for users to understand where their request currently is and how far it has progressed — especially in long-running workflows. It’s not about showing technical model detail, but about transparency and traceability in the business process.

⸻

Exploring Open-Source Options

Separately from my day job, I also run my own consulting company, where we develop software platforms for smaller businesses. I’m currently exploring open-source workflow options — like Imixs Workflow — for these projects.

The goal is to build process automation systems that are not tied to Oracle, since not all clients can afford the Oracle price tag. I’m particularly interested in pairing Imixs Workflow with Flutter as the front-end framework to create flexible, cross-platform business process applications.

⸻

Thanks again, Ralph, for taking the time to explain all of this in such depth. I really appreciate your openness and the clarity you’ve provided.

Best regards,
Jaco

[rsoika]

Sure, simply send a request to info@imixs.com