User Voice

💡 Summary

Add a native “Freeze instance” / “Set On Hold” function that allows administrators (or authorized users) to pause a workflow instance — including all active sub-workflows — so that no tasks can be completed until the instance is released.

🧭 Current situation

In WEBCON BPS today, there is no built-in way to temporarily freeze an instance.
When a user mistakenly enters incorrect data or triggers sub-workflows, the process can move forward quickly before the error is discovered. Correcting this requires ad-hoc workarounds such as:

- Creating custom “On Hold” steps with no tasks,
- Adding complex path conditions or business rules, or
- Manually reassigning or closing tasks.

These solutions are difficult to maintain, especially in large applications with many steps and sub-workflows.

🚀 Proposed enhancement

Introduce a built-in “Set instance On Hold” capability with these behaviors:

- Freeze all user actions
Suspend all active tasks in the instance and its sub-workflows.
Prevent users from performing transitions or responding to tasks while On Hold.

- Display a visual warning
Show a banner or badge in the form header (e.g., “⚠ This workflow is currently On Hold”).
Optionally notify users who try to open tasks.

- Administrator control
Allow authorized roles to set or release On Hold status.
Optionally require a comment or reason.

- Automatic consistency across sub-workflows
Freezing the parent workflow automatically pauses all linked sub-workflows.
When the parent is resumed, sub-workflows are resumed as well.

- Audit visibility
Log “Set On Hold” and “Released” events in the workflow history for traceability.

✅ Benefits

- Prevents accidental progress on incorrect or incomplete data.
- Simplifies corrections without having to cancel or rebuild workflows.
- Reduces the need for custom “On Hold” steps, global paths, or path-rule maintenance.
- Improves user experience and administrative control in complex workflows.

Dear Community,
Currently, when accessing the homepage of WEBCON BPS, the browser title bar displays the name defined in:
System Settings → Global Parameters → Appearance → Portal name
However, when navigating to a specific application, the title bar only shows the Application name, which can lead to ambiguity - especially when multiple portals or environments are in use.

Suggested Improvement:
Include the Portal name alongside the Application name in the browser title bar for better clarity and context.
For example:
Portal name: WEBCON BPS 1st Company
Application name: Helpdesk IT
Browser title bar: Helpdesk IT @ WEBCON BPS 1st Company

The separator (e.g., "@") can be adjusted to suit branding or readability preferences.

Benefits:
Clearer identification of the portal context when multiple applications are open.
Improved user experience, especially in multi-tenant or multi-environment setups (TEST, PROD, DEV).
Easier navigation and task switching for users working across several portals.

Hi,

this user voice is related to this one:
Storing deltas of attachment versions instead of full file size
https://community.webcon.com/forum/thread/7909/15

Even so I mentioned that customers want to have all 177 versions or more, I think that we can define cases, when we could delete old versions of an attachment. As far as I know, this is not possible at the moment, we can either :
Remove attachment and leave attachment’s history – the attachment is deleted from the workflow instance, but the historical data are retained in the database,
Remove attachment and all binary data – the attachment is deleted from the workflow instance, and the historical data are also deleted from the database,
Remove only history of binary data – the attachment remains on the workflow instance, but historical data are deleted from the database.

There's no option to delete version attachment version 10, 15 and 20.

It would be great to have this as an action and API endpoint.

Best regards,
Daniel

Hi,

a lot of our customers are using the WebDAV integration to modify office documents. Unfortunately, some employees don't just save the file when they are done but hit the save button quite frequently.
This results in in a lot of versions and, depending on the file size, the database explodes.

At the same time our customers are against deleting old versions. While I'm still waiting for the answer how they wanted to find the one version out of 170 versions, that the situation.

It would be great if the current implementation for storing attachments would be changed to reduce the consumed diskspace while maintaining traceability.

I did a little brainstorming session with AI and there seem to be quite a few different options to achieve this.

Best regards,
Daniel

Hi Franek,

I also looked at the .bpe packages and wanted to save the result to Git so that we could compare it if necessary. Yes, it would be a pain but it would have been feasible, if necessary. Then we installed a new version and the order of the XML elements changed a lot, this made us drop the idea.

I still have the file:
$sourceFile = "C:\Users\dkrueger9319\Desktop\Temp\BPE\Incident Management_9_2021_03_29 11_59_34_dev_package.bpe"
$targetFile = "C:\Users\dkrueger9319\Desktop\Temp\BPE\Incident Management_9_2021_04_06 13_47_03_dev_app_only.bpe"
. C:\Workspace\PoC\LS-DLC_Research_Lab\PowerShell\Compare_BPE_Files.internal.ps1
Create-ComparableBPEFiles -sourceFile $sourceFile -targetFile $targetFile

Damn, it's already been four years. :)

We have some kind of code due to the import/export mechanism → inside the packages there are XML files that could probably be saved, visualized, and versioned with every save in the remote repository.


I do not know if this is possible in Webcon, but until we ask, we will not know. :) Currently, Webcon is working on a new version of Designer Studio, so perhaps they could consider building in some kind of Git repository support.(not only dark mode ;) )

Cheers

Hi Franek,

I'm sorry to ask this, but did you ask yourself how this would be possible? Since your are mentioning Git I'm assuming that you are a developer and therefore would be able to create a concept how it would be possible.

I read your message thought about it for a short time and dropped the idea. The issue is not the Git integration but that everything that entailed with it.

That's the current situation:
- There are no code files but data rows, which we would commit to git.
- There are multiple dependencies between the data rows.
- Simply everything in WEBCON is build on the integer ids.
- You need to commit all the applications, data sources, connection etc. to git


Issues:
- While you could compare the data rows from one table to another, that's mostly useless because there are dependencies. You would need some kind of visualization to decide, whether something should be merged into a branch without accidently breaking something else.
- Since everything is build on the integers this would need to be refactored to GUIDs. If this change would be applied, I would skip the next major release until everything is fixed.
- What are you doing if you are having workflow instances in steps, which you aren't (yet) available in a commit?
- Adding, removing and readding fields, because of switching branches, which could cause that the same field in the same environment has a different database column which in turn is used somewhere else?
- Security issues with passwords etc.
- Setting up Git

WEBCON BPS is a low code product targeting non developers at end customers , and this change would benefit only a very small percentage of the customers I would guess. The implied risks and costs simply aren't worth the effort.

Feel free to correct me and point out any errors. We would really be glad if there would be something because we, as a partner, are providing the same application to multiple customers and it would be great to have a comparison option between the current deployed version and the new one, before deploying it.

Best regards,
Daniel

Yes, but if you log in from outside the local Active Directory (e.g. Entra ID) and your server is in the local AD, there will be no information in the IIS logs about the user login.
There isn’t even any information in the Event Viewer security logs about who logged in — it only shows that someone logged in.

I’ve been wondering why Webcon doesn’t support Git integration. It could really help speed up the development of new features in workflows and make it easier to fix any critical bugs quickly. Webcon team — Git support would be a game-changer. Please consider adding it!

Would it be a problem to add a button "Show full error description" (available only for admin users maybe) on the error notification pop-ups ?
It would sometimes speed up the debuging.
When error shows up on production environment you have to log on to production designer to see what is going on and then to dev designer to fix it.
Knowing exact error description would let you sometimes fix/analyze it faster