GermainUX provides dynamic, context-aware access controls that determine which users and teams can view specific collected data points—called facts—and Session Replay recordings.
Unlike Data Privacy controls, which determine whether sensitive information is collected, masked, or anonymized, Data Security controls who can access the data after it is collected.
This enables organizations to restrict visibility according to application context, transaction type, user role, team membership, or other business-specific criteria.
Key Capabilities
|
Capability |
Description |
|---|---|
|
Fact-level control |
Visibility can be assigned to individual data points. |
|
Session Replay control |
Access to recorded sessions can be restricted according to the activity captured in each session. |
|
Team-based access |
Data can be made visible only to designated GermainUX teams. |
|
Context-aware rules |
Access can depend on application, transaction, user role, business area, or other collected context. |
|
Custom security logic |
Organizations can implement custom scripts that define visibility according to their own requirements. |
|
Dynamic assignment |
Access metadata is assigned as data is collected and used to enforce visibility in GermainUX. |
Session Replay Security
Session Replay access can be restricted according to the context of the recorded activity.
For example, a financial organization may permit different teams to view sessions involving different financial products or transactions.
Custom access logic can be added through the RUM JS initialization script.
Use:
settings.application.metadataProviders['access']
The metadata provider assigns the appropriate access information to the recorded session. GermainUX then uses that information to determine which authorized teams can view the replay.
Fact-Level Security
Fact-level security applies visibility rules to individual data points, such as:
UxConsoleEvent
Custom logic can be added through:
settings.application.factProcessor
The processor evaluates each applicable fact and assigns its visibility expression before the data becomes available to GermainUX users.
Access Expressions
Visibility is defined through team-based access expressions.
|
Expression |
Meaning |
|---|---|
|
|
Visible to Team 0. |
|
|
Visible to Team 1. |
|
`t0 |
|
|
|
Visible when the applicable Team 1 and Team 2 access requirements are satisfied. |
Team identifiers and expressions should be configured according to the organization’s GermainUX team and authorization model.
Example: Financial Organization
Consider an organization in which access to recorded activity must be separated by financial product.
|
Team |
Authorized data |
|---|---|
|
Team A |
Sessions and facts related to Stock ABC. |
|
Team B |
Sessions and facts related to Stock DEF. |
The custom security logic evaluates the monitored application context and assigns visibility based on criteria such as:
-
Financial product
-
Transaction type
-
Business function
-
User role
-
Organizational team
As a result, each team can access only the sessions and facts it is authorized to review.
Implementation Summary
|
Security scope |
Configuration mechanism |
Purpose |
|---|---|---|
|
Entire Session Replay |
|
Controls which teams can view a recorded session. |
|
Individual facts |
|
Controls which teams can view specific data points. |
|
Team visibility |
Expressions such as |
|
Test all custom security logic before deploying it to production. Confirm that unauthorized users cannot retrieve protected data through dashboards, searches, reports, exports, Session Replay, or other supported interfaces.
Related Documentation
This page focuses on access to collected facts and Session Replay recordings. Related capabilities are documented separately:
Service: Management
Feature Availability: 2021.2 or later