WELCOME TO THE COMMUNITY
find what you are looking for or ask a new question
Home > User Voice > Latest posts

User Voice

MVP

Hi,

I suggest introducing gamification capabilities within WEBCON BPS Portal to increase user engagement, process adoption, and data quality.

Users could earn points, badges, and achievements based on their activities in the platform, such as:

* Completing workflow tasks on time
* Creating and processing workflow instances
* Maintaining high-quality data
* Participating in business processes regularly
* Reaching productivity milestones
* Supporting process improvements and optimization initiatives

Organizations could optionally use leaderboards, levels, personal progress tracking, and rewards to encourage participation and strengthen user adoption of digital processes.

Gamification would make daily interaction with WEBCON BPS more engaging, increase process compliance, and help organizations drive successful digital transformation initiatives.

Raluca has a KB article about it but built-in and maintained by WEBCOB would be great:
https://community.webcon.com/posts/post/how-can-you-digitize-processes-in-webcon-bps-and-make-them-engaging-at-the-same-time/438/4

Kind regards
Sébastien

(My idea but AI generated text)

MVP

Hi,

we have dictionaries containing a multiline text field containing base64 image strings. Those strings are needed to display the image in reports or picker dialogs.

Using the Excel export button in the portal leads to this error:

"msg: An unhandled exception has occurred while executing the request. | ... | href: | ex: Aspose.Cells.CellsException: You want to put a string longer than 32K to Cell F4. MS Excel only allows to put a string shorter than 32K to a Cell."

This is why I suggest to add import/export not only for Excel but also for JSON format.

Kind regards
Sébastien

In reply to: Michal Rykiert

We're reviewing the situation as it's a bit more intricate than you described. We'll update this tread whenever a decision is reached.

Hi Michał
We are still waiting for a solution to an issue that should be straightforward to implement.

From the SQL perspective, the report displayed on the dashboard has the same configuration as a regular report. The view configuration is also identical. From the front-end perspective, the situation should be clear, as dashboard filtering operates on data sources rather than on individual reports. Therefore, it is difficult to understand how such a discrepancy in behavior could have been introduced between two identically functioning solutions.

I hope this issue can be resolved in the near future, as an increasing number of users are beginning to raise complaints in this area.

MVP

Hi,

in the configuration of a report it is possible to have a dropdown of steps of the workflow in the advanced filters section. But those addtional filters can be deselected from users. That's why I suggest to have the same functionality with dropdowns with all values also in default filters instead of limited matching criteria and a static value.
Indicating a step id here breaks the report after import to other environments because the step id remains the one from DEV.

This is not only for the step attribute. You can enhance all attributes representing a form field.

Kinrd regards
Sébastien

Please add:

1. New response type "Multipart"

Support multipart HTTP responses in the "Invoke REST Web Service" action, not only multipart request bodies.

2. Add header and response code/body mapping for response type "Binary"

HTTP headers are independent from the body type and should be accessible for mapping even when the response body is handled as binary stream / attachment.

Typical use cases:

* file download + metadata headers
* OCR/AI APIs returning metadata in headers
* presigned URLs
* correlation IDs
* filename/content-disposition handling

3. Add new response type "Text" / "Raw"

Currently the action supports only:

* Binary
* JSON

A plain text / raw response mode is missing.

This causes problems with APIs returning:

* CSV
* text/plain
* XML without JSON wrapping
* custom text formats

without requiring JSON deserialization.

4. Decouple response parsing from mapping capabilities

Currently:

* JSON mode enables response/header mapping
* Binary mode disables it

The response metadata (headers/status code) should always be available independently from body parsing mode.

5. Add support for content-type aware handling

Example:

* application/json => JSON parsing
* text/csv => text mode
* application/octet-stream => binary mode

Currently JSON mode appears to force Newtonsoft JSON deserialization regardless of actual response content type.

6. Allow mapping of:

* HTTP status code
* raw response body
* response headers

for all response modes.

This would significantly improve compatibility with modern REST APIs.