Access authorization to form fields
Applies to version: 2025.1.x and above; author: Grzegorz Straś
Related Documentation
The 2 areas relevant to setting up this feature are the Visibility tab in the configuration of each form field, and the Security node in the global parameters, where the authorization methods are enabled. This article references only the minimal configuration required, but a full writeup of each page is available in the documentation:
Introduction
In WEBCON BPS 2025 R1, a new feature was added to enhance the security of vulnerable and confidential data. A user who wishes to gain access to a field will have to confirm their identity based on an additional authorization operation
This article describes Access Authorization to a form field. The configuration of the authorization methods themselves is shared with Path transition authorization. Access authorization is in many ways a continuation of that feature. The terminology and approach are carried over.
Configuration and operation principles
The access authorization feature provides additional authentication, protecting sensitive data on the form. When users open a form, they cannot interact with the protected data until they confirm their identity.
This can reduce the risk of unauthorized people gaining access to the data, but it can also alert the intended user that there is sensitive data on the form that they should be aware of.
Access to the data will either be time-limited (one authorization operation every so often) or always required, and users will need to perform an additional authentication operation every time they view the field.
The configuration to enable this feature is found in the Visibility tab and is named Access Authorization. It has the following settings:
- None – no additional authorization is required. This is the default for all form fields.
- Periodically required – one authorization is required for the entire authorization session.
The period of the authorization session is set globally for the environment, with a default value of 5 minutes.
During the authorization session, the end user may view any number of form fields (on any workflow instance) for which the authorization is set to “Periodically required”.
When the authorization session expires, a new authorization is necessary. One authorization is required for the entire authorization session. The authorization session lasts 5 minutes by default, but this value can be changed globally for the environment. During the session, the end user may go any number of times through any path (on any workflow instance) for which this authorization mode is set. When the authorization session expires, a new authorization is necessary,
- Always require – each access to a form field requires authorization. In this mode, the authorization session is related to a specific instance presented to the user at the time of authorization and to specific fields.
A new authorization in “Always require” mode refreshes the authorization session for “Periodically required” mode. This means that for the duration of the refreshed authorization session, the end user may view any number of form fields that have the authorization mode configured as “Periodically required”.
Access authorization can be enabled for form fields, as well as groups and tabs. It is possible for fields to have different levels of access authorization – although a scenario that involves a form having both periodic and always required authorization on the form at the same time seems unlikely.
It’s also worth noting that the periodic sessions are shared between access and path authorization. A user who confirms their identity to view a field will be authorized to use path transitions that require the same level of authorization, and vice versa. Of course, this is limited to the 5-minute window.
Fig. 1. Configuration of access authorization
The authorization methods to be used by the end user are defined by the system administrator in the Available authorization methods section under System settings → Global parameters → Security.
Fig. 2. Choice of authorization methods available to the user
If the field is configured with the Require periodically or Always require mode selected, and the administrator allows any authorization method (see Fig.2), a window allowing the selection of authorization method will appear (if only one is available, that one will always be used).
It’s worth remembering that for SMS authorization, the user needs to have defined a phone number in their user profile (or loaded from the Active Directory), and for the Mobile application method, the user needs a device with the mobile app added as a trusted device:
The e-mail option is always available since all synchronized users will always have a valid e-mail address. For the e-mail method, Portal will show the user a window to enter the code. Here the user must enter the authorization code that was mailed to them.
Fig. 3. Form window for entering the authorization code
Fig. 4. E-mail containing the authorization code and a list of fields that will be authorized after entering it
Entering the code is equivalent to confirming the user's identity, and once authorized, the user may continue working with the instance(-s) once or for the duration of the session (5 minutes by default).
If the field has been configured with the Always require option selected, viewing the fields will require additional authorization, even if the user already has an active authorization session. Authorizing will always refresh the session for all other fields configured as Require periodically – if they exist on the form, of course.
Form in view and edit mode
On a form in view (read-only) mode, fields, groups, and tabs that require authorization will be covered up with this button:
Fig. 5. A restricted field/group/tab
Clicking on the button will reveal the field as long as the authorization session is still active (Required periodically), or will need to be authorized each time (Always require).
Authorization is required immediately when opening the form in edit mode, or when attempting to enable edit mode on the form.
This “preliminary” authorization is required to make sure that business rules and form rules work correctly since those could be based on fields that require access authorization.
Limitations on Dashboards, Reports, and in Process Configuration
At the time of writing, there is no way to easily authorize outside of the form. Because of this, using form fields with access authorization configured is not possible in certain places. These include:
- Reports – fields are not available in column configuration,
- Dashboards – fields are not available in the configuration of data sources (or any place that uses these data sources, such as filters or tiles),
- Compact view – distinguishers set up in the process configuration.
Fields with access authorization cannot be displayed on reports, and may not be used in their configuration (e.g. Mass actions).
Attempting to configure access authorization on a field that is used in a forbidden place will result in an error. The same is true for attempts to place such a field in a tab or group with access authorization, this will also result in an error.
History and admin mode
Fields with access authorization are not included in the instance history. They are shown neither in the regular or admin mode. The only way to see historical data in these fields is to go to the versioned instance (magnifying glass icon above the version number) and proceed with the authorization as usual.
Because admin mode automatically shows fields in edit mode, switching to it will require authorization – the same as when opening the form in edit mode.
SDK and shared instances
In addition to presentation elements and on the form, access authorization places 2 more limitations on form fields:
- Access authorization cannot be added to fields that use Customization of form field controls (SDK).
- Access authorization does not work on shared instances, the button for revealing fields is inactive.
Archiving
After archiving the instance, access authorization no longer applies. Form fields requiring authorization are archived like those that do not.
Summary
The Access authorization feature, just like the Path transition authorization, provides our workflows with an additional layer of protection against unauthorized agents. Thanks to it, the admin can be sure that sensitive data is shown selectively – only when it is necessary. Of course, the feature in its simplest form can serve as a shield from prying eyes, but the more interesting outcome is the introduction and propagation of a certain level of information hygiene – a more conscious and prudent approach to handling sensitive data. This authorization, just like path transition authorization, should not be treated as a limitation, but as a method of increasing the safety of data entered into the system.
+48 12 443 13 90