Basic Process Configuration
The process represented above is now described in detail.
It is really easy:
the process starts every time a new company record is created and its Rating is checked.
Depending on that the flow takes two different paths.
If the value is set on “Active” a new Potential is created, otherwise an email is sent to the administration department to inform them of the company’s record creation.
This process is designed to start every time a new company record is created. For that reason on “when to run the check” the option “on create” has been chosen.
Once the process has been performed, we find this Conditional Task.
On “when to run the check” has been chosen the condition “every time the condition is true”; in this way there is
no need for a manual intervention of the user and the process continues every time the condition is true.
At this point the process is divided in different paths, considering the conditions previously set. Here in the previous
condition two groups of conditions were set (OR), for that reason we can see two different paths.
One of these (status Active Company Rating) will lead to the creation of a new Opportunity related to the company, the
other (Company Rating Non Attivo) will send an informative email.
Let’s analyze the first:
You create a ScripTask with the action “Create entity”, then you choose the module Potentials. It is recommended to always name the actions, in this case “New Potential”.
It is always recommended to give a reference name to the actions of the process, in this case “New Opportunity”.
Once the desired module is selected, in this case the “Potentials” one, all the related fields are shown. Those can be mapped by taking data from all the related entities, from the selected one and from all the entities connected to the process itself.
In the other path, an email that notifies the creation of the company record is sent.
We create a Send Task and the “Action” chosen is send email.
As previously sad it is highly recommended to give a name to every action, in this case is “New Company Email Send”.
Sender, Receiver, Subject and all the other classical information needed are displayed.
Every field can be mapped by taking the data from the different field of the entities recalled in the process.
In the body of the email it is possible to use some special functions that can be selected from the Pick list on the right.
At this point, the process converge in one element, the End Event. Therefore the Ended Status is set.
End of support service
The following process manage the end of of support service.
The description of the process is the following when a user check the field "end of the support" inside the Service module the assignee of that service will be notificed with a pop-up where is asked if he/she wants to extend the support or confirm the end. Depending on the choice made by the asignee the process will take two differents process branches.
The process start when a user modify the field “End of Support” to the value “yes” within the module Service. This condition prevent that the process is trigered each time that any entity inside the module Service is modified.
The process continues with a pop-up that ask to the asignee of the service if he/she wants to extend the support or if he/she wants confirm the end. The pop-up is made through an “user task” where is checked the box “process helper”. Inside the Process Helper configuration is set the person who will see the pop up as well as the linked entity and the message that will be displayed to the assignee. In addition the process helper has one section with two fileds: one to confirm the extension of the service support ( which is a check box that is set to mandatory) and the other “Support end date” ( which is a date field thtat is mandatory only in the case that the assignee confirm the extension of the service).
For the correct visualizzation of the pop-up is needed a “conditional task” after the user task. Inside this task are set two group conditions on the new field ( End of Support). These two conditions will be used in the next step.
At this point the process reach gatwey here the process can potentially take two braches depending on the choice made by the assigne: If the assignee choosed to don’t extend the support service each contacts, related to that service, will be notificed with an email; on the other hand if the assignee choosed to extend the support date the service record will be update with the new date indicated by the asignee.
1 case the asignee of service do not confirm the support service extension
The process will send an email to each contacts related to that service. This action is made with the action cycle related records, starting from the module service the process cycle to each single contact and it send email.
2 case the asignee of service confirm the support service extension
In this case the support date will be updated with the value that the assigne passed in the process helper step. In this step is used the action update entity with the Renwal date mapped to the field support end date.
In the end the last task (end event) is configured as shown below:
