> For the complete documentation index, see [llms.txt](https://eaclouddoc.eauditor.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://eaclouddoc.eauditor.eu/eacloud-docs-en/features/data-loss-prevention/triggers/how-triggers-work.md).
# How Triggers Work
**Trigger** defines the event or condition that causes the DLP rule to start.
For example, it can be:
* device connection,
* USB storage use,
* copying data,
* sending a file,
* starting a specific process,
* visiting a website,
* an event occurring at a specific time.
The trigger therefore answers the question:
**When should the rule be activated?**
What **the system will do after detecting the event**, are determined by the configured [actions](/eacloud-docs-en/features/data-loss-prevention/actions.md).
{% hint style="info" %}
The trigger and the action serve different roles. The trigger detects a specific event, while the action defines the system response, such as blocking the operation, taking a screenshot, or displaying a message.
{% endhint %}
### Workflow diagram
The rule operation can be represented simply as follows:
**Event -> Trigger -> Action -> Notification**
Example:
A user connects an unauthorized USB storage device.
1. The trigger recognizes the event.
2. The system checks the conditions configured in the rule.
3. If the conditions are met, the appropriate action is performed.
4. If a notification has been configured, the information can be sent to the designated recipient.
Triggers define the events that cause a DLP rule to start.
### Available trigger types
The trigger type should be selected according to the event you want to control.
| Trigger | When to use it |
| ------------------------------- | -------------------------------------------------------------------------------------------- |
| **Schedule** | When the rule operation should depend on a specific time or schedule |
| **Copying** | When you want to control data copying operations |
| **Device connection** | When you want to control the connection of specific types of peripheral devices |
| **USB device connection** | When you want to control USB storage devices in detail, including specific media |
| **File sending** | When the rule should respond to file sending |
| **File operations** | When you want to respond to specific actions performed on files |
| **Process/application started** | When the rule should respond to the launch of a specific program or process |
| **Website visited** | When you want to control the use of specific websites |
| **Network connection** | When the rule should respond to a specific network connection |
| **Working hours exceeded** | When the event should be detected after the configured working hours range has been exceeded |
| **Screenshot** | When the rule should respond to a user taking a screenshot |
{% hint style="info" %}
Each trigger type has its own configuration parameters. After selecting the appropriate type, define the conditions that match the scenario you want to control.
{% endhint %}
### Device connection and USB device connection
These two triggers have different use cases.
#### Device connection
Trigger **Device connection** is used to control categories of peripheral devices, for example:
* printers,
* external drives,
* pointing devices,
* other supported device types.
The mechanism lets you define whether a given device category should be allowed or blocked.
#### USB device connection
Trigger **USB device connection** is intended for more detailed control of USB storage devices.
It allows, among other things, the consideration of:
* specific devices identified based on **Device ID**,
* encrypted media,
* unencrypted media,
* specific USB storage groups.
{% hint style="warning" %}
Do not treat triggers **Device connection** and **USB device connection** as interchangeable.
If you want to control a specific USB flash drive or USB storage properties, use the trigger **USB device connection**. To control other categories of peripheral devices, use **Device connection**.
{% endhint %}
### Adding a trigger to a rule
{% stepper %}
{% step %}
#### Open the rule
Create a new rule or open an existing rule for editing.
{% endstep %}
{% step %}
#### Go to the Triggers section
In the rule configuration, go to the **Triggers**.
The available event types will be displayed.
The trigger type defines the event that is to start the rule.
{% endstep %}
{% step %}
#### Select the trigger type
Select the trigger that corresponds to the event you want to control.
For example, if the rule should respond to USB storage use, select **USB device connection**.
{% endstep %}
{% step %}
#### Configure the conditions
Set the parameters available for the selected trigger type.
The scope of configuration depends on the type of event.
It may include, among other things:
* device,
* process or application,
* website,
* operation type,
* file parameters,
* time,
* connection method.
{% endstep %}
{% step %}
#### Configure the action
After defining the trigger, configure the system response in the **Actions**.
{% hint style="info" %}
Specifying the event alone does not yet define how the system will respond.
{% endhint %}
{% endstep %}
{% step %}
#### Save the rule
After completing the configuration, save the rule and assign it to the appropriate policy.
{% endstep %}
{% step %}
#### Update policies
After saving the changes, click:
**Update policies**
so that the latest configuration can be delivered to the eAgents.
{% endstep %}
{% endstepper %}
### How do I choose the correct trigger?
First, determine the event you want to detect.
#### I want to control...
**...USB flash drives and USB storage devices**
Use:
**USB device connection**
***
**...printers, drives, or other peripheral devices**
Use:
**Device connection**
***
**...launching a specific program**
Use:
**Process/application started**
***
**...sending a file**
Use:
**File sending**
***
**...actions performed on a file**
Use:
**File operations**
***
**...copying data**
Use:
**Copying**
***
**...using specific websites**
Use:
**Website visited**
***
**...time-based events**
Depending on the scenario, use:
**Schedule** or **Working hours exceeded**
{% hint style="info" %}
When creating a rule, start by asking: **which specific event do I want to detect?** Only then define what the system should do with it.
{% endhint %}
### Activating and deactivating a trigger
If the configuration of a given trigger allows its state to be changed, you can temporarily disable the mechanism without removing the saved parameters.
This is useful during:
* rule testing,
* temporary disabling of a specific control method,
* preparing the configuration before deployment.
After re-enabling the trigger, its saved configuration can be used again.
### Testing a trigger
Before deploying the rule to a larger number of computers, perform a test.
{% stepper %}
{% step %}
#### Limit the policy scope
For the duration of the test, assign the policy to a computer or a small group of test devices.
{% endstep %}
{% step %}
#### Update policies
Send the latest configuration to eAgent.
{% endstep %}
{% step %}
#### Trigger a controlled event
Perform the action corresponding to the configured trigger.
For example:
* connect a test USB storage device,
* start the specified application,
* visit the configured website,
* perform a test file operation.
{% endstep %}
{% step %}
#### Verify the response
Verify that the expected action was performed.
{% endstep %}
{% step %}
#### Check the DLP Logs
Go to:
**Data Leak Prevention -> DLP Logs**
and review the information related to the tested event.
{% endstep %}
{% endstepper %}
{% hint style="warning" %}
Always test blocking rules in a controlled environment before broad deployment. A misconfigured trigger may cause the action to be executed more often than intended.
{% endhint %}
### FAQ
Does the trigger block the user's activity by itself?
No. The trigger defines the event that starts the rule.
The response method is defined separately in the configuration **Actions**.
Are Device connection and USB device connection the same trigger?
No.
**Device connection** is used to control categories of peripheral devices, for example printers or drives.
**USB device connection** is used for detailed control of USB storage devices and allows you to include, among other things, specific devices identified by Device ID.
Can I change the trigger configuration after creating the rule?
Yes. Open the rule for editing and change the trigger parameters.
After saving the changes, remember to use the option **Update policies**.
Why is the modified trigger not yet working on the computer?
Check whether, after saving the configuration, the option was used **Update policies** and whether eAgent downloaded the current configuration.
Which trigger should I choose to control a specific USB flash drive?
Use the trigger **USB device connection**.
It allows for more detailed configuration of USB storage devices, including identification of specific media.
Do I need to create a new rule after changing the trigger?
No. The parameters of an existing trigger can be changed by editing the rule.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://eaclouddoc.eauditor.eu/eacloud-docs-en/features/data-loss-prevention/triggers/how-triggers-work.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
