Automations - Examples

Package: BASIC

1. Examples of Automations

The automations described below are intended to demonstrate, using concrete examples, the variety and flexibility that automations offer in practice.

1.1. Sales Process

The “Sales Process” automation maps the complete process from the creation of a deal, through the creation of a contract and the billing of projects, all the way to the creation of invoices.

Brief description of the process:

• As soon as a deal is set to “won”, a sales order is created automatically.
• After the sales order has been created, a record is created in the Contracts module and the title of the contract is subsequently updated. In addition, the title of the sales order is updated.
• Depending on whether the field “Project Instalments” in the automatically created sales order has the value “yes” or “no”, further nodes follow:
  • Field “Project Instalments” has the value “yes” → an instalment invoice and a (total) invoice are generated, whereby the titles of the invoices are subsequently updated.
  • Field “Project Instalments” has the value “no” → a (total) invoice is generated, whereby the title of the invoice is subsequently updated.

The complete process - consisting of 15 nodes (triggers, conditions and actions) - is presented in the overview as follows:

Overview Sales Process

The exact configuration of the individual triggers, conditions and actions can be found in the following screenshots and descriptions.

1.1.1. Deal is saved (Trigger)

The automation begins with the saving of a record in the Deals module (trigger).

Connections to nodes before/after:

• before: none
• after: Deal was won (Condition))

Trigger „Deal is saved"

1.1.2. Deal was won (Condition)

The condition for further nodes to be run after a deal has been saved is that the deal has the value “won” in the field “Status”.

Connections to nodes before/after:

• before: Deal is saved (Trigger))
• after: Create Sales Order (Action))

Condition „Deal was won"

1.1.3. Create Sales Order (Action)

If a deal has been created which has the value “won” in the field “Status”, a record is created in the Sales Orders module.

Connections to nodes before/after:

• before: Deal was won (Condition))
• after: Sales Order was created (Trigger))

Action „Create Sales Order"

1.1.4. Sales Order was created (Trigger)

After the creation of a sales order, a further trigger follows.

Connections to nodes before/after:

• before: Create Sales Order (Action))
• after:
  • Create Contract (Action))
  • Update title in Sales Order (Action))
  • Billing with project instalments (Condition))
  • Billing without project instalments (Condition))

Trigger „Sales Order was created"

1.1.5. Create Contract (Action)

Once a sales order has been created, a record is now created in the Contracts module.

Connections to nodes before/after:

• before: Sales Order was created (Trigger))
• after: Contract was saved (Trigger))

Action „Create Contract"

1.1.6. Contract was saved (Trigger)

After the creation of a contract, a further trigger follows.

Connections to nodes before/after:

• before: Create Contract (Action))
• after: Update title in Contract (Action))

Trigger „Contract was saved"

1.1.7. Update title in Contract (Action)

Once a sales order has been created, the title of the newly created record in the Contracts module is now updated.

Connections to nodes before/after:

• before: Sales Order was created (Trigger))
• after: none

Action „Update title in Contract"

For the field “Contract title”, the “Set value” functionality (“Puzzle” icon) is used.

The contract title is composed of the contract no. and the name of the organization, separated by a hyphen.

Set value in the field Contract title

1.1.8. Update title in Sales Order (Action)

Once a sales order has been created, the title of the newly created record in the Sales Orders module is now updated.

Connections to nodes before/after:

• before: Sales Order was created (Trigger))
• after: none

Action „Update title in Sales Order"

For the field “Title”, the “Set value” functionality (“Puzzle” icon) is used.

The title is composed of the sales order no. and the name of the organization, separated by a hyphen.

Set value in the field Title

1.1.9. Billing with project instalments (Condition)

The condition for further nodes to be run after a sales order has been saved is that the sales order has the value “yes” in the field “Project Instalments”.

Connections to nodes before/after:

• before: Sales Order was created (Trigger))
• after:
  • Create first instalment for project (Action))
  • Create one-off invoice (Action))

Condition „Billing with project instalments"

1.1.10. Create first instalment for project (Action)

If a sales order has been created which has the value “yes” in the field “Project Instalments”, a record is now created in the Invoices module.

Connections to nodes before/after:

• before: Billing with project instalments (Condition))
• after: Invoice was saved (Trigger))

Action „Create first instalment for project"

For the field “Due date”, the “Set value” functionality (“Puzzle” icon) is used.

The due date is the current date + 14 days.

Set value for the field Due date

1.1.11. Create one-off invoice (Action)

If a sales order has been created which has the value “yes” in the field “Project Instalments”, a record is now created once in the Invoices module.

Connections to nodes before/after:

• before: Billing with project instalments (Condition))
• after: Invoice was saved (Trigger))

Action „Create one-off invoice"

For the field “Due date”, the “Set value” functionality (“Puzzle” icon) is used.

The due date is the current date + 14 days.

Set value for the field Due date

1.1.12. Billing without project instalments (Condition)

The condition for further nodes to be run after a sales order has been saved is that the sales order has the value “no” in the field “Project Instalments”.

Connections to nodes before/after:

• before: Sales Order was created (Trigger))
• after: Create total invoice (Action))

Condition „Billing without project instalments"

1.1.13. Create total invoice (Action)

If a sales order has been created which has the value “no” in the field “Project Instalments”, a record is now created once in the Invoices module.

Connections to nodes before/after:

• before: Billing without project instalments (Condition)))
• after: Invoice was saved (Trigger))

Action „Create total invoice"

For the field “Due date”, the “Set value” functionality (“Puzzle” icon) is used.

The due date is the current date + 14 days.

Set value for the field Due date

1.1.14. Invoice was saved (Trigger)

After the creation of an invoice, a further trigger follows.

Connections to nodes before/after:

• before:
  • Create first instalment for project (Action))
  • Create one-off invoice (Action))
  • Create total invoice (Action))
• after: Update title in the Invoice (Action))

Trigger „Invoice was saved"

1.1.15. Update title in the Invoice (Action)

Once an invoice has been saved, the title of the newly created record in the Invoices module is now updated.

Connections to nodes before/after:

• before: Invoice was saved (Trigger))
• after: none

Action „Update title in the Invoice"

For the field “Title”, the “Set value” functionality (“Puzzle” icon) is used.

The title is composed of the text “Invoice for sales order” and the sales order no.

Set value for the field Title

1.2. Letter salutation

The “Letter salutation” automation automatically creates the values for the field “Letter salutation”, depending on which values are present in the field “Salutation” in the record of the Leads module.

The field “Letter salutation” can be used, for example, as a placeholder in PDF templates or email templates.

Brief description of the process:

• When a record is created in the Leads module, a check is performed on the field “Salutation”. Depending on the result of the check, a corresponding value is written to the field “Letter salutation”.
• When the field “Salutation” or “Last name” is changed in a record of the Leads module, a check is performed on the field “Salutation”. Depending on the result of the check, a corresponding value is written to the field “Letter salutation”.

The complete process - consisting of 14 nodes (triggers, conditions and actions) - is presented in the overview as follows:

Overview Letter salutation

The exact configuration of the individual triggers, conditions and actions can be found in the following screenshots and descriptions.

Since the automation has two parts that are independent of each other, these are also described separately:

• Record was created
• Record was changed

1.2.1. Record was created

1.2.1.1. Record created (Trigger)

The trigger is the creation of a record in the Leads module.

Connections to nodes before/after:

• before: none
• after:
  • Check | Salutation “Mr” (Condition))
  • Check | Salutation “Ms” (Condition))
  • Check | Salutation “--none--” (Condition))

Trigger „Record created"

1.2.1.2. Check | Salutation “Mr” (Condition)

After the record has been created, a check is performed to determine whether the value “Herr” is present in the field “Salutation”.

Connections to nodes before/after:

• before: Record created (Trigger))
• after: Set Letter salutation (Action)))

Condition Salutation „Mr"

1.2.1.3. Set Letter salutation (Action)

If the conditions field “Letter salutation” is empty and field “Salutation” is “Herr” have been fulfilled, a corresponding value is entered in the field “Letter salutation”.

Connections to nodes before/after:

• before: Check | Salutation “Mr” (Condition))
• after: none

Action „Set Letter salutation"

For the field “Letter salutation”, the “Set value” functionality (“Puzzle” icon) is used.

The letter salutation is composed of the text “Sehr geehrter Herr ” and the last name. Note that the word “Herr” is followed by a space.

Set value in the field Letter salutation

1.2.1.4. Check | Salutation “Ms” (Condition)

After the record has been created, a check is performed to determine whether the value “Frau” is present in the field “Salutation”.

Connections to nodes before/after:

• before: Record created (Trigger))
• after: Set Letter salutation (Action))

Condition Salutation „Ms"

1.2.1.5. Set Letter salutation (Action)

If the conditions field “Letter salutation” is empty and field “Salutation” is “Frau” have been fulfilled, a corresponding value is entered in the field “Letter salutation”.

Connections to nodes before/after:

• before: Check | Salutation “Ms” (Condition))
• after: none

Action „Set Letter salutation"

For the field “Letter salutation”, the “Set value” functionality (“Puzzle” icon) is used.

The letter salutation is composed of the text “Sehr geehrte Frau ” and the last name. Note that the word “Frau” is followed by a space.

Set value in the field Letter salutation

1.2.1.6. Check | Salutation “--none--” (Condition)

After the record has been created, a check is performed to determine whether the value “--ohne--” is present in the field “Salutation”.

Connections to nodes before/after:

• before: Record created (Trigger))
• after: Set Letter salutation (Action)))

Condition Salutation „--none--"

1.2.1.7. Set Letter salutation (Action)

If the conditions field “Letter salutation” is empty and field “Salutation” is “--ohne--” have been fulfilled, a corresponding value is entered in the field “Letter salutation”.

Connections to nodes before/after:

• before: Check | Salutation “--none--” (Condition))
• after: none

Action „Set Letter salutation"

For the field “Letter salutation”, the “Set value” functionality (“Puzzle” icon) is not used here; instead the static text “Sehr geehrte Damen und Herren ” is entered. Note that the word “Herren” is followed by a space.

1.2.2. Record was changed

1.2.2.1. Record changed (Trigger)

The trigger is the change of the fields “Salutation” or “Last name” of a record in the Leads module.

Connections to nodes before/after:

• before: none
• after:
  • Check | Salutation “Mr” (Condition))
  • Check | Salutation “Ms” (Condition))
  • Check | Salutation “--none--” (Condition))

Trigger „Record changed"

1.2.2.2. Check | Salutation “Mr” (Condition)

After a record has been changed, a check is performed to determine whether the value in the field “Salutation” is “Herr” and whether the values of the fields “Salutation” or “Last name” have changed.

Connections to nodes before/after:

• before: Record changed (Trigger))
• after: Set Letter salutation (Action))

Condition Salutation „Mr" and „Salutation" or „Last name" was changed

1.2.2.3. Set Letter salutation (Action)

If the conditions value in the field “Salutation” is “Herr” and the values of the fields “Salutation” or “Last name” have changed have been fulfilled, a corresponding value is entered in the field “Letter salutation”.

Connections to nodes before/after:

• before: Check | Salutation “Mr” (Condition))
• after: none

Action „Set Letter salutation"

For the field “Letter salutation”, the “Set value” functionality (“Puzzle” icon) is used.

The letter salutation is composed of the text “Sehr geehrter Herr ” and the last name. Note that the word “Herr” is followed by a space.

Set value in the field Letter salutation

1.2.2.4. Check | Salutation “Ms” (Condition)

After a record has been changed, a check is performed to determine whether the value in the field “Salutation” is “Frau” and whether the values of the fields “Salutation” or “Last name” have changed.

Connections to nodes before/after:

• before: Record changed (Trigger))
• after: Set Letter salutation (Action)))

Condition Salutation „Ms" and „Salutation" or „Last name" was changed

1.2.2.5. Set Letter salutation (Action)

If the conditions value in the field “Salutation” is “Frau” and the values of the fields “Salutation” or “Last name” have changed have been fulfilled, a corresponding value is entered in the field “Letter salutation”.

Connections to nodes before/after:

• before: Check | Salutation “Ms” (Condition))
• after: none

Action „Set Letter salutation"

For the field “Letter salutation”, the “Set value” functionality (“Puzzle” icon) is used.

The letter salutation is composed of the text “Sehr geehrte Frau ” and the last name. Note that the word “Frau” is followed by a space.

Set value in the field Letter salutation

1.2.2.6. Check | Salutation “--none--” (Condition)

After a record has been changed, a check is performed to determine whether the field “Salutation” has been changed and the value “--ohne--” is present.

Connections to nodes before/after:

• before: Record changed (Trigger))
• after: Set Letter salutation (Action))

Condition Salutation „--none--" and „Salutation" was changed

1.2.2.7. Set Letter salutation (Action)

If the conditions field “Salutation” was changed and the value “--ohne--” is present have been fulfilled, a corresponding value is entered in the field “Letter salutation”.

Connections to nodes before/after:

• before: Check | Salutation “--none--” (Condition))
• after: none

Action „Set Letter salutation"

For the field “Letter salutation”, the “Set value” functionality (“Puzzle” icon) is not used here; instead the static text “Sehr geehrte Damen und Herren ” is entered. Note that the word “Herren” is followed by a space.

1.3. New customer – Deal won

The automation “2.0 | New customer – Deal won” maps the complete process following a won new-customer deal: from the automatic creation of sales orders, project, contract and invoices through to the sending of the corresponding documents to the customer.

Design and structure

The automation is deliberately built in a modular way and consists of a main automation as well as two sub-automations:

Automation	Function
2.0 | New customer – Deal won	Main automation: creates sales orders, contract, project and invoices
[2.6 | Send sales order to customer and info to user](/en/global-settings/system-automation/automations/automations-examples#1.3.8.-sub-automation:-2.6-	-send-sales-order-to-customer-and-info-to-user)
[7.1 | Billing – Invoice dispatch process](/en/global-settings/system-automation/automations/automations-examples#1.3.9.-sub-automation:-7.1-	-billing-–-invoice-dispatch-process)

The sub-automations are deliberately separated out so that they can also be reused in other processes (e.g. existing customer, project process).

Overview „2.0 | New customer – Deal won"

Brief description of the process

The process starts as soon as a deal is marked as won – either through a digital signature (via DocuSign or DocuSeal) or by manually setting the status to won.

Several strands then run in parallel:

• The organization is set to the type Customer.
• Two sales orders are created:
  • Sales order 1 contains the standard positions (hardware, subscription, service, extra services).
  • Sales order 2 contains exclusively customizing positions and serves as the basis for the customizing project.
• A contract is created based on the subscription positions; a contract statement is sent to the customer by email.
• A project is created based on the customizing sales order; depending on the configured instalment plan, one or more invoices are generated.
• A one-off invoice is created for non-project-related one-off positions.
• The sub-automations handle the dispatch of the order confirmation and the invoice.

The descriptions of the nodes have been divided into thematic areas:

• Process start and triggers
• Digital signature process
• Process switch: manual vs. digital
• Sales order creation
• Contract strand
• One-off invoice strand
• Project strand and billing

Difference: Digital signature vs. manually won

A central feature of the automation is the distinction between two triggering paths:

	Digital signature (DocuSign / DocuSeal)	Manually set to won
Detection	Field Signature process started on is not empty	Field Signature process started on is empty
Position transfer into sales order	Only positions with the checkbox Ordered position (selected by the customer in the quote)	All positions in the deal
Feedback to user	Notification (bell), as the process can run in the background at any time	Notice box (success message directly in the UI), as a user is actively sitting in front of the screen

Instalment plan for the customizing project

If a customizing project is part of the deal, the billing type is determined based on the stored instalment plan:

Instalment plan	Invoice type
No instalment plan available	Standard invoice (100 %)
Instalment plan available (e.g. 50/50, 40/30/30)	Instalment invoices with configurable percentage

For instalment invoices, it can additionally be selected whether the instalment is applied to the quantity or to the price:

• Instalment on quantity (default): the price remains stable, the quantity is reduced proportionally. Example: 40 hours × €220 → first instalment invoice: 20 hours × €220.
• Instalment on price: the quantity remains stable, the price is reduced proportionally. Example: 40 hours × €220 → first instalment invoice: 40 hours × €110.

Title update (two-stage process)

Titles of sales orders and invoices that are to contain the record number are updated downstream: the number is only assigned after the record has been saved for the first time. For this reason, the record is first saved, and in a second step – triggered by a dedicated checkbox (Update title) – the title is populated with the number.

1.3.1. Process start and triggers

1.3.1.1. Save deal (Trigger - #1)

Reacts to every save of a deal record. This trigger is the entry point for the manual process path (deal is manually set to won). The downstream condition #2 filters whether the relevant criteria are met.

Connections to nodes before/after:

• before: none
• after: Deal won - new customer without digital envelope (Condition - #2)))

Save deal (Trigger - #1)

1.3.1.2. DocuSign: Signature received (Trigger - #52)

Triggered as soon as DocuSign reports a completed signature back to brainX. Starts the digital process path for new customers who have signed a quote via DocuSign.

Connections to nodes before/after:

• before: none
• after: New customer filter (Condition - #59)))

DocuSign: Signature received (Trigger - #52)

1.3.1.3. DocuSeal: Signature received (Trigger - #68)

Triggered as soon as DocuSeal reports a completed signature back to brainX. Works analogously to #52, but for quotes that were sent for signature via DocuSeal.

Connections to nodes before/after:

• before: none
• after: New customer filter (Condition - #59)))

DocuSeal: Signature received (Trigger - #68)

1.3.2. Digital signature process

1.3.2.1. New customer filter (Condition - #59)

Checks whether the deal signed via DocuSign or DocuSeal is of the type new customer. Only if this condition is met is the process continued and the deal set to won in action #54.

Connections to nodes before/after:

• before:
  • DocuSign: Signature received (Trigger - #52)))
  • DocuSeal: Signature received (Trigger - #68)))
• after: Deal won (Action - #54)))

New customer filter (Condition - #59)

1.3.2.2. Deal won (Action - #54)

Sets the status of the deal to won. This action is only required in the digital signature process in order to bring the deal, after signing, into the same state that is already assumed in the manual path.

Connections to nodes before/after:

• before: New customer filter (Condition - #59)))
• after: Record saved (Trigger - #55)))

Deal won (Action - #54)

1.3.2.3. Record saved (Trigger - #55)

Reacts to the save of the deal set to won, triggered by action #54. Serves as a link between the digital signature process and the further process flow from condition #56.

Connections to nodes before/after:

• before: Deal won (Action - #54)))
• after: Deal won - new customer with digital envelope (Condition - #56)))

1.3.3. Process switch: manual vs. digital

1.3.3.1. Deal won - new customer without digital envelope (Condition - #2)

Checks whether the deal was manually set to won, recognizable by the fact that the field Signature process started on is empty. If it applies, the actions #36, #3 and #22 are triggered in parallel.

Connections to nodes before/after:

• before: Save deal (Trigger - #1)))
• after:
  • Field change Organization - Type (Action - #36)))
  • Create Sales Order (1) (Action - #3)-(action-#3))-erstellen-(aktion---%233))
  • Create Sales Order (2) (Action - #22)-(action-#22))-erstellen-(aktion---%2322))

Deal won - new customer without digital envelope (Condition - #2)

1.3.3.2. Deal won - new customer with digital envelope (Condition - #56)

Checks whether the deal was signed via a digital envelope (DocuSign or DocuSeal), recognizable by the fact that the field Signature process started on is not empty. If it applies, the actions #36, #57 and #58 are triggered in parallel.

Connections to nodes before/after:

• before: Record saved (Trigger - #55)))
• after:
  • Field change Organization - Type (Action - #36)))
  • Create digital signature sales order (1) (Action - #57)-(action-#57))-erstellen-(aktion---%2357))
  • Create digital signature sales order (2) (Action - #58)-(action-#58))-erstellen-(aktion---%2358))

Deal won - new customer with digital envelope (Condition - #56)

1.3.3.3. Field change Organization - Type (Action - #36)

Updates the type of the linked organization to Customer. Is executed in both the manual and the digital process path as soon as the deal is considered won.

Connections to nodes before/after:

• before:
  • Deal won - new customer without digital envelope (Condition - #2)))
  • Deal won - new customer with digital envelope (Condition - #56)))
• after: none

Field change Organization - Type (Action - #36)

1.3.4. Sales order creation

1.3.4.1. Create Sales Order (1) (Action - #3)

Creates the first sales order (standard sales order) in the manual process path. Contains the position groups hardware, subscription, service and extra services. All positions of the deal are transferred, as no filtering by ordered positions takes place.

Connections to nodes before/after:

• before: Deal won - new customer without digital envelope (Condition - #2)))
• after:
  • Record saved (Trigger - #5)))
  • Record saved (Trigger - #9)))

Create Sales Order (1) (Action - #3)

1.3.4.2. Create Sales Order (2) (Action - #22)

Creates the second sales order (customizing sales order) in the manual process path. Contains exclusively the customizing position group and serves as the basis for the customizing project as well as the associated instalment invoices.

Connections to nodes before/after:

• before: Deal won - new customer without digital envelope (Condition - #2)))
• after: Record saved (Trigger - #27)))

Create Sales Order (2) (Action - #22)

1.3.4.3. Create digital signature sales order (1) (Action - #57)

Creates the first sales order (standard sales order) in the digital process path. Only transfers positions for which the checkbox Ordered position is set, i.e. those positions that the customer actively selected in the quote.

Connections to nodes before/after:

• before: Deal won - new customer with digital envelope (Condition - #56)))
• after:
  • Record saved (Trigger - #5)))
  • Record saved (Trigger - #9)))

Create digital signature sales order (1) (Action - #57)

1.3.4.4. Create digital signature sales order (2) (Action - #58)

Creates the second sales order (customizing sales order) in the digital process path. As with #57, only ordered positions are transferred, but filtered to the customizing position group.

Connections to nodes before/after:

• before: Deal won - new customer with digital envelope (Condition - #56)))
• after: Record saved (Trigger - #27)))

Create digital signature sales order (2) (Action - #58)

1.3.5. Contract strand

1.3.5.1. Record saved (Trigger - #5)

Reacts to the save of the newly created first sales order (from action #3 or #57). Triggers the downstream contract creation process via action #23.

Connections to nodes before/after:

• before:
  • Create Sales Order (1) (Action - #3)-(action-#3))-erstellen-(aktion---%233))
  • Create digital signature sales order (1) (Action - #57)-(action-#57))-erstellen-(aktion---%2357))
• after: Create Contract (Action - #23)))

Record saved (Trigger - #5)

1.3.5.2. Create Contract (Action - #23)

Creates a new contract based on the subscription positions of the deal. Sets contract start and end via Blockly formula, defines the billing type and activates the contract directly.

Connections to nodes before/after:

• before: Record saved (Trigger - #5)))
• after: Save contract (Trigger - #24)))

Create Contract (Action - #23)

1.3.5.3. Save contract (Trigger - #24)

Reacts to the save of the newly created contract. Triggers four parallel follow-up actions: notification in the manual path (#70 and #25), notification in the digital path (#71 and #72), update contract fields (#37) and send contract statement by email (#43).

Connections to nodes before/after:

• before: Create Contract (Action - #23)))
• after:
  • Sales order was created manually (Condition - #70)))
  • Sales order was created via digital envelope (Condition - #71)))
  • Update (Action - #37)))
  • Email contract statement (Action - #43)))

Save contract (Trigger - #24)

1.3.5.4. Sales order was created manually (Condition - #70)

Checks whether the deal underlying the contract was manually set to won. If it applies, a notice is output as a UI success message (#25).

Connections to nodes before/after:

• before: Save contract (Trigger - #24)))
• after: Notice - new contract (Action - #25)))

Sales order was created manually (Condition - #70)

1.3.5.5. Sales order was created via digital envelope (Condition - #71)

Checks whether the deal underlying the contract was signed via a digital envelope. If it applies, a notification (bell) is output (#72).

Connections to nodes before/after:

• before: Save contract (Trigger - #24)))
• after: Notice - new contract (Action - #72)))

Sales order was created via digital envelope (Condition - #71)

1.3.5.6. Update (Action - #37)

Updates selected fields of the newly created contract with post-processing values that could not yet be set during creation (e.g. supplementary contract information via Blockly formula).

Connections to nodes before/after:

• before: Save contract (Trigger - #24)))
• after: none

Update (Action - #37)

1.3.5.7. Email contract statement (Action - #43)

Sends a contract statement to the customer by email. The email summarizes the essential contract data and is automatically sent when a new contract is created in the new-customer process.

Connections to nodes before/after:

• before: Save contract (Trigger - #24)))
• after: none

Email contract statement (Action - #43)

1.3.5.8. Notice - new contract (Action - #25)

Displays a green success message to the user in the UI stating that the contract was created successfully. Is only output in the manual process path, since in this case a user is actively sitting in front of the screen.

Connections to nodes before/after:

• before: Sales order was created manually (Condition - #70)))
• after: none

Notice - new contract (Action - #25)

1.3.5.9. Notice - new contract (Action - #72)

Sends a notification (bell) to the responsible user that the contract was created successfully. Is used in the digital process path, since the processing can take place in the background at any time.

Connections to nodes before/after:

• before: Sales order was created via digital envelope (Condition - #71)))
• after: none

Notice - new contract (Action - #72)

1.3.6. One-off invoice strand

1.3.6.1. Record saved (Trigger - #9)

Reacts to the save of the newly created first sales order (from action #3 or #57). Triggers the one-off invoice strand via action #10, in parallel to #5.

Connections to nodes before/after:

• before:
  • Create Sales Order (1) (Action - #3)-(action-#3))-erstellen-(aktion---%233))
  • Create digital signature sales order (1) (Action - #57)-(action-#57))-erstellen-(aktion---%2357))
• after: Create invoice (without delay) (Action - #10)-(action-#10))-(aktion---%2310))

Record saved (Trigger - #9)

1.3.6.2. Create invoice (without delay) (Action - #10)

Creates a one-off invoice based on the first sales order. All position groups except customizing and subscription are transferred. The invoice is created immediately without delay and thus covers positions to be billed once, such as hardware or setup costs.

Connections to nodes before/after:

• before: Record saved (Trigger - #9)))
• after: none

Create invoice (without delay) (Action - #10)

1.3.7. Project strand and billing

1.3.7.1. Record saved (Trigger - #27)

Reacts to the save of the newly created customizing sales order (from action #22 or #58). Branches into several parallel strands: create project (#30) as well as check of the billing type (#60 to #63) for the first invoice.

Connections to nodes before/after:

• before:
  • Create Sales Order (2) (Action - #22)-(action-#22))-erstellen-(aktion---%2322))
  • Create digital signature sales order (2) (Action - #58)-(action-#58))-erstellen-(aktion---%2358))
• after:
  • Create project (Action - #30)))
  • Billing 100% by sales order (Condition - #60)))
  • Billing 50% by sales order (Condition - #61)))
  • Billing 40% by sales order (Condition - #62)))
  • Billing 30% by sales order (Condition - #63)))

Record saved (Trigger - #27)

1.3.7.2. Create project (Action - #30)

Creates a new customizing project based on the second sales order. Sets default values such as status In planning and type Customizing. The project forms the basis for the project-related billing and later milestone invoices.

Connections to nodes before/after:

• before: Record saved (Trigger - #27)))
• after: Save project (1) (Trigger - #31)-(trigger-#31))-(auslöser---%2331))

Create project (Action - #30)

1.3.7.3. Billing 100% by sales order (Condition - #60)

Checks whether no instalment plan is stored for the customizing sales order. If it applies, a standard invoice for 100 % of the sales order value is created (#64).

Connections to nodes before/after:

• before: Record saved (Trigger - #27)))
• after: Create 100% invoice by sales order (Action - #64)))

Billing 100% by sales order (Condition - #60)

1.3.7.4. Billing 50% by sales order (Condition - #61)

Checks whether a 50/50 instalment plan is stored for the customizing sales order. If it applies, an instalment invoice for 50 % is created (#65).

Connections to nodes before/after:

• before: Record saved (Trigger - #27)))
• after: Create 50% invoice by sales order (Action - #65)))

Billing 50% by sales order (Condition - #61)

1.3.7.5. Billing 40% by sales order (Condition - #62)

Checks whether an instalment plan with 40 % as the first instalment is stored for the customizing sales order. If it applies, an instalment invoice for 40 % is created (#66).

Connections to nodes before/after:

• before: Record saved (Trigger - #27)))
• after: Create 40% invoice by sales order (Action - #66)))

Billing 40% by sales order (Condition - #62)

1.3.7.6. Billing 30% by sales order (Condition - #63)

Checks whether an instalment plan with 30 % as the first instalment is stored for the customizing sales order. If it applies, an instalment invoice for 30 % is created (#67).

Connections to nodes before/after:

• before: Record saved (Trigger - #27)))
• after: Create 30% invoice by sales order (Action - #67)))

Billing 30% by sales order (Condition - #63)

1.3.7.7. Create 100% invoice by sales order (Action - #64)

Creates a standard invoice of the type Standard for 100 % of the customizing sales order value. Is used when no instalment plan is available and the entire amount is billed immediately.

Connections to nodes before/after:

• before: Billing 100% by sales order (Condition - #60)))
• after: none

Create 100% invoice by sales order (Action - #64)

1.3.7.8. Create 50% invoice by sales order (Action - #65)

Creates an instalment invoice for 50 % of the customizing sales order value. By default, the instalment is applied to the quantity (the price remains stable, the quantity is halved).

Connections to nodes before/after:

• before: Billing 50% by sales order (Condition - #61)))
• after: none

Create 50% invoice by sales order (Action - #65)

1.3.7.9. Create 40% invoice by sales order (Action - #66)

Creates an instalment invoice for 40 % of the customizing sales order value. By default, the instalment is applied to the quantity.

Connections to nodes before/after:

• before: Billing 40% by sales order (Condition - #62)))
• after: none

Create 40% invoice by sales order (Action - #66)

1.3.7.10. Create 30% invoice by sales order (Action - #67)

Creates an instalment invoice for 30 % of the customizing sales order value. By default, the instalment is applied to the quantity.

Connections to nodes before/after:

• before: Billing 30% by sales order (Condition - #63)))
• after: none

Create 30% invoice by sales order (Action - #67)

1.3.7.11. Save project (1) (Trigger - #31)

Reacts to the save of the newly created project (action #30). Triggers three parallel follow-up actions: status check for full billing (#80), notification in the manual path (#76 and #32) and notification in the digital path (#77 and #78).

Connections to nodes before/after:

• before: Create project (Action - #30)))
• after:
  • When the sales order is billed directly at 100% (Condition - #80)))
  • Sales order was created manually (Condition - #76)))
  • Sales order was created via digital envelope (Condition - #77)))

Save project (1) (Trigger - #31)

1.3.7.12. When the sales order is billed directly at 100% (Condition - #80)

Checks whether no instalment plan is stored (100 % billing). If it applies, the project is directly marked as fully billed via action #81, since no further instalment invoices follow.

Connections to nodes before/after:

• before: Save project (1) (Trigger - #31)-(trigger-#31))-(auslöser---%2331))
• after: Set the status in the project to fully billed (Action - #81)))

When the sales order is billed directly at 100% (Condition - #80)

1.3.7.13. Sales order was created manually (Condition - #76)

Checks whether the project originated from a deal that was manually set to won. If it applies, the user is shown a notice as a UI success message that the project was created (#32).

Connections to nodes before/after:

• before: Save project (1) (Trigger - #31)-(trigger-#31))-(auslöser---%2331))
• after: Notice - New project (Action - #32)))

Sales order was created manually (Condition - #76)

1.3.7.14. Sales order was created via digital envelope (Condition - #77)

Checks whether the project originated from a digitally signed deal. If it applies, a notification (bell) is sent to the responsible user (#78).

Connections to nodes before/after:

• before: Save project (1) (Trigger - #31)-(trigger-#31))-(auslöser---%2331))
• after: Notice - New project (Action - #78)))

Sales order was created via digital envelope (Condition - #77)

1.3.7.15. Set the status in the project to fully billed (Action - #81)

Sets the fully billed flag in the project. Is only triggered when no instalment plan is available (100 % billing), since in this case the first and only invoice covers the entire sales order value.

Connections to nodes before/after:

• before: When the sales order is billed directly at 100% (Condition - #80)))
• after: none

Set the status in the project to fully billed (Action - #81)

1.3.7.16. Notice - New project (Action - #32)

Displays a green success message to the user in the UI that the customizing project was created successfully. Is only output in the manual process path.

Connections to nodes before/after:

• before: Sales order was created manually (Condition - #76)))
• after: none

Notice - New project (Action - #32)

1.3.7.17. Notice - New project (Action - #78)

Sends a notification (bell) to the responsible user that the customizing project was created successfully. Is used in the digital process path.

Connections to nodes before/after:

• before: Sales order was created via digital envelope (Condition - #77)))
• after: none

Notice - New project (Action - #78)

1.3.8. Sub-automation: 2.6 | Send sales order to customer and info to user

This sub-automation is triggered for each created sales order (Sales order 1-(action-#3)) and Sales order 2-(action-#22))) via the checkbox Begin dispatch process. It performs two tasks:

1. Update title: The sales order title is populated with the sales order number (after the first save, so that the number has already been assigned).
2. Send order confirmation: The order confirmation is sent to the customer by email with an attached PDF. Subsequently, the checkbox Begin dispatch process is reset so that the sub-automation is not triggered again.

Overview „2.6 | Send sales order to customer and info to user

1.3.9. Sub-automation: 7.1 | Billing – Invoice dispatch process

This sub-automation is triggered for each created invoice via the checkbox Begin dispatch process. It performs the following tasks:

1. Update title: The invoice title is populated with the invoice number.
2. Send invoice: The invoice is sent to the customer by email with an attached PDF. Optionally, a delayed dispatch can be configured (e.g. 1 hour or 1 day).
3. Update status: The invoice status is set to sent; the automatic dunning run is activated.
4. Reset dispatch process: The checkbox Begin dispatch process is reset.

Overview 7.1 | Billing - Invoice dispatch process

1.4. Billing – Dunning process

The automation “7.0 | Billing – Dunning process" monitors open invoices and, in the event of non-payment, automatically carries out up to three payment reminders (PR). The stages build up sequentially on one another.

Design and structure

The automation consists of two triggers and several condition and action strands:

Node no.	Name	Type
#1)	Dunning schedule	Trigger (Invoices module)
#2)	Invoice open?	Condition (1 group, 3 conditions)
#3-(aktion---%233))	Sends 1st PR (external)	Action – Send email
#4)	Update PR information	Action – Update record
#6-(aktion---%236))	Sends 2nd PR (external)	Action – Send email
#7)	Update M2 information	Action – Update record
#8-(aktion---%238))	Sends 3rd PR (external)	Action – Send email
#9)	Update 3rd PR	Action – Update record
#13)	Invoice is saved	Trigger (Invoices module)
#14)	Info to accounting before 2nd PR	Action – Send notification
#16)	Info to accounting before 3rd PR	Action – Send notification
#19)	Invoice open after PR?	Condition (1 group, 4 conditions)
#20)	Invoice open 2nd PR?	Condition (1 group, 4 conditions)
#21)	Insert dunning fee	Action – Add position
#22)	Invoice open?	Condition (1 group, 1 condition)

Overall overview of the automation

Overview 7.0 | Billing – Dunning process

1.4.1. Trigger: Dunning schedule (Trigger - #1)

The first trigger starts the dunning process for an invoice. It is triggered by a defined point in time or an event in the Invoices module and initiates the first payment reminder strand.

Connections to nodes before/after:

• before: none
• after: Invoice open? (Condition - #2))

1.4.2. Invoice open? (Condition - #2)

The condition checks, using 3 criteria, whether the invoice is still open and a first payment reminder should be sent (e.g. status not paid, dunning run active, due date exceeded).

Connections to nodes before/after:

• before: Dunning schedule (Trigger - #1))
• after (condition met): Sends 1st PR (external) (Action - #3)-(aktion---%233))
• after (condition not met): no further actions

1.4.3. Sends 1st PR (external) (Action - #3)

If the invoice is open, the first payment reminder is sent to the customer (external) by email.

Connections to nodes before/after:

• before: Invoice open? (Condition - #2))
• after: Update PR information (Action - #4))

1.4.4. Update PR information (Action - #4)

After the first payment reminder has been sent, the invoice record is updated – e.g. send status, date of the payment reminder.

Connections to nodes before/after:

• before: Sends 1st PR (external) (Action - #3)-(aktion---%233))
• after: none (the next stage is controlled by the trigger “Invoice is saved (Trigger - #13))”)

1.4.5. Trigger: Invoice is saved (Trigger - #13)

The second trigger fires on every save of an invoice. It controls the follow-up stages of the dunning process (2nd and 3rd payment reminders) as well as the accounting notifications.

Connections to nodes before/after:

• before: none (standalone trigger)
• after: Invoice open? (Condition - #22)), Invoice open after PR? (Condition - #19)), Invoice open 2nd PR? (Condition - #20))

1.4.6. Invoice open? (Condition - #22)

A simple condition with 1 check criterion that checks whether the invoice is still open. Controls the further process flow after saving.

Connections to nodes before/after:

• before: Invoice is saved (Trigger - #13))
• after (met): Info to accounting before 2nd PR (Action - #14)) or Info to accounting before 3rd PR (Action - #16))
• after (not met): no further actions

1.4.7. Invoice open after PR? (Condition - #19)

Checks, using 4 criteria, whether the invoice is still open after the first payment reminder and whether the second payment reminder should be triggered.

Connections to nodes before/after:

• before: Invoice is saved (Trigger - #13))
• after (met): Sends 2nd PR (external) (Action - #6)-(aktion---%236))
• after (not met): no further actions

1.4.8. Invoice open 2nd PR? (Condition - #20)

Checks, using 4 criteria, whether the invoice is still open after the second payment reminder and whether the third payment reminder (with dunning fee) should be triggered.

Connections to nodes before/after:

• before: Invoice is saved (Trigger - #13))
• after (met): Insert dunning fee (Action - #21))
• after (not met): no further actions

1.4.9. Info to accounting before 2nd PR (Action - #14)

Before the second payment reminder is sent to the customer, accounting receives an internal notification that the next dunning stage is imminent.

Connections to nodes before/after:

• before: Invoice open? (Condition - #22))
• after: none (the actual 2nd PR is controlled by condition 19)

1.4.10. Info to accounting before 3rd PR (Action - #16)

In line with the logic of node 14, accounting receives an internal notification before the third payment reminder (with dunning fee) is carried out.

Connections to nodes before/after:

• before: Invoice open? (Condition - #22))
• after: none (the actual 3rd PR is controlled by condition 20)

1.4.11. Sends 2nd PR (external) (Action - #6)

If the condition “Invoice open 2nd PR? (Condition - #20))” is met, the second payment reminder is sent to the customer by email.

Connections to nodes before/after:

• before: Invoice open after PR? (Condition - #19))
• after: Update M2 information (Action - #7))

1.4.12. Update M2 information (Action - #7)

After the second payment reminder has been sent, the invoice record is updated – e.g. send status, date of the second payment reminder.

Connections to nodes before/after:

• before: Sends 2nd PR (external) (Action - #6)-(aktion---%236))
• after: none

1.4.13. Sends 3rd PR (external) (Action - #8)

If the condition “Invoice open 2nd PR? (Condition - #20))” is met, the third payment reminder is sent to the customer by email. This stage additionally contains a dunning fee (see Insert dunning fee (Action - #21))).

Connections to nodes before/after:

• before: Insert dunning fee (Action - #21))
• after: Update 3rd PR (Action - #9))

1.4.14. Insert dunning fee (Action - #21)

Before the third payment reminder is sent, a dunning fee is inserted into the invoice as a new position. A predefined product is used for this (e.g. “Dunning fee” with a fixed amount). Alternatively, default interest can be calculated.

Connections to nodes before/after:

• before: Invoice open 2nd PR? (Condition - #20))
• after: Sends 3rd PR (external) (Action - #8)-(aktion---%238))

1.4.15. Update 3rd PR (Action - #9)

After the third payment reminder has been sent, the invoice record is updated – e.g. send status, date of the third payment reminder.

Connections to nodes before/after:

• before: Sends 3rd PR (external) (Action - #8)-(aktion---%238))
• after: none