I’m looking for the recommended OOTB approach in Constellation 25 to enforce mandatory Terms & Conditions acceptance on first login (or when T&C version changes).
Requirement:
User must accept T&C before accessing any other case types or landing pages.
Access must be blocked server-side (no URL/API bypass).
Acceptance must be auditable and version-aware.
Current proposed design (high level):
Dedicated data instance storing Operator + App + Version + AcceptedDateTime.
Simple case type to capture acceptance.
Access restricted via RBAC / Access Control Policies until acceptance record exists.
Optionally, auto-start case via post-authentication activity.
Before implementing this, I’d like to confirm:
Is there any OOTB mechanism in Constellation 25 for this scenario?
There is a standard cookie consent modal shown on first login, but I couldn’t find a supported way to reuse or customize it for T&C.
Is the custom data + case + access control approach the recommended pattern?
Not exactly covering RBAC and backend flow as it covers only frontend but good starting point might be modification of cookie consent banner: Customizing Constellation Portal
@vbarashko That might be the safest option, as you wanted to track approval stats for each requestor. If you just want to get users’ consent to use web access, then @Kamil_Janeczek provided approach would suffice, as it’s just acceptance of web access terms & conditions.
If you want to maintain a configuration of acceptances in SOR and maintain the versions and accordingly let the users accept the terms and conditions before they access any system resources then you can try to build a custom DX component of type widget on your own and put it on the home page.
Maintain configuration sets to have the latest version of the terms and conditions version and expiration date/days.
Maintain a data table where you have entries maintained for each user of which version of TNC they accepted and when they have accepted with an expiration date
When the user logs in, during the authentication you can fetch this information and put them on the Operator record.
When the home page loads, your component will read this information from the current logged in operator context and shows the modal window accordingly with the terms and conditions powered by a data page that in turn calls a delegated correspondence rule that contains the content to be shown to the user.
If the user has already agreed to the TNC it will not show from the next login.
User can close this modal continue their work only when they accept the terms and condtions check box and submit. Once submitted you can update the SOR and also the current operator record as well.
When your TNC has a new version, your admin can update the configuration set from Administration landing page and this will automatically enable the modal for every user login after this change enforcing the acceptance.
You can use this acceptance information from SOR or from Operator record to power your RBAC across your application assets for allowance/disallowance.
You can employ the same check for all your DX API requests as well accordingly.
I have tried this approach and its working well for a proof of concept.