Skip to main content
Open

Layout Process Flow Monitor

Related products:Indicium Service TierUI/UX
  • October 10, 2025
  • 7 replies
  • 134 views
Harm Horstman
Superhero
Forum|alt.badge.img+21

The new debug center looks great, but we would like to see some adjustments to the layout of the process flow monitor so that it can better assist us in resolving errors. Resolving issues in Process Flows is often very time-consuming. The process flow monitor we had in the Windows GUI wasn’t ideal either, but it still often allowed us to locate issues more effectively.

We hope it is not to much effort to come to a layout more like this...

Key focus points:

  1. Make the most efficient use of screen space wherever possible, assuming that nearly all developers have at least an HD display

  2. Indicators showing which actions were not successful 

  3. Duration of actions in milliseconds, highlight slow ones

  4. Type of action with symbol

  5. Display associated database event(s) per action as well

 

Logic will get you from A to B. Imagination will take you everywhere (Albert Einstein)

7 replies

Jeroen van den Belt
Administrator
Forum|alt.badge.img+10
New→Open
E
Moderator

Maybe also group the start and end of the same action. More often then not you are looking for 1 particular problem. Grouping these together would save up a lot of space. 

    Harm Horstman
    Superhero
    Forum|alt.badge.img+21

    In addition to this, flag HTTP actions (webconnector/HTTP connector) as failed in case the HTTP response status is not in the 200 range

    Logic will get you from A to B. Imagination will take you everywhere (Albert Einstein)
      T
      Moderator

      The failure flag is based on the process action status code, when it returns a negative value it'll set the failure flag. This'd mean that the process action itself would have to return a negative code. These codes are generally reserved for internal failures like: invalid certificate, timeout, invalid JSON Path for the output transformation etc.
      Furthermore, the valid response status codes depend on your specific requirements. It's true that 200 status code are generally successful, but that doesn't mean that non-200 response status codes mean failure. E.g. I personally wouldn't consider most 300 status codes to be failures. For example 304 (not modified) means that the resource you requested hasn't changed since your last request. Or other status codes like 404 could also be acceptable depending on the context.

      It might be a nice addition to have an endpoint being able to provide which response status codes it sees as successful, but I’m not sure if it's as simple as marking non-200 response status codes as failed.

       

      Harm Horstman
      Superhero
      Forum|alt.badge.img+21

      Hi ​@Tim Scholten ,

      Thanks for your response! I understand your explanation.

      But for us the main issue is that finding problems in process flows is very time-consuming. We spend a lot of time digging through steps to figure out where things went wrong.

      What need a simpler way to quickly spot issues in a flow, without having to investigate everything manually. 
       

      Logic will get you from A to B. Imagination will take you everywhere (Albert Einstein)
      T
      Moderator

      Yeah I also don't know what a good solution would be, I think that the suggested layout changes will already help with this.

      Maybe instead of trying to reuse failure, a warning system could be implemented that you could trigger?

      Harm Horstman
      Superhero
      Forum|alt.badge.img+21

      This was only an extra idea that popped up in this context. I hope you understand how important it is, to have a efficient debug center, as we may expect from a proper development platform. 

      Logic will get you from A to B. Imagination will take you everywhere (Albert Einstein)
        Terms & ConditionsAccessibility statement