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

User Voice

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.

Sometimes an Item list isn't the best way to display data, it would be better to display in the default stacked format. If you want your data to look this way you can't utilize the Autocomplete Field Type. The ability to disable adding rows in an Item List somewhat covers this, but having the ability to use an Autocomplete within a Group would let users have the same search experience regardless of if fields are in an Item List or a Group. Thus allowing both form factors to function the same way from a user perspective.

Hi everyone,

I would like to suggest an improvement to the standard archiving mechanism in WEBCON BPS.

Currently, the standard archiving functionality works well in two important areas:
- links to archived elements remain the same as before archiving,
- archived elements are moved to a separate archive database, which helps reduce the amount of data processed in the main database and improves performance.

However, there is one very important business requirement that is currently not covered:
- Archived elements should preserve the same read permissions they had before being moved to the archive.

In many real-life business processes, permissions are not global or static. They are often assigned individually to each workflow element based on:
- the author of the element,
- process participants,
- actions executed during the process,
- the path the element followed,
- business-specific permission logic.

This means that every element can have a different permission set depending on how it was processed.

For some organizations, granting broad/global access to archived elements is not acceptable due to security, compliance, and confidentiality requirements. Manual permission assignment is also not realistic when dealing with large volumes of archived data.

We have already consulted this case with WEBCON. Based on the analysis, this scenario cannot currently be handled using standard configuration, SDK extensions, or REST API. Modifying the archive database directly is not recommended and would be risky, especially because archiving is asynchronous and processed through a queue. This creates a risk of inconsistency between permissions at the time the item is queued for archiving and the moment it is actually archived.

WEBCON also suggested creating a User Voice request on the Community portal, as support from other users may help prioritize and speed up the introduction of such functionality in the product.

Because of this, I believe WEBCON BPS should provide a standard, supported way to preserve item-level read permissions during archiving.

This would make the archiving feature much more useful in enterprise scenarios where performance optimization must still respect existing security rules.

I think this would be valuable for many WEBCON BPS customers who need to archive large amounts of data without compromising access control.

Please vote if you also need archived elements to keep their original permissions.

MVP

Hi everyone,

assuming that I'm not doing anything wrong then this endpoints returns the collection of all attachments with their content.
"https://$($WebconConfig.Hostname)/api/data/v7.0/db/$($WebconConfig.DatabaseId)/elements/$ElementId/attachments"
$result = Invoke-WebconApiRequest -Method "GET" -Uri $uri
$result.attachments[0].content.length
932976

Depending on the use case, it may not be necessary to return the actual content of the attachment. I'm also wondering how this will react if there are dozens of large fiels.

Therefore I would suggest to add a flag /query parameter to especially request the content / skip the content.

Best regards,
Daniel