Vtiger users frequently ask of how to pass some information automatically from one entity to another.Of course the two entities are related together somehow.A common solution would be to add fields to the first entity and get them updated regularly by a functionwhich collects the information while activated on a certain condition.
We are talking about a custom workflow function activated on save of one of the two entities.
Well, the solutions is quite simple and straightforward, the only problem is that the custom function is only customizable
by a programmer! The main concept of the Workflow Creator starts exactly at this point.
What is the Workflow Creator?
It’s a tool that creates custom workflow functions getting some information from an entity and passing them to
another one related to it. It has a user-friendly interface in wich you can choose the entity modules, fields to update, values of these fields etc.
It is thought for normal users to easily create their own custom workflow functions without the help of a programmer.
Some examples of how to use it
There are two big categories of custom functions created by the Workflow Creator :
1. The one to one update functions and
2. The one to many update functions.
Both of these categories are also divided in some subcategories.
The one to one update functions
These functions update some fields of an entity (module) by getting information directly from another module related to it. The two modules
are linked together by a uitype 10 (popup) field in the first module. That is why it’s called the one to one function,
because the first module is linked with only one record of the second module.
This category is divided in two subcategories based on the way the information is updated:
-The overwriting function
-The appending function
Example of the overwriting function:
In the above example, the first module is the Contatcs (Contatti) module so the fields to be updated will be Contact fields, the second module chosen from the picklist
is the Accounts (Aziende) module related to the Contacts by a uitype 10 (Nome Azienda) of the Contacts module. From all the fields in the list only one field
will be updated, the First Name (Nome). It will take the value of the Account name (Nome Azienda) overwriting its own previous value.
Example of the appending function:
As you can probably notice the third column of the Workflow Creator interface is used to determine the function subcategory. If you choose None in
the function column, it will be an overwriting function, otherwise it will be an appending one. In this second image the user is creating
a workflow in which the Account Name (Nome Azienda) will be appended to the Contact’s existing First Name.
The appending method provides a very simple way to keep an history of changes of the updating field in the updated field.
The one to many update functions
These functions update fields of the first module with aggregated values of fields of the second one. The first module is related to the second one by a uitype 10 field
in the second module. This explains the name, one first module entity could be related to many second module entities. It’s obvious that we cannot directly update first
module fields. We have to use some aggregating method. The aggregation methods are the base of the subcategory division of these functions, but not only the methods,
even the second field type. So for text second fields we have two subcategories:
Imploding means that the first field will be updated with all the second field values separated by commas from each other, while counting means
the first field will containt the exact number of records related to the first one.
For numeric second fields we have six subcategories:
It means that the first field will be updated will the sum, count, average, minimun, maximum or the comma separeted values of the second field records related to
the first entity.
For datetime second fields we have three subcategories:
Apart from the implode function previously explained, first and last are two specific date functions. Using them means updating the first field value with the most recent (last) or
the less recent (first) date from a list of dates of the second module records related to the first one.
There is also another subcategory division concerning the one to many update functions.
-The non filtering aggregation and
-The filtering aggregation
The difference between them is that the filtering aggregation does not aggregate necessarily all the second module record related to the first but
only some of them based on a condition.
Example of a non filtering aggregation
In the above image we can see a workflow that updates the Potential Name (Nome opportunità) of an entity with the less recent Date Start of the Timecontrols
related to it. The forth, fifth and sixth columns are not used.
Example of a filtering aggregation
In this case the last three columns are used. This workflow is going to update the Potential Name of an entity with a list of comma separated Timecontrol titles related to it
BUT it isn’t going to use all the timecontrols just the ones with the Date start field equal to the 28.10.2012 value.
The same goes for the other fields. The Potential No is going to be updated with the number of timecontrols starting on October, the 28th 2012
while the Amount (Ammontare) is getting the sum of the timecontrol units starting on that date and of course related to the first module entity.
The ultimate steps
After determining the categories/subcategories of the funcion we should also choose the workflow direction. Will it start on save of the first or the second
module? We could create a both direction function too. While saving our function from the Workflow Creator, a new workflow, task and
method will be created automatically in our Vtiger copy at the same time with the function file itself. That’s the end of the entire process.
Just play around saving records and you’ll see your chosen fields getting updated.