Acorel
Gratis demo

Timing and condition issues with Workflow Rules

Roderick Stoffels, 10 maart 2021

Workflow rules are standard and is a very useful tooling within SAP Sales Cloud and can be set up very flexible to meet almost all of your business requirements. It is possible to trigger the automatic creation of tasks as an addition to e-mail messages, notifications, field updates and actions for business objects. Although it’s a powerful feature, it does have its limitations. One of these limitations is the impossibility to create a dependency between workflow rules. Another limitation is that the usage of the setting ‘Before Object Change’ within a condition group can only be used for workflow rules with timing ‘On Every Save’. This means that the setting ‘Before Object Change’ will thus not work for workflow rules which are scheduled.

This blog will describe how we faced and tackled those two limitations at one of our clients.

 

One of our clients business requirements is that at a specific moment in the process flow, several events have to be executed for a service ticket at the same time! The following events need to be executed:

  1. Trigger a letter to be sent to the customer registered in the service ticket;
  2. Update the status and sub-status of the service ticket;
  3. Create a task for an employee.

Our client uses an external system (PlanetPress) to create and send letters to its customers. To create the best customer experience it is of course not desirable to send the same letter more than once to the same customer. Important to know is that we had to deal with two prerequisites:

  1. The status and sub-status update of the service ticket can only be executed when the customer letter has been processed successfully.
  2. The task for the employee can only be created when the status and sub-status of the service ticket has been updated.

During the implementation period we faced the problem that the scheduled workflow rules created to meet the three business requirements mentioned above, were interfering with each other and hampering the process flow. After some investigation we discovered that the workflow rule to create a letter was triggered multiple times, because the service ticket was updated or changed due to timing issues and incomplete condition groups. The result was that a kind of endless loop was established, because it is not possible to use the setting ‘Before Object Change’ in a scheduled workflow rule! And unfortunately it’s not possible to limit the execution of a workflow rule to one time only, like there is for actions in SAP CRM on premise.

Next I will describe the adjustments and settings that have been made in the SAP C4C system to streamline and stabilize the integration and communication with the external system. Our adjustments should cover all business requirements and thus prevent the same letter from being sent multiple times. It is important to note that this must apply to both situations where the external system is “online” and the situation where it is “offline”.
The following adjustments have been made in the SAP C4C system:

Custom Field “Letter PlanetPress”

A new Custom Field “Letter PlanetPress” has been created for the Service Tickets and has the following properties:

This field is designed and necessary for the correct sending of letters to the external system to prevent the same letter being sent multiple times. It acts kind as a “check” field. By default, when a Service Ticket is created, the value “No” (False) is assigned to the field. At the moment when a workflow rule to trigger a letter is being executed, the action ‘sendMessageToPlanetPress’ is called (SDK development) that will immediately change the value from ‘No’ (False) to ‘Yes’ (True).

Custom Table “PP Status after success”

Two custom tables have been created for a correct process of status updates for Service Tickets and the communication with the external system:
1. “Planet press mailing triggers”;
2. “PP Status after success”.

The first table “Planet press mailing triggers” contains entries with the (key) combination of Status & Sub-status (= extension field) of a Service Ticket to indicate which letter should be created in. At the moment a Workflow Rule with regard to PlanetPress is triggered, the SDK action ‘sendMessageToPlanetPress’ is called which will read this custom table ‘Planet press mailing triggers’ to determine which letter should be generated in PlanetPress.
The “sendMessageToPlanetPress” action will refer to another second custom table “PP Status after success” to read the entries and see which Status and Sub-status update on a Service Ticket should be executed when the letters have successfully been processed.

As mentioned earlier, we are dealing with 2 scenarios:
• Scenario A: PlanetPress is “Online”;
• Scenario B: PlanetPress is “Offline”.

Scenario A: PlanetPress is “Online”

Below is a schematic representation of the process when PlanetPress is ‘online’:

As you can see, both custom tables in SAP C4C are being used in this scenario. Table “PlanetPress Mailing Triggers” is used for the outbound communication from SAP C4C to SAP CPI and table “PP trigger after success” for the inbound communication from SAP CPI to SAP C4C.

In addition to creating the new custom field “Letter PlanetPress”, a number of changes have also been made to workflow rules so that all data is processed in the correct order and to secure a stable process. And of course, to ensure that a service ticket shows the correct and “up to date” information.
All workflow rules that should trigger a letter now contain an extra condition: “Letter PlanetPress” equal to value “No”. The moment a workflow rule is being triggered, the SDK action ‘sendMessageToPlanetPress’ is called that changes the value immediately from ‘No’ (False) to ‘Yes’ (True). And when the processing of the letter is successful, SAP CPI will return the hyperlink to the specific letter and also value “No” for “Letter PlanetPress”. Because there is an immediate response, the same action or SDK development ‘sendMessageToPlanetPress’ will adjust the status and sub-status of the service ticket with regard to the custom table “PP trigger after success” accordingly. And this new status and sub-status of the service ticket is the trigger to execute the workflow to create a task for the employee.

To sum it all up, all business requirements are fulfilled:

Scenario B: PlanetPress is “Offline”

In the previous scenario, the “Happy Flow” has been described and we are assuming that the letters will always be processed successfully straight away, so a response or response will be received immediately. Although this is often the case, the reality shows that sometimes there is a hiccup somewhere on the line and there is no immediate response from the external system.
Below is a schematic representation of the process when the external system is ‘offline’ (see red arrows between SAP CPI and PlanetPress):

As you can see, in this scenario only the custom table “PlanetPress Mailing Triggers” will be used when a workflow rule with SDK action ‘sendMessageToPlanetPress’ is executed to trigger a letter. The reason that the second custom table “PP trigger after success” (as in scenario A) is not applicable here is because there is no direct response from PlanetPress and SAP CPI. As a result, the SDK action ‘sendMessageToPlanetPress’ will be aborted. This means that the value for the extension field ‘Letter PlanetPress’ in a service ticket has been set to ‘Yes’ (True) by the ‘sendMessageToPlanetPress’ action on the ‘outbound journey’. However, it will not immediately be changed by SAP CPI to ‘No’ (False) on its way back.

SAP CPI contains a mechanism that every 5 minutes an external system is being pinged to see if the external system is “online” again. When after some period of time, the system is “online” again or the hiccup has been solved, SAP CPI will receive and process the message to SAP C4C. Just like in scenario A, SAP CPI will return the hyperlink to the specific letter and also the value “No” for “Letter PlanetPress”. However, in this case the custom table “PP trigger after success” will not (in fact cannot) be accessed to determine which status update should be performed on the service ticket.

That leaves us with only a minor issue in this scenario: to ensure that the service ticket will be updated with the correct status and sub-status. This can easily be solved by workflow rules which will take over the task of the custom table “PP trigger after success”. And in this case we will make use of the setting ‘Before Object Change’ (only valid with timing ‘On Every Save’!), where the object in this case is the custom field ‘Letter PlanetPress”. The conditions for this workflow rule will contain the current status and sub-status and the value ‘No’ for the custom field and object “Letter PlanetPress” and value ‘Yes’ for the same object but with the additional check ‘Before Object Change’!

In this manner we will also fulfill all the business requirements, like in scenario A.

 

As mentioned before, workflow rules are very powerful but they can also cause you a lot of headaches or even migraine when timing and conditions are not set correctly! Think outside the box and hopefully this blog can keep you away from a doctor’s appointment.

 

Roderick Stoffels

Read all my blogs

Receive our weekly blog by email?
Subscribe here:

More blogs