Skip to main content

Celonis Product Documentation

O2C: Update Delivery Dates
Overview

Use Case Name

Update delivery dates for customer sales orders with requested dates in the next few days

Execution Capacity

Reduce manual effort, increase first time right, improve customer satisfaction

Process / Data Model

Order-to-Cash data model

Semi-/Fully automated

Fully automated

Systems

SAP ECC or S/4HANA, Email (SMTP)

SAP TCode in GUI

VA02 (Change Sales Order)

Updated SAP field

VBAK.VDATU → requested delivery date value will be updated based on material availability

Execution Gap

Customers may place orders that have unrealistic requested delivery dates -- delivery dates that are only a few days away. It is important to identify these at-risk orders quickly in order to determine whether or not the requested delivery dates can be met.

If the dates can be met, then there is no action required, and the customer should receive their order on the date that they requested. If, however, the requested delivery dates cannot be met, then the delivery dates need to be updated in the system of record (SAP), and the customer needs to be notified that their order will arrive later than requested.

In many instances, the above tasks are completed manually, resulting in unnecessary manual effort, increased error rates, and occasional rework.

Additionally, orders with short lead times are unlikely to be delivered on time. As such, any solution that automates the process of identifying problem orders, updating their delivery dates, and communicating these changes to customers will result in reduced express shipping costs, increased on-time delivery rates, improved first-time-right performance, and an overall boost to customer satisfaction.

Business Case Calculation

Let’s look at a customer that receives 3,000 sales orders per day. If we assume that 10% of these orders have a requested delivery date in the next 3 days, then we need to adjust the delivery dates of 300 orders per day. If each one of these date changes takes 2 minutes to complete, then we spend a total of 600 minutes (or 10 hours) each day adjusting delivery dates in SAP.

Once these dates are adjusted, the customer must be notified of the change to their orders’ delivery dates. If the 300 orders updated each day correspond to 150 unique customers, then updates must be distributed via email to each one of these customers daily. If we assume that it takes 15 minutes to collect the relevant information and compile it into an email for each customer, then we spend a total of 2,250 minutes (or 37.5 hours) each day notifying customers of their relevant delivery date changes.

If we assume that the all-in annual cost of a full-time employee (FTE) is $75,000, then the approximate hourly cost per employee is $37.50. As such, automating the above SAP updates and email actions will save an estimated $440,000 per year in FTE costs alone.

If we also consider the possibility that today, some of these orders are shipped as express items to meet the customer’s requested delivery dates, then additional savings could be realized by reducing the number of express orders shipped each day.

Lastly, automating this operation will also have a direct, measurable impact on important metrics like “first time right” and customer satisfaction scores.

Customer Example

During the COVID-19 pandemic, one Celonis customer noticed that they were receiving a large number of sales orders with extremely short lead times. That is, the requested delivery dates on these orders were only a few days after the dates on which the orders were placed. These sales orders need to be checked manually to identify which delivery dates could be met, and which orders would have to be delayed.

Once the order management clerks had identified orders with unrealistic requested delivery dates, they needed to manually update the delivery schedules in SAP. Additionally, they needed to notify the respective customers (via email or other methods) that their original delivery dates could not be met, and that their orders had been updated with new delivery dates.

Due to a large number of these kinds of orders, the Celonis customer wasn’t able to effectively identify and correct these delivery date issues manually. As such, they approached Celonis regarding possible solutions that could solve the problem whilst reducing manual effort, lowering express shipping costs, improving on-time delivery performance, and continuing to delight their customers.

Customer Solution

Celonis can be used to automatically identify orders that have unrealistic requested delivery dates. The EMS can continuously scan your incoming sales orders to identify those that match certain customer-specific criteria.

For example, new sales documents (those that were created today) with short lead times (requested delivery date is less than 3 days away) can be automatically detected by Action Engine. If there are other relevant criteria (sales organizations, order types, specific customers, etc.) these can be included in the scanning criteria as well.

Once these orders have been identified, a new delivery date is calculated based on the underlying business logic related to material availability and reasonable delivery schedules. Accordingly, the schedule line dates for these sales documents are automatically updated, directly in the SAP source system.

The updated delivery details for all adjusted orders are aggregated by a customer, and emails are sent out twice per day to notify the relevant customers of their delayed deliveries.

41195669.png

Why Celonis EMS Automation?

The first striking advantage is that the advanced business logic for auto-updating delivery dates can easily be created and adjusted by the customer’s business analysts without the need for technical ABAP development. In the customer example, one crucial condition was to look at sales orders that had customer requested delivery dates less than 3 days from the order creation date. This condition refers to the entire history of a single sales order. While it’s easy to describe this condition using Celonis’ Process Query Language (PQL), it’s cumbersome to implement it in SAP and would require SAP developer knowledge. As a second compelling advantage, the customer stated that it is not possible to implement the desired granular logic on source system level.

Required IT Architecture

The IT architecture required to successfully implement this automation use case can be found on the following help page.

Project Timeline & Effort

The recommended timeline, milestones and project members needed to successfully implement this automation use case can be found on the following help page.

Technical Setup

The table below shows the technical setup steps required to configure this use case successfully.

Note

It is strongly recommended that the use case package import and business logic configuration & validation are tackled in parallel to the SAP integration setup.

Step

Documentation

Who

Effort

Update extractor to real-time extractor

Installation Guide

IT Contact

Data Scientist

2 h

Install Celonis on-prem Agent and set to automatic start

Installation Guide

IT Contact

Data Scientist

2 h

Import SAP transport for credit release action

SAP Automation Package

IT Contact

2 h

Create technical SAP user with required permissions

Installation Guide

IT Contact

2 h

Set up SMTP server for email actions

Installation Guide

IT Contact

2 h

Import Use Case Package

The following import guide contains instructions for importing the Action Engine and Studio Skills for this automation use case.

The relevant use case package can be downloaded using the following download link.

  • Automation Use Case Package (download package)

Template Building Blocks

After importing the package (see technical setup above), you will find the following building blocks in your EMS team. The vast majority of the Data Scientist person-days indicated in the project setup table above is allocated to customizing these building blocks and adjusting the business logic to the customer’s needs.

1. Identify Orders with Short Delivery Lead Times
41195671.png
Action Engine Skill

Action Engine Skills work by scanning all relevant records (e.g. sales orders) for certain rules and criteria whenever the underlying data model is reloaded. These Action Engine Skills trigger actions and automations that are defined in associated Studio Skills.

This action Engine Skill will check all incoming sales orders (the Signal ID), and will flag those with upcoming requested delivery dates in the near future.

Signal ID

The Signal ID is the object or record on which the use case is based. In this use case, a new Signal is generated for eachSales Document ("VBAK"."VBELN")that contains an item with an unrealistic requested delivery date.

Customer Example

The Action Engine Skill identifies sales orders with requested delivery dates ("VBAK"."VDATU") less than 3 days after order creation date ("VBAK"."ERDAT"), as it will be difficult to deliver these orders on the dates requested. In turn, associated Studio Skills are triggered to define realistic new delivery dates for these orders in SAP, and to automatically notify customers of these changes via email. See the use case description for further details.

Skill Filters

Action Engine Skills are configured through a set of filters that apply to a particular data model. Usually, a combination of different types of filters are used to define an Action Engine Skill. These can be organizational filters (referring to particular sales organizations or customer groups), process flow filters (related to cycle times, process events and conditions), or record attribute filters (order-specific criteria like document types or credit statuses).

Below, you will find a collection of filters and considerations for identifying orders with unrealistic requested delivery dates.

Organizational Filters

Organizational filters are those that define the organizational scope of the Action Engine Skill (e.g. company codes, sales organizations, sales groups, profit centers, and other custom criteria).

Sales groups and organizations

Different sales groups or organizational units may have unique delivery and lead time requirements. They may also rely on bespoke business rules or filter logic to identify at-risk orders.

Example filters:

  • FILTER "VBAK"."VKORG" IN ('ABC', 'DEF');

    -- Sales Organization is ABC or DEF

  • FILTER "VBAK"."VKBUR" IN ('UVW', 'XYZ');

    -- Sales Group is UVW or XYZ

  • FILTER "VBAP"."PRCTR" IN ('123', '456');

    -- Profit Center is 123 or 456

Additional remarks:

  • For these kinds of filters, it’s often easiest to use the Column Fiter in Action Engine to define the required organizational conditions for the Skill.

Particular customers

Particular customers or client groups may have unique delivery and lead time requirements. They may also rely on bespoke business rules or filter logic to identify at-risk orders.

Example filters:

  • FILTER NOT "VBAK"."KUNNR" IN ('123', '456');

    -- Customer Number is not 123 or 456

Order not already updated

Changes to order delivery dates can be written back to the Celonis data model to ensure that they are only updated and communicated once. This ensures that orders are only updated when necessary, and that customers always receive relevant, up-to-date information about their deliveries.

Example filters:

  • FILTER NOT ("VBAK"."VBELN" IN ("OUTBOX"."SALES_DOCUMENT"));

    -- Delivery dates for sales documents ("VBAK"."VBELN") have not already been updated and stored in the Celonis "OUTBOX" table

Additional remarks:

  • When a delivery date is changed, the details of that order are written to the "OUTBOX" table. This filter ensures that the details of these orders are only updated once, and that the customer is only notified of these changes once. As a result, delivery date changes are only made and communicated when necessary.

Process Flow Filters

Process flow filters are those that define process-specific conditions for the Action Engine Skill (e.g. filters related to process cycle times, relevant activities, order process flows, and other custom criteria).

Delivery lead times

The time between order creation and the customer’s requested delivery date may determine which orders can be delivered on time, and which will need to be delayed. Short, unrealistic lead times are more likely to be delayed.

Example filters:

  • FILTER DATEDIFF (dd, "VBAK"."ERDAT", "VBAK"."VDATU") < 3;

    -- Requested delivery date ("VBAK"."VDATU") is less than 3 days after order creation date ("VBAK"."ERDAT")

  • FILTER DATEDIFF (hh, "VBAK"."ERDAT", PU_FIRST("VBAK", "VBEP"."MBDAT")) < 72;

    -- Material availability date ("VBEP"."MBDAT") is less than 72 hours after order creation date ("VBAK"."ERDAT")

Additional remarks:

  • A combination of filters related to requested delivery dates, material availability dates, and others may be required to define orders that need to be delayed.

  • There may be instances where delivery dates may need to be adjusted more than once. To account for this, filters may need to be applied to the availability dates of relevant materials.

Recently created orders

The order creation date can be utilized to ensure that the Skill only contains recently created orders that are at risk of being delayed. In this case, we filter on orders that were created today or yesterday.

Example filters:

  • FILTER DATEDIFF (dd, "VBAK"."ERDAT", TODAY()) = 0 OR DATEDIFF (dd, "VBAK"."ERDAT", TODAY()) = 1;

    -- Days between order creation date and today is 0 or 1 (order was created today or yesterday)

Additional remarks:

  • For automated Skills that are being executed daily, it may make sense to only filter on orders that have been created recently. This ensures that changes are only made and communicated for new, relevant orders.

  • In addition to filtering on orders that have been created or changed recently, it may also be relevant to only filter on orders that are open.

Record Attribute Filters

Record attribute filters are those that limit the scope of the Action Engine Skill to records (e.g. sales documents) that have particular characteristics (e.g. those with or without particular holds, payment terms, shipping conditions, and other custom criteria).

Document and order types

Different documents or order types may have unique delivery and lead time requirements. They may also rely on bespoke business rules or filter logic to identify at-risk orders.

Example filters:

  • FILTER "VBAK"."AUART" IN ('ABC', 'DEF');

    -- Sales document type ("VBAK"."AUART") is ABC or DEF

  • FILTER "VBAP"."PSTYV" IN ('UVW', 'XYZ');

    -- Sales document item category ("VBAP"."PSTYV") is UVW or XYZ

Shipping conditions

Shipping methods and conditions may determine which orders can be delivered on time, and which will need to be delayed.

Example filters:

  • FILTER NOT ("VBAK"."VSBED" = 'ABC');

    -- Shipping conditions ("VBAK"."VSBED") not ABC

Adjustments and Extensions

You can easily apply business rules and logic to your process data using Celonis PQL. To learn more about PQL, you can leverage the free-of-charge Analyst Training Track in the Celonis Academy. The training tracks for “Analysis Building Basics”, “Basic Coding with PQL”, and “Analysis Building Advanced” will equip you with a deep understanding of the power of PQL.

The business logic in the Action Engine Skill outlined above is completely customizable. For the full list of available actions that can be performed through EMS automation, see EMS Help Page.Actions

2. Update Delivery Date in SAP
41195672.png
Studio Skill

Studio Skills define the actions and system automations that are performed against a record (e.g. sales order) when an Action Engine Skill is triggered.

This Studio Skill updates an order’s delivery date ("VBAK"."VDATU") in SAP when the date requested by the customer cannot be met.

Customer Example

The Studio Skill is triggered by an Action Engine Skill when an order’s requested delivery date is less than 3 days after the order is created. The Studio Skill executes a BAPI or RFC call in the SAP system to update the delivery date of the order.

Skill Configuration

Studio Skills are composed of asensorand one or moreactionsperformed in Celonis or connected IT systems. When an Action Engine Skill is triggered, the sensor executes the system actions defined in the associated Studio Skill. Usually, a combination of different types of actions are defined in the Studio Skill. These can be Celonis actions (query a data model, write data to a table or execute a machine learning script), system actions (apply data filters, process routers, or loops), ERP actions (remove a delivery block in SAP or update an account in Salesforce), communication actions (email a customer or Slack a colleague), and many others.

Below you will find the sequence of actions required to update the delivery date for an order in SAP.

41194944.png

1) Action Engine Sensor

The Action Engine sensor will execute the Studio Skill when the associated Action Engine Skill is triggered.

Example custom inputs:

  • Sales document ("VBAK"."VBELN"): ${b1["sales document"]}

    -- Defines the sales order for which the delivery date will be updated in SAP

  • Sales document item ("VBAP"."POSNR"): ${b1["sales document item"]}

    -- Defines the sales order item for which the delivery date will be updated in SAP

  • Schedule line number ("VBEP"."ETENR"): ${b1["schedule line number"]}

    -- Defines the schedule line for which the delivery date will be updated in SAP

  • Customer number ("VBAK"."KUNNR"): ${b1["customer number"]}

    -- Defines the customer whose order delivery date is being updated

  • Customer name ("KNA1"."NAME1"): ${b1["customer name"]}

    -- Defines the name of the customer whose order is being updated

  • Sales document type ("VBAK"."AUART"): ${b1["sales document type"]}

    -- Defines the document type of the order

  • Shipping conditions ("VBAK"."VSBED"): ${b1["shipping conditions"]}

    -- Defines the shipping conditions of the order

  • Old delivery date ("VBAK"."VDATU"): ${b1["old delivery date"]}

    -- Defines the original customer requested delivery date for the sales order

  • New delivery date: ${b1["new delivery date"]}

    -- Defines the new delivery date for the order

  • Old material availability date ("VBEP"."MBDAT"): ${b1["old material availability date"]}

  • -- Defines the original date on which the ordered material was available for delivery

  • New material availability date: ${b1["new material availability date"]}

    -- Defines the new date on which the ordered material will be available for delivery

  • SAP change date (TODAYT()): ${b1["sap change date"]}

    -- Defines the date and time on which the delivery date was changed in SAP

Additional remarks:

  • Based on your customer’s needs, further input fields may be required. For example, you may need to consider the material availability date, plant details, or shipping conditions in the actions you define.

2) Query Data Model

The Query Data Model action will retrieve defined data fields from a Celonis data model. In this case, we are querying the positions and schedule line details of the order.

Example columns:

  • Sales document ("VBAK"."VBELN"): ${b2["sales document"]}

    -- Defines the sales order for which the delivery date will be updated in SAP

  • Sales document item ("VBAP"."POSNR"): ${b2["sales document item"]}

    -- Defines the sales order item for which the delivery date will be updated in SAP

  • Schedule line number ("VBEP"."ETENR"): ${b2["schedule line number"]}

    -- Defines the schedule line for which the delivery date will be updated in SAP

Example filters:

  • FILTER "VBAK"."VBELN" = '${b1["sales document"]}';

    -- Filter on only this order

  • FILTER "VBAP"."ABGRU" IS NULL;

    -- Order is not canceled

  • FILTER "VBEP"."ETENR" = '0001';

    -- Only the first row of the schedule line

Additional remarks:

  • Based on your customer’s needs, additional fields may need to be queried in the Celonis data model. For example, you may need to query the material availability date for the order in question to determine when the new delivery date should be.

  • Additional filters may be required to meet your customer’s needs. For example, you may need to filter on particular order types, schedule line categories, or material types.

3) Execute SAP Action (Advanced)

The Execute SAP Action step will trigger a BAPI or RFC call in SAP to create or change defined elements (delivery dates, payment terms, order details, etc.) of a business object (sales order, purchase order item, schedule line, etc.).

Example actions:

  • Change Requested Delivery Date (Header Level)

    -- Updates the delivery date for the sales order

  • Change Requested Delivery Date (Position Level)

    -- Updates the delivery date for the sales order item and schedule line

Example input requirements:

  • Sales document

    -- ${b1["sales document"]} ("VBAK"."VBELN")

  • Sales document item

    -- ${b1["sales document item"]} ("VBEP"."ETENR")

  • Schedule line number

    -- ${b1["schedule line number"]} ("VBEP"."ETENR")

  • New delivery date

    -- ${b1["material availability date"]} ("VBEP"."MBDAT")

Additional remarks:

  • In the above example, the material availability date is used as the new delivery date. Your customer might have different requirements for calculating or determining the new delivery date for the order.

  • Within your Studio Skill, a simple SAP action is sufficient to update the delivery dates at both the header and item level. Based on your customer’s needs, however, you could use an advanced SAP action to make more personalized adjustments to the order details.

4) Write Data to Table

The Write Data to Table action will populate defined data tables and fields in a Celonis data model. In this case, an "OUTBOX" table is created, which records a new entry for every sales order delivery date that is updated, and for every customer email that is sent. In turn, this table is used in the Action Engine Skill filter criteria to ensure that we only update orders when necessary, and only notify customers of relevant changes.

Example columns:

  • SALES_DOCUMENT

    -- Record of the sales order that was updated in SAP

  • CUSTOMER_NAME

    -- Name of customer whose order is being updated

  • CUSTOMER_ID

    -- Customer number

  • SALES_DOC_TYPE

    -- Document type of sales order that is being updated

  • SHIP_CONDITIONS

    -- Shipping conditions of the order

  • OLD_DELIVERY_DATE

    -- Original customer requested delivery date

  • NEW_DELIVERY_DATE

    -- New delivery date for the order

  • OLD_MAT_AVAIL_DATE

    -- Original material availability date of the order

  • NEW_MAT_AVAIL_DATE

    -- New material availability date for the order

  • SAP_CHANGE_DATE

    -- The date and time when the delivery date was changed in SAP (today)

Additional remarks:

  • This action can be used to maintain a record of changes performed in SAP, to ensure that customers are only notified of changes once, or for many other reasons. Your customer may have their own requirements for what information they would like to write back to the data model.

3. Notify Client of New Delivery Date
41195673.png
Action Engine Skill

Action Engine Skills work by scanning all relevant records (e.g. sales orders) for certain rules and criteria whenever the underlying data model is reloaded. These Action Engine Skills trigger actions and automations that are defined in associated Studio Skills.

This action Engine Skill will check all incoming sales orders (theSignal ID), and will flag those with upcoming requested delivery dates in the near future.

Signal ID

The Signal ID is the object or record on which the use case is based. In this use case, a new Signal is generated for eachcustomer that has at least one updated ordersince the previous email was sent out.

Customer Example

The Action Engine Skill identifies orders that have had their delivery dates updated by the previous Skill. If these changes have not yet been communicated to the customer, the Studio Skill is triggered to dispatch an email to the customer. This email contains an aggregated list of all of the orders that have been changed since the last notice. See the use case description for further details.

Skill Filters

Below, you will find a collection of filters and considerations for identifying customers for whom at least one order was updated since the last email was sent out.

Process Flow Filters

Process flow filters are those that define process-specific conditions for the Action Engine Skill (e.g. filters related to process cycle times, relevant activities, order process flows, and other custom criteria).

Customer not yet notified

A customer’s order has been updated, but they have not yet been notified of this change.

Example filters:

  • FILTER "OUTBOX"."SAP_CHANGE_DATE" > "OUTBOX"."CUST_LAST_CHANGE_DATE";

    -- The delivery date change in SAP took place after the customer was last notified

Additional remarks:

  • Your customer may only want to notify their customers of delivery date changes at certain times of the day or week. As such, you may have to consider their requirements in defining how frequently emails are sent out, and what the contents of those emails should look like.

Record Attribute Filters

Record attribute filters are those that limit the scope of the Action Engine Skill to records (e.g. sales documents) that have particular characteristics (e.g. those with or without particular holds, payment terms, shipping conditions, and other custom criteria).

Order delivery date was updated

Certain fields in the "OUTBOX" table may only be populated when an order’s delivery date is updated in SAP. This filter ensures that customers only receive relevant and up-to-date information.

Example filters:

  • FILTER "OUTBOX"."SAP_CHANGE_DATE" IS NOT NULL;

    -- Order was updated in SAP

Studio Skill

Studio Skills define the actions and system automations that are performed against a record (e.g. customer) when an Action Engine Skill is triggered.

This Studio Skill sends an email to notify a customer when the delivery date of one or more of their orders has been updated.

Customer Example

The Studio Skill is triggered by an Action Engine Skill when an order’s delivery date has been adjusted, and the customer has not yet been notified of this change. The Studio Skill compiles a list of orders that have been changed for each customer, and sends an email containing these updates at set times of the day.

Skill Configuration

Studio Skills are composed of asensorand one or moreactionsperformed in Celonis or connected IT systems. When an Action Engine Skill is triggered, the sensor executes the system actions defined in the associated Studio Skill. Usually, a combination of different types of actions are defined in the Studio Skill. These can be Celonis actions (query a data model, write data to a table or execute a machine learning script), system actions (apply data filters, process routers, or loops), ERP actions (remove a delivery block in SAP or update an account in Salesforce), communication actions (email a customer or Slack a colleague), and many others.

Below you will find the sequence of actions required to send an email to customers to notify them of relevant delivery date changes.

41194952.png

1) Action Engine Sensor

The Action Engine sensor will execute the Studio Skill when the associated Action Engine Skill is triggered.

Example custom inputs:

  • Customer number ("VBAK"."KUNNR"): ${b1["customer number"]}

    -- Defines the customer whose order delivery date has been updated

  • Customer name ("KNA1"."NAME1"): ${b1["customer name"]}

    -- Defines the name of the customer whose order has been updated

  • Customer last change date: ${b1["sales document type"]}

    -- The last time this particular customer's sales order delivery date was updated

  • Customer email address: ${b1["customer email"]}

    -- The email address of the customer contact who should be notified of changes

Additional remarks:

  • Based on your customer’s needs, additional or alternate input fields may be required. For example, you may need to consider the date on which updates are performed in SAP, customer names and preferences, or other particulars in the actions you define.

2) Query Data Model

The Query Data Model action will retrieve defined data fields from a Celonis data model. In this case, we are querying the positions and schedule line details of the order.

Example columns:

  • Sales document ("OUTBOX"."SALES_DOCUMENT"): ${b2["sales document"]}

    -- Defines the sales order for which the delivery date will be updated in SAP

  • Customer number ("OUTBOX"."CUSTOMER_ID"): ${b2["customer number"]}

    -- Defines the customer whose order delivery date has been updated

  • Customer name ("OUTBOX"."CUSTOMER_NAME"): ${b2["customer name"]}

    -- Defines the name of the customer whose order is being updated

  • Sales document type ("OUTBOX"."SALES_DOC_TYPE"): ${b2["sales document type"]}

    -- Defines the document type of the order

  • Shipping conditions ("OUTBOX"."SHIP_CONDITIONS"): ${b2["shipping conditions"]}

    -- Defines the shipping conditions of the order

  • Old delivery date: ${b2["old delivery date"]}

    -- Defines the original customer requested delivery date for the sales order

  • New delivery date: ${b2["new delivery date"]}

    -- Defines the new delivery date for the order

  • Old material availability date: ${b2["old material availability date"]}

    -- Defines the original date on which the ordered material was available for delivery

  • New material availability date: ${b2["new material availability date"]}

    -- Defines the new date on which the ordered material will be available for delivery

Example filters:

  • FILTER "OUTBOX"."CUSTOMER_ID" = '${b1["customer number"]}';

    -- Filter on only this customer

Additional remarks:

  • Based on your customer’s needs, additional fields may need to be queried in the Celonis data model. For example, you may need to query the material availability date, distribution facility or shipping conditions for the order in question to determine when the new delivery date should be.

  • Additional filters may be required to meet your customer’s needs. For example, you may need to filter only on order changes that have not yet been communicated to the customer.

3) Email by Celonis

The Email by Celonis Action will compose and send emails to desired recipients. In this case, emails will be populated with each customer’s updated order details, and distributed at set times of the day or week.

Example contents:

  • HTML Table: ${b2["htmlTable"]}

    -- Contains the details queried in the previous step of the Skill

Additional remarks:

  • The Email by Celonis action will only allow your customer to send out a maximum of 100 emails per day. If your customer needs to send out more than 100 emails per day, they may need to configure their own SMTP server to allow for this. More information on SMTP Email actions can be found here.

4) Write Data to Table

The Write Data to Table action will populate defined data tables and fields in a Celonis data model. In this case, a record is added to the "OUTBOX" table when an email is sent to the customer to update them of changes to their order delivery dates.

Example columns:

  • CUSTOMER_NAME

    -- Name of customer who is receiving an update to their order delivery date

  • CUSTOMER_ID

    -- Customer number

  • CUST_LAST_CHANGE_DATE

    -- The date and time when the customer was notified of changes to their order delivery date

Additional remarks:

  • This action can be used to maintain a record of changes performed in SAP, to ensure that customers are only notified of changes once, or for many other reasons. Your customer may have their own requirements for what information they would like to write back to the data model.