Triggers

Creating a rule

Creating a data protection rule is a key step in configuring a data protection policy. The rule defines specific events (triggers) that will initiate certain actions and notifications. With flexible rule configuration, an administrator can precisely tailor protections for their organization against leaks to individual needs.

After creating a new policy (see: Creating a new policy data protection), the user proceeds to configure the rule assigned to that policy. The rule creation process includes the following steps:

  1. Adding triggers – events that initiate the rule.

  2. Configuring actions and notifications – specifying what will happen after triggers are met.

  3. Risk level - specifies the impact on the infrastructure when the rule is triggered.

  4. Assigning the rule – to devices or users.

circle-info

The color of the bar indicates the current load or risk level:

Green (0–33%) – value within normal range, normal state.

Yellow (34–66%) – warning level, observation or preventive actions recommended.

Red (67–100%) – critical state, requires immediate response.


New data protection rule step by step - Triggers

1

Adding triggers

In the newly opened tab there is an area with the text "When this happens...". This is where you configure the triggers that initiate the rule's actions.

Clicking the Add step opens the triggers window (side menu on the right side of the screen).

2

Trigger categories

Triggers are divided into two main categories:

  • Schedule - triggers that operate cyclically, without user involvement. Actions are executed automatically at specified intervals.

  • DLP (data loss prevention) - triggers activated as a result of user actions, e.g., attempts to copy data or other activity covered by the DLP policy.

circle-info

Additional information

The Schedule section enables running actions at regular intervals without the need for a specific event to occur. The action is executed cyclically, regardless of the current system state.

If the computer is turned off, the scheduled action is queued and will be executed after the device is restarted.

In the Schedule section for the DLP view the following options are available:

  • hourly,

  • daily,

  • weekly,

  • monthly.

[We are working on this functionality. We will announce its deployment in the changelog as soon as it becomes available.]

3

Trigger parameterization

Each trigger can be further parameterized depending on context. Parameterization is necessary when only specific cases are of interest, e.g., operations on files with a particular extension and in a given location.

For example, if we want to monitor only Word files saved on the desktop:

  • file mask - *.docx,

  • path - C:\Desktop.

Thanks to parameterization, the trigger reacts only to events that meet the defined conditions, instead of encompassing all operations of that type.

circle-info

The trigger is optional

For policy configuration setting a trigger is not always required. In some cases this step can be skipped by toggling the switch in the upper right corner of the tile and proceeding directly to the next stage, i.e., configuring actions.

This is useful, for example, when you want to trigger a startup message displayed every time a user logs into the computer, without the need to define a trigger or schedule.

To proceed to action configuration, click here.

Available trigger options

This allows scheduling the automation to run at a specific time, regardless of other conditions.

  • hourly - the automation runs once every hour.

  • daily - the automation runs once a day at the specified time.

  • weekly - the automation runs once a week, on the selected day and time.

  • monthly - the automation runs once a month, on the specified day and time.


After creating triggers you can proceed to configure actions and notifications, which constitutes the next step in the automation creation process.

Last updated

Was this helpful?