docs/eca/install.md, docs/eca/usage.md

docs/eca/usage.md

@@ -3,7 +3,8 @@ title: Usage
 ---
 # Using the ECA module
 
-Once installed and configured, the Events - Conditions - Actions (ECA) module operates automatically in the background.
+Once [installed](/eca/install/) and configured, the Events - Conditions - Actions (ECA) module operates automatically
+in the background.
 This page explains how ECA processes models and how to manage them on your site.
 
 ## How ECA works
@@ -26,28 +27,27 @@ ECA continuously processes all enabled models. The module:
 - Matches events to conditions defined in your models
 - Executes the appropriate actions when conditions are met
 
-## Disabling the ECA admin UI on production environments
+## Optionally disabling the ECA admin UI on production environments
 
-ECA doesn't require the UI (`eca_ui`) in order to function.
-We recommend that you turn off the UI and the modeler in production environments.
-
-For production sites, consider this recommended approach:
+ECA doesn't require the `ECA UI module` (`eca_ui`) in order to function.
+Some Drupal administrators may choose to turn off the UI and the modeler in production environments.
+The steps are as follows:
 
 - Create and test ECA models in your development environment
 - Export the models to your production site
 - Enable only ECA and required submodules on production
 - Uninstall the `eca_ui` module on production
 
-This setup allows ECA to operate based on your configured models without exposing the model creation interface to users
-on the production site.
-
-This is similar to the approach that Drupal takes for Views and Fields -
-the user interfaces for those modules can also be disabled when not required.
+Drupal takes a similar approach for Views and Fields -
+the user interfaces for those modules can also be (optionally) disabled.
 
 ## ECA admin UI is separate from the modeler
 
-The ECA admin UI does not, by itself, provide you access to the create or edit models.
-To make the `BPMN.iO` modeler interface available, enable the `bpmn_io` module:
+The ECA admin UI does not, by itself, provide you access to create or edit models.
+To make the `BPMN.iO` modeler interface available, go to Administration > Extend (`/admin/modules`)
+and enable thie `BPMN.iO for ECA` module.
+
+If you are familiar with the command-line, you can use `drush`:
 
 ```
 drush pm:enable bpmn_io
@@ -55,7 +55,7 @@ drush pm:enable bpmn_io
 
 ## Site performance
 
-ECA efficiently subscribes to Drupal events with minimal performance impact.
+ECA dynamically subscribes to all Drupal events which have been defined in the active models on your site.
 The module uses cached information to quickly determine whether an event is relevant to any configured models,
 avoiding unnecessary processing overhead.
 In fact, in our own tests, we have not seen any measurable performance impact, over and above that of the Symfony
@@ -75,6 +75,10 @@ When you save a model using a modeler, ECA recreates the first entity by convert
 Always keep both configuration entities together, as ECA keeps them synchronized.
 Never edit the `.yml` files manually, as the `eca.eca` entity is always regenerated from the `eca.model` entity.
 
+!!! note
+
+    Since the release of ECA version 2.1, you can (optionally) omit the `eca.model.[MODEL-ID]` configuration entity.
+
 ## Administrative interface
 
 The ECA administrative interface is optional and can be enabled separately:
@@ -96,6 +100,8 @@ The `Models` tab allows you to:
 - Enable or disable models: disabled models are not processed by ECA
 - Delete an ECA model entirely from the Drupal site
 - Clone an ECA model with a new random model ID
+- Export an ECA model
+- Export an ECA model as a Drupal Recipe
 
 If the `bpmn_io` module is enabled, you can edit the model in the modeler interface.
 
@@ -123,6 +129,17 @@ Determines where documentation links point when using a modeler.
 The default is <https://ecaguide.org>, but you can change this to your own documentation site,
 or leave it empty to disable documentation links.
 
+#### Execute models with user
+
+Allows you to specify the User ID (`uid`) of the user account that ECA uses to execute models.
+It is recommended to leave this field empty unless you have a good reason to set another user account.
+By default, the current user's account is used to execute models, that works for most use cases.
+
+#### Service account user
+
+The service account is a Drupal user account ECA will switch to when the action "Switch to service user"
+is executed in a model.
+
 ### Logs tab
 
 When the `Database Logging` (`dblog`) module is enabled, you can view ECA log messages through the `Logs` tab: