Business rules

Business rules in Workspace Settings let you configure thresholds and classifications that Oleria uses across identity security analytics. Adjusting these settings shapes how dormancy, risk SLAs, and access token validity are evaluated throughout the product.

For example, Oleria defaults to classifying any account as dormant after 30 days of inactivity. If your organization’s policy uses a different threshold, you can update that here - and the change will be reflected in dashboards, group status, and the access graph.

Only Administrators can change business rule settings.

Dormant days

Define the number of days of inactivity after which an account is considered dormant. This value affects dormant account counts in dashboards, group status in Group Utilization, activity paths in the Access Graph, and the Workspace dashboard’s dormant account and unutilized group metrics.

Oleria’s default is 30 days.

1. Navigate to Dormant Days settings

   Go to Settings → Business Rules → Dormant Days.

2. Set the threshold

   Enter the number of days after which an account is considered inactive.

   

3. Save and confirm

   Save the change. The new value takes effect after the next data sync, which typically completes within one hour.

After the change takes effect: account active/inactive status updates across Group Utilization data and graphs; solid and dotted lines in the Access Graph reflect the new threshold; and the Workspace dashboard updates dormant account and unutilized group metrics.

Service level agreement (SLA)

Define the number of days for each risk severity level after which a risk is considered out of SLA. This affects the SLA breakdown metrics in Risk Monitoring.

Oleria’s defaults:

• Critical - 3 days or more
• High - 7 days or more
• Moderate - 30 days or more
• Low - 60 days or more

1. Navigate to SLA settings

   Go to Settings → Business Rules → Service Level Agreement.

2. Set the SLA thresholds

   Enter the number of days for each risk severity level.

   

3. Save and confirm

   Save the change. The new values take effect after the next data sync and apply to existing synced data as well. This typically completes within one hour.

Personal access tokens

Access tokens authenticate to SaaS applications in place of usernames and passwords. For GitHub, personal access tokens (PATs) are common when authenticating from the command line or via APIs.

Define the maximum number of days a personal access token is considered valid. Tokens older than this threshold are flagged as a risk.

1. Navigate to Personal Access Tokens settings

   Go to Settings → Business Rules → Personal Access Tokens.

2. Set the maximum validity period

   Enter the maximum number of days for which a personal access token is considered valid.

3. Save the change

   Save the setting.

Contact us

For questions, contact us at [e-mail].