Automations - Triggers

Package: BASIC

1. Configure Trigger

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

Trigger sidebar

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

• Show actions (icon "three dots") → after clicking, a flyout menu is displayed with the following actions:
  • Edit → After clicking the action "Edit", the popup "Trigger" opens, in which the name, event, a module and the description can be entered or changed.
  • Delete → After clicking the action "Delete", an unconfigured trigger is deleted without further query.
    For already configured triggers: After clicking the action "Delete", a query opens ("Should this node really be deleted? Subsequent nodes may be reset as a result if they lose the module binding of a trigger."), 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 action icon "arrow with vertical bar"
• Toggle automation active/inactive → using the toggle, the trigger can be set to active/inactive

1.1. Trigger Step 1 - Select Event and Module

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

Popup Trigger

The following fields are available in the popup "Trigger":

• Individual name → Enter 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 following events are available as triggers in the selection list:

  • Attachment added → An attachment has been added to a record in a system-integrated upload area.
    Note: This trigger relates exclusively to system-integrated upload areas, such as those present in the Wiki module. Custom upload fields and regular file fields in a record do not trigger this trigger. For file changes in such fields, the triggers "Record saved" or "Record changed" should be used.

    In the condition configuration, in addition to the fields of the triggering record, properties of the file attachment itself are also available for this trigger, 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 changes).
    Note: The trigger "Record saved" is triggered every time a save occurs – regardless of whether a change has taken place, and regardless of whether it is an initial creation or an update. 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 mandatory to avoid unwanted cycles.

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

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

  • Record changed → The record was changed and saved.
    Note: In billing modules (e.g. Invoices, Deals), in addition to the fields of the triggering record and its references, the fields of the item groups (e.g. product or service name) are also available in the condition configuration. This allows conditions to be formulated that react 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 integration DocuSign is active.

  • DocuSeal: Signature received → The recipient of a DocuSeal envelope has signed and the signature was received.
    Note: Only available if the integration DocuSeal is active.

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

  • Billing: Item inserted → An item was inserted in the product block in a record of 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 from the product block in a record of 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 in a record of 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 has received a push in connection with the Jira integration.
    Note: This trigger relates 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.

  • Mandate requested/granted/revoked → Trigger for the payment processing integration
    Note: Only available in the version brainX APP, when the integration Payment Processing is configured and activated.

    • Mandate requested → A mandate request was triggered via the configured payment provider.
    • Mandate granted → The customer confirmed the requested mandate.
    • Mandate revoked → The customer revoked an existing mandate.
      Note: All three mandate triggers are triggered externally: brainX provides a webhook endpoint for each trigger, through which the payment provider transmits status information. The revocation link for mandates can be embedded e.g. in automatically sent emails – as soon as the customer clicks 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: As an "external comment" counts every comment that is created outside the internal comment area – regardless of whether it comes from a customer (e.g. by email) or from a user in the system (e.g. in support). The trigger is fired in both cases.

    In the condition configuration, in addition to the fields of the ticket, the content of the comment and its source are also 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 specifically configured for the respective case – e.g. a notification to the support team for incoming customer inquiries or automatic email sending for an internally recorded response.

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

• For module * → Selection list of modules in which the configured trigger applies.
• Description → Brief description of the trigger (optional)
• Also for changes via → Multi-selection list with the values "API" and "Import/Update" → Configuration of whether the trigger should also apply when the record was changed via API or CSV update. By default, a trigger is exclusively triggered by manual actions in the interface.
  The setting serves to specifically exclude certain automations for external connections (e.g. to avoid unwanted follow-up actions for API calls) or to improve processing speed during large imports when the automation is not needed in this context.
  Note: If triggers are to be triggered by external services that communicate via the brainX API (e.g. DocuSeal), the value "API" must be activated in all involved triggers - including chained subsequent triggers. Otherwise, these triggers will not be fired by the external push.
  The field is only displayed when 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 the conversion (e.g. lead conversion).
  The field is only displayed when 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 when the event "Record converted to" is selected.
• Email mailboxes → Selection of the mailbox (optionally the folder) that should be scanned.
  The field is only displayed when the event "Email scanned" is selected.
• Search for → Multi-selection list with the values "read" and "unread" → Configuration of whether to scan for read and/or unread emails.
  The field is only displayed when the event "Email scanned" is selected.
• After scan → Selection list with the values "no change", "read" and "unread" → Configuration of 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 when the event "Email scanned" is selected.
• Linked module → Selection list of modules selected as the target module of a link (reference).
  The field is only displayed when the event "Link added" is selected.

*Required field

1.2. Trigger Step 2 - Save Trigger

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

1.3. Delete Trigger

By selecting a trigger (by clicking, the border is displayed thick) and pressing the "Delete key", a trigger can be deleted again in the automation editor.
If the trigger is connected to other configured nodes, a popup with the text "Should this node really be deleted? Subsequent nodes may be reset as a result if they lose the module binding of a trigger." is displayed.

2. Practical Examples

1 – Record Created: Automatically create a task when a new lead is saved

A new lead enters brainX and a follow-up task should be created automatically. The trigger Record Created is selected for the Leads module. After configuring the conditions and the action Create Record (module: Tasks), the task is assigned to the responsible team member via the reference field. As soon as a new lead is saved, the automation runs and the task appears in the task list.

2 – Record Changed: Start a DocuSeal signing process via the API field

As soon as the status of a deal changes to Contract, a DocuSeal signing process should be triggered automatically. The trigger Record Changed is used for the Deals module. In Step 2, the field Status is selected as the monitored field. An additional condition checks whether the new value equals Contract. The action sends the request to DocuSeal via Trigger API. The API field in the trigger configuration ensures that the automation only fires when the relevant field actually changes.

3 – Email Scanned: Automatically create a support ticket from an incoming email

Incoming support emails should be automatically converted into records in the Tickets module. The trigger Email Scanned is selected. Subject and body are mapped to the corresponding fields via placeholders. A condition ensures that only emails with a specific subject keyword (e.g. "Support") trigger the automation.

4 – Chained trigger: Create an invoice after an automatic order creation

An automation creates an order from a deal. A second, separate automation uses Record Created for the Orders module and creates the corresponding invoice immediately. The two automations are intentionally kept separate so that each can be activated and tested independently.

3. Frequently Asked Questions

What is the difference between "Record Saved", "Record Created", and "Record Changed"?

Record Saved fires every time a record is saved — whether it is new or existing. Record Created fires only when a record is saved for the first time. Record Changed fires only when an existing record is saved and the monitored field has actually changed compared to its previous value.

What does the API field in the trigger configuration do?

The API field is a checkbox that can be activated to also trigger the automation when the record is changed via the API (e.g. by an external tool). Without this option, API changes are ignored by default.

Can I use multiple modules in a single trigger?

No. Each trigger is assigned to exactly one module. If you want to react to events in multiple modules, create separate automations with a trigger for each module.

Can I change the event or module of an existing trigger?

Yes. Via the Edit action in the trigger sidebar, the popup opens in which the event and module can be adjusted. Note that changing the module may reset already configured conditions and actions.

What does the Active/Inactive toggle in the trigger sidebar do?

The toggle determines whether the trigger — and thus the entire automation — is currently active. Inactive automations are not executed even if the trigger event occurs. New automations are always saved as inactive by default.