Automations - Notes and Tips

Automations can be bound to specific clients:

• Mail scanners that are bound to clients are executed when one of them is permitted for the user whose mailbox is being scanned.
• The client for record creation is automatically determined via the source record. In modules without an explicit client selection, the responsibility or the logged-in user is used.

Changes made by automations are logged accordingly in the change tracking.

By default, triggers are triggered exclusively by manual actions in the user interface. If a trigger should also apply when changes are made via the API or a CSV import/update, this must be explicitly activated in the trigger via the field "Also for changes via".

This is particularly important when external services initiate processes in brainX via the API – for example, push notifications from DocuSeal after a signature is received. In such cases, the value "API" must be activated in all involved triggers of an automation chain – including chained subsequent triggers.

In an action of an automation, a time delay can be configured.

This means that, for example, an email dispatch can be configured such that the email is only sent after a freely definable time delay following the save action.

All actions with a configured time delay are listed in the Scheduled Actions module and can be checked there again and deleted if necessary.

Late payment fees and default interest in automations are only possible for the Invoices module.

Actions allow access to secondary data of the trigger when appropriate. This includes, for example, item fields from billing records.

If errors occur in an automation, these are logged in the log files.

To identify the triggering nodes more easily, nodes are numbered, which are displayed accordingly in the log files.

In an automation, "cycles" refer to repeated processes that are executed in a loop. These cycles can occur in various contexts, such as when processing data, executing tasks, or interacting with users.

Cycles can be problematic when:

1. Infinite loops arise: If a process is designed to execute itself repeatedly without having a condition that stops it, this can lead to system overload.
2. Resource waste: Cycles can consume unnecessary resources, impairing the efficiency of the software.
3. Error-proneness: Complex cycles can be difficult to debug and lead to unexpected errors.

To avoid cycles, the following strategies can be applied:

1. Define conditions: Ensure that each cycle has a clear abort condition that must be met for the process to end.
2. Input controls: Check inputs and conditions to ensure that they do not lead to unexpected cycles.
3. Test and validate: Perform comprehensive tests to ensure that the automation processes work as desired and do not create cycles.

Through these measures, the probability of cycles in an automation can be reduced and the efficiency and stability of the processes improved.

If an automation triggers a cycle, only a single message is output. The affected automation is then marked to indicate that a cycle has occurred since the last save. The marking is lifted as soon as the automation is edited and saved again.

All cycles that have occurred are also logged in a separate log file to enable subsequent analysis. Cycles should generally be avoided as they lead to unnecessary system load.

Due to their range of functions and the variety of possible triggers, conditions and actions, automations are a very "powerful" instrument.

When creating – especially more complex automations – it is recommended to initially execute sensitive actions (e.g. sending invoices, reminders, etc. by email) with a time delay. The emails can then be checked again in the Scheduled Actions module before sending.

If the actions deliver the desired result, the time delay can be reduced or removed.

When creating triggers, conditions and actions, "meaningful", i.e. descriptive, names should always be chosen.

Meaningful names make sense for several important reasons:

• Clearly named triggers, conditions and actions make the automation more understandable. Anyone looking at the complete automation immediately recognizes the context and the process without having to look at the configuration of the individual nodes.
• If changes to the automation are necessary at a later point in time, meaningful names facilitate understanding and adapting the automation.
• If multiple people/users have administrative permissions and are correspondingly permitted to edit automations, this facilitates joint editing.

For the calculation of values in conditions and actions – e.g. elapsed time between two date values – field values are sometimes required that are not available in the standard fields.

In such cases, it is advisable to create fields in the module manager and mark these with the property Additional information.

If the setting "Additional information" has been activated, the field is not available in the main form for data entry, but is displayed in a separate sidebar in the detail view of a record.

In the brainX system, changes in the Global Settings are generally logged (see section Recent Changes). However, not all details of a change are saved.

Before making changes to an automation, it can be saved as a "backup copy" by duplicating/copying it. In this copy, it can be viewed again in detail after changes have been made to the original automation. Via export, an automation can also be saved separately.

Especially for more complex automations, the steps of changes made should possibly also be manually logged by the administrator.