Introduction

In the previous post, we extended the Activity Template feature to include the possibility of pre-defining optional Participants within the templates.

 

What is achieved by following the instructions can have practical applicability without modifications but should not be set in stone, the main goal is to illustrate how the underlying features can be combined to shape Aurea CRM to individual needs and processes of each organization.

 

Important: The changes described in this post should not be applied directly to a production system, especially the changes involving the Data Model and CRM.designer configurations. Careful testing should be performed to eliminate the possibility of human error following the instructions or unexpected interactions with pre-existing customizations.

 

In this post, we will add a global disclaimer text to all the Activities of type Service Visit with the following requirements:

  • It must be identical in all newly created Service Visits;
  • It needs to be regularly revised and updated in a centralized way.

 

Let's assume this is the disclaimer to be added to the text of each Service Visit:

Disclaimer:

Service Visits are essential to assure the correct operation and maintenance of your equipment.

The impossibility to perform maintenance tasks within the defined schedule can void the equipment's Warranty.

We thank you in advance for your collaboration.

 

User-defined Variables

Because our disclaimer needs to be managed in a centralized way, User-defined Variables are a good candidate to meet the requirements.

 

Defining variables in the Variable info area

The Variable and Variable Value info areas can be maintained in Aurea CRM.win (Defining Variables) and Aurea CRM.web (Variables).

 

Let's start by creating a new Variable(Z5) named CU_MA_ServiceVisit_Disclaimer in CRM.web.

Please note that the Info Area and Field Number are simply a convenient way to determine the Data Type of the variable. The variable can still be used with other info areas and fields with the same data type.

After the variable is created, one or more values can be assigned.

In this case, we can add HTML tags to the variable because the target field is defined as an HTML field.

The time a new Variable Value takes to be available is controlled by the Catalog Refresh Frequency, as described in Station Configuration: Cat. refresh frq.

Data Access Considerations

By default, the menu option is available in Settings > Maintenance > Variables.

As the default location of the option suggests, editing Variables is not a common task for an ACRM user as is considered a Maintenance task. For this reason, take the following into consideration:

  • In CRM.designer, the menu location can be altered to a more convenient place by editing the corresponding configuration units;
  • Through Roles, Access to the option can be provided or restricted to certain users or groups;
  • By defining suitable Rights, non-administrative users can be prevented to edit Variables not created by themselves or their group.

 

Triggers

Now that we have a Variable holding the text of our disclaimer, Triggers are a suitable option to make use of it.

 

Defining the Trigger

We want to Append the value of the Variable named CU_MA_ServiceVisit_Disclaimer, to express this the Trigger can be defined as follows:

PropertyValue
NameMA_append_disclaimer
Info AreaActivity
ActionEdit/Update

 

 

FieldFunctionField ContentsVariable
TextAppendCU_MA_ServiceVisit_DisclaimerVariable

 

 

For more information about defining triggers please consult Defining Triggers in the Core Administrator Guide.

 

Setting up the Trigger

The definition of which events initiate the trigger is done through the Rights format as described in Defining Database Events.

In our scenario, we want to run the Trigger for the Activity info area whenever a New record of Type Service Visit is created.

In a development system, an IIS application pool restart can expedite the loading of the new Triggers and Rights formats by CRM.web.

An alternative to the application pool recycle is to rely on the Format Refresh Frequency as described in the Station Configuration: Format. refresh frq. section of the Core Administrator Guide.

 

Creating a Service Visit

Now that Variable and Trigger creation and setup is complete, we can proceed with the creation of a new Service Visit in CRM.web.

 

Upon saving, we see that the text defined in the Variable is appended to the Text field of the Activity.

 

 

Conclusion

In this post, we used a user-defined Variable combined with a Trigger to append a boilerplate text to all Service Visits.

Although ACRM offers other mechanisms to achieve a similar outcome, the one presented is easy to maintain and because it is implemented in the ACRM Core, it has the added benefit of working in any ACRM application used to create Service Visits, not just in CRM.web.

 

On the next post, we will work on the final requirement of this series:

3. The name and email signature of the user must be added to the activity text

The final requirement has a few characteristics in common with the one covered on this post but we will use the differences as a pretext to explore other ACRM features.

 

References