Automations - Triggers

Package: BASIC

1. Trigger configuration

After clicking a trigger in the editor, the "Trigger" sidebar opens.

Trigger sidebar

In the top right of the trigger sidebar there are two action icons, and at the bottom a toggle:

• Show actions (the "three dots" icon) → after clicking, a flyout menu with the following actions is displayed:
  • Edit → After clicking the "Edit" action, the "Trigger" popup opens, in which the name, the event, a module and the description can be entered or changed.
  • Delete → After clicking the "Delete" action, an unconfigured trigger is deleted without any further prompt.
    For already configured triggers: After clicking the "Delete" action, a prompt opens ("Should this node really be deleted? Following nodes may thereby be reset if they lose the module binding of a trigger.") asking whether the trigger should really be deleted. After clicking the "Confirm" button, the trigger is deleted.
• Show/hide sidebar → the sidebar can be shown/hidden by clicking the "arrow with vertical bar" action icon
• Automation active/inactive toggle → the toggle can be used to set the trigger to active/inactive

1.1. Trigger step 1 - choosing the event and module

After a double click on a trigger in the editor - alternatively via the "Edit" action in the trigger's sidebar - the "Trigger" popup opens.

Trigger popup

The "Trigger" popup provides the following fields:

• Individual name → Entry of an individual name for the trigger (optional). If no name is entered, the selected event is used as the name for the trigger.
• Event * → The picklist provides the following events as triggers:

  • Attachment added → An attachment was added to a record in a system-integrated upload area.
    Note: This trigger refers exclusively to system-integrated upload areas, such as those found in the Wiki module. Custom upload fields and regular file fields in a record do not fire this trigger. For file changes in such fields, use the triggers "Record saved" or "Record changed".

    In the condition configuration, this trigger provides, in addition to the fields of the triggering record, properties of the file attachment itself, including file name, file size and file extension (e.g. PDF, DOCX, XLSX). This allows conditions to be formulated that only apply to certain file types.

  • Record created → The record was created (saved for the first time).

  • Record exported → The record was exported (PDF export).

  • Record deleted → The record was deleted.

  • Record saved → The record was saved (even without a change).
    Note: The "Record saved" trigger fires on every save – regardless of whether a change has taken place, and regardless of whether it is an initial creation or an update. Please note: The comparison operator "was changed" is not available in conditions that are evaluated in the context of an initial creation. Careful condition configuration is therefore essential to avoid unwanted cycles.

    It is recommended to use the triggers "Record created" and "Record changed" in a targeted manner instead of using "Record saved", if a clear distinction between initial creation and change is required.

    Note: In Billing modules (e.g. Invoices, Deals), the condition configuration provides, in addition to the fields of the triggering record and its references, also the fields of the item groups (e.g. product or service name). This allows conditions to be formulated that respond to the content of individual items.

  • Record changed → The record was changed and saved.
    Note: In Billing modules (e.g. Invoices, Deals), the condition configuration provides, in addition to the fields of the triggering record and its references, also the fields of the item groups (e.g. product or service name). This allows conditions to be formulated that respond to the content of individual items.

  • Record opened → The record was opened (detail view).

  • Record converted from → The record was converted (e.g. lead conversion).

  • Record converted to → The record was converted into a record in another module (e.g. lead conversion).

  • DocuSign: signature received → The recipient of a DocuSign envelope has signed and the signature was received.
    Note: Only available if the DocuSign integration is active. The fields from the "Envelope for digital signature" block are available as a condition. The same fields can also be selected as the trigger date for delaying actions.

  • DocuSeal: signature received → The recipient of a DocuSeal envelope has signed and the signature was received.
    Note: Only available if the DocuSeal integration is active. The fields from the "Envelope for digital signature" block are available as a condition. The same fields can also be selected as the trigger date for delaying actions.

  • Email scanned → Emails from a definable email account (alternatively including selected folders) were scanned.
    Note: Tickets created by the email scanner adopt the priority of the scanned email.
    Note: For an email account to be available for selection in the Email scanned trigger, it must be enabled for use in Automations in the email account configuration. This setting needs to be set once.

  • Billing: item inserted → An item was inserted in the product block of a record in a Billing module.
    Note: The trigger allows conditions on items:

    • For positive comparisons, at least one item must have the desired value.
    • For negative comparisons, no item may have the comparison value.

  • Billing: item removed → An item was removed in the product block of a record in a Billing module.
    Note: The trigger allows conditions on items:

    • For positive comparisons, at least one item must have the desired value.
    • For negative comparisons, no item may have the comparison value.

  • Billing: item changed → An item was changed in the product block of a record in a Billing module.
    Note: The trigger allows conditions on items:

    • For positive comparisons, at least one item must have the desired value.
    • For negative comparisons, no item may have the comparison value.

  • Jira: push received → The CRM received a push in connection with the Jira integration.
    Note: This trigger refers exclusively to pushes from Jira Software, not from Jira Service Management. Jira Service Management is fully integrated into the ticket management of brainX and therefore has no separate push trigger.

    The Tickets module is available in the module selection, as Jira Software tasks can be stored there. Typically, however, this trigger is used with the Projects or Tasks modules.

  • Appointment: invite/uninvite participant → A participant was invited/uninvited in a record in the Appointments module

  • Appointment: participant status changed → The participant status changed in a record in the Appointments module

  • Mandate request/granted/revoked → Trigger for the Payment Processing integration
    Note: Only available in the brainX APP version, if the Payment Processing integration is configured and enabled.

    • Request mandate → A mandate request was triggered via the configured payment provider.
    • Mandate granted → The customer has confirmed the requested mandate.
    • Mandate revoked → The customer has revoked an existing mandate.
      Note: All three mandate triggers are triggered externally: brainX provides a webhook endpoint for each trigger via which the payment provider transmits status information. The revocation link for mandates can, for example, be embedded in automatically sent emails – as soon as the customer opens this link and revokes the mandate, the corresponding webhook is triggered and the automation is started. The current mandate status can be viewed in the Contracts module in the mandate management (values: open, confirmed, revoked).

  • Ticket: external comment → An external comment was entered in a record in the Tickets module.
    Note: Any comment created outside the internal comment area counts as an "external comment" – regardless of whether it originates from a customer (e.g. by email) or from a user in the system (e.g. in Support). The trigger fires in both cases.

    In the condition configuration, in addition to the ticket fields, the content of the comment as well as its source are available. The source can be used to distinguish whether the comment was created externally (e.g. received by email) or internally (e.g. entered by a user in Support). This allows subsequent actions to be configured specifically for each case – for example, a notification to the Support team when a customer request comes in, or an automatic email send for an internally recorded reply.

  • Link added → A link (reference) was added to a record.

• For module * → Picklist of the modules in which the configured trigger applies.
• Description → Short description of the trigger (optional)
• Also for changes via → Multi-picklist with the values "API" and "Import/Update" → Configuration whether the trigger should also apply if the record was changed via API or CSV update. By default, a trigger is fired exclusively by manual actions in the interface.
  The setting serves to specifically exclude certain automations for external connections (e.g. so that API calls do not trigger unwanted follow-up actions) or to improve processing speed during extensive imports when the automation is not needed in this context.
  Note: If triggers are to be initiated by external services that communicate via the brainX API (e.g. DocuSeal ), the value "API" must be enabled for all involved triggers - including chained follow-up triggers. Otherwise these triggers are not fired by the external push.
  The field is only displayed if the event "Record changed", "Billing: item changed" or "Link added" is selected. The field is only displayed after a module has been selected.
• Target module → Module in which a record was created after conversion (e.g. lead conversion).
  The field is only displayed if the event "Record converted from" is selected.
• Source module → Module in which a record was selected for a conversion (e.g. lead conversion).
  The field is only displayed if the event "Record converted to" is selected.
• Email accounts → Selection of the email account (optionally the folder) to be scanned.
  The field is only displayed if the event "Email scanned" is selected.
• Search for → Multi-picklist with the values "read" and "unread" → Configuration whether to scan for read and/or unread emails.
  The field is only displayed if the event "Email scanned" is selected.
• After the scan → Picklist with the values "no change", "read" and "unread" → Configuration whether a positively scanned email should be marked as read or unread after the scan, or whether no change should be made.
  The field is only displayed if the event "Email scanned" is selected.
• Linked module → Picklist of the modules that were selected as the target module of a link (reference).
  The field is only displayed if the event "Link added" is selected.

*Mandatory field

1.2. Trigger step 2 - saving the trigger

After clicking the "Save" button in the "Trigger" popup, the trigger is saved and displayed in the editor.

1.3. Deleting a trigger

By marking a trigger (by clicking it, the frame is shown as thick) and pressing the "Del key", a trigger can be deleted again in the automation editor.
Should the trigger be connected to other configured nodes, a popup with the text "Should this node really be deleted? Following nodes may thereby be reset if they lose the module binding of a trigger." is displayed.

2. Practical examples

1 – "Record created" trigger for an automatic task on a new lead

In the Leads module, a task for the responsible sales representative should be created automatically for every newly created lead. Record created for the Leads module is chosen as the trigger. Since the action should only apply on initial creation, this trigger is preferable to the Record saved trigger – the latter would fire again on every save of the lead.

2 – "Record changed" trigger with API activation for DocuSeal

An automation should set the status of a deal to won after a digital signature is received via DocuSeal. Since DocuSeal transmits the status change via the brainX API, the Also for changes via field is set to API in the Record changed trigger for the Deals module. Without this setting, the trigger would ignore the external push.

3 – "Email scanned" trigger for automatic ticket creation

Incoming support emails to a dedicated email account should be automatically created as tickets. Email scanned is chosen as the trigger and the corresponding email account is selected. In the Search for field, unread is selected so that only new emails are processed. In the After the scan field, read is set in order to mark processed emails and avoid double processing.

4 – Chained trigger after an automatically created invoice

After the automatic creation of an invoice (the Create record action), the invoice title should be updated with the assigned invoice number. Since the number is only available after the first save, another trigger Record saved for the Invoices module is connected directly to the creation action. This chained trigger is fired exclusively by the upstream action – a manual save by the user does not fire it.

3. Frequently asked questions

What is the difference between "Record saved", "Record created" and "Record changed"?

Record saved fires on every save – regardless of whether a change has taken place. Record created applies exclusively on the initial creation of a record. Record changed is only fired if the record was actually changed and saved. For precise automations, it is advisable to use created and changed in a targeted manner to avoid unwanted cycles.

When do I need to set the "Also for changes via" field to "API"?

Whenever the trigger should be initiated by an external service that communicates via the brainX API – e.g. DocuSeal or DocuSign. Without this activation, brainX ignores the external push. For chained triggers, the API activation must also be set on all follow-up triggers of the same strand.

Can I use the same trigger for multiple modules?

No. Each trigger is bound to exactly one module, which is defined in the For module field. If the same logic should apply to multiple modules, separate automations (or chained strands) are necessary.

What happens if I want to change the event or module of a saved trigger?

As long as the trigger is connected to following nodes, Event and For module cannot be changed. First, all connections to following nodes must be removed before the fields become editable.

What does the "active/inactive" toggle on the trigger do?

It allows an individual trigger within an automation to be deactivated without switching off the entire automation. The trigger is then skipped; all other strands of the automation continue to run.