A CRM system is an independent application and works like a central hub to combine data from different sources into one system. For this to happen effectively, there must be external data feeds and integrations that bring in data to your CRM, in addition to all the user input data. When it comes to building business rules in Creatio, there are low code options to handle the necessary scenarios, but this applies to the user interface (also referred to as "client-side" business logic).

These client-side rules however do not kick-in if a back-end integration is trying to import data into the CRM database on a daily basis, because they feed data directly at the database layer. So, to make sure the data being imported is following the same rules, any back-end system integrations also need to synchronize by building similar logic into their integration solutions.

While this may be simple in the short term—given that the integration team and the CRM teams can work in parallel—we end up with a maintenance issue in the long term because the same logic in multiple applications needs to be updated and maintained continuously. Add one more integration with a new system, and the number of copies of this logic start to multiply rapidly.

So, keeping long term maintainability and scalability in mind, we have to decide if having low code options in multiple systems makes sense…or whether we should consider centralizing the rules in CRM via some code so that all the other systems do not have the burden of maintaining the CRM-specific logic.

This is when adding some code directly to the back-end CRM system (AKA “server side” code) makes more sense. It might take a little bit of coding, but in the long term will save a huge amount of time when several systems get integrated with the CRM. The CRM will receive and reject invalid data in a global fashion using the same point of contact, and this means we don’t need all the other systems to also implement and maintain the same logic rules.

To do this effectively, some effective server-side processing needs to be built into Creatio. In this example, we have a company that must ensure when customers are imported as Accounts, that their won deals exceed lost deals when both foreign and country (domestic) sales are combined. Basically, when both sales numbers are added, Creatio needs to ensure that the net total is positive. For other account types, this check is not required, and the data can be imported as-is.

To implement a solution for this, we need to add some functionality at the Account object level inside of Creatio.

First, turn on the "Before record saved" event which allows for creating a hook into the process that is attempting to save an account record. Also here is where the custom sales fields - CountrySales, ForeignSales and TotalSales fields can be added to the Account table.

Then, we need to create a process at the Account object level that receives a message ("AccountSaving") and triggers an operation. In this case we have a script that contains code to be executed.

Click "Open Process" to launch the process designer.

Add an event sub-process.

In the event sub process, add a triggering message (AccountSaving) which tells the operation when to execute.

Next, add the code that performs the validation. Don’t forget to save and publish the changes!

For readability, here is the text of the C# code:

Decimal countrySales = Entity.GetTypedColumnValue<Decimal>("UsrCountrySales"); Decimal foreignSales = Entity.GetTypedColumnValue<Decimal>("UsrForeignSales"); Decimal totalSales = countrySales+foreignSales;   if(totalSales<0 && Entity.GetTypedColumnValue<string>("TypeId").ToString().Equals("03a75490-53e6-df11-971b-001d60e938c6")) { throw new Exception("Total sales cannot be negative for a Customer"); }   else { Entity.SetColumnValue("UsrTotalSales",totalSales); return true; }

Now that we have the rule in place, we must test to see if the logic is being properly triggered in a centralized fashion. On the UI side, we have added to code or business rules at the screen/UI level. Yet, when saving a "Customer" record, we can see that the server side rule is now performing the appropriate checking. In this case, the higher negative foreign sales value is making the net total negative 500, which violates the rule implemented and generates an error message.

What about external systems or data imports? To test this, we need to dummy up some data and import it via the Creatio import tool. Note that there is one record of type "Customer" whose net total is negative. The two others should get imported successfully.

Notice that once the data is imported, the import tool reports that two records imported successfully while one did not. This is exactly what we expected to see.

On closer examination of the log, we see the reason why one of them could not be imported. This system message is the same as what we experienced in the UI. The same messaging will appear when a similar import is made using any external ETL tools like our highly recommended StarfishETL tool that uses the Creatio API.

As you can see, the CRM system now has centralized rules in place to make sure that the "total sales" calculation and validation is done, and this offloads the burden from any other systems that integrate with CRM. The centralized nature will also make sure that the same consistent responses are maintained to communicate with any external system as to why some data is not appropriate for processing into the CRM. This makes for a more scalable and maintainable system in the long run.