Creating automatic triggers - Technical

Root > 3. Customisation

 

 

    Follow WiredContact on Twitter
 

Creating Automatic Triggers

Summary - WiredContact can automate a lot of functionality to ensure high levels of consistency in your database. If the content below is confusing please submit a ticket describing what you want to achieve and we will assist you. The time will be billable.

Technical 
When updating a contact record for example  (wce_activity, wce_sales, wce_history, custom subentity tables) you can trigger three types of actions:
Field changes
  • Conditionally change fields
  • Conditionally update the history
  • Conditionally send an email
Conditional triggers are set via the conditional trigger sections defined in the subentity dialog templates. Examples of subentity dialog templates are Schedule.html, NewSale.html and EditHistory.html.

Some subentity dialogs have default conditional trigger behaviors that can be overridden.

Conditional Field Changes
You can assign a value to a field if a specific condition is met. For example, you may want to update the EditTime field of a contact table every time a note is changed for a contact. Conditional Field Change triggers are defined in the <#conditionalfieldchangex>/<#/conditionalfieldchangex> sections - where x is an integer value (1, 2 or 3 for example). You setup the parameters for the Conditional Field Change trigger in this section. Parameters are:

  • TestBefore - Conditional statement prior to update - must evaluate to true for even to happen
  • TestAfter - Conditional statement after update - must evaluate to true for even to happen
  • Field - which field to change
  • FieldValue - what value to change the field to
  • EntityTable (optional) - which table the field is in (if not in the current table)
  • EntityTableField (optional) - field which will identify the record to be updated, like UniqueID
  • EntityTableValue (optional) - value which will identify the record to be updated
For example, to update the EditTime field for a contact when a note is added or updated, you would use the following code in your EditHistory.html:
  <#conditionalfieldchange1>
testbefore=1=1
testafter=Note=<#params value='_htype'>
field=EditTime
fieldValue=<#date> <#time>
entitytable=wce_contact
entitytablefield=uniqueid
entitytablevalue=<#parent field=uniqueid>
<#/conditionalfieldchange1>

In the above example, the contact record will be updated regardless of what the "TestBefore" conditional statement is - so a conditional statement that evaluates to true is used: 1=1. If the statement evaluates to true, the TestAfter condition is checked.

The TestAfter conditional statement is checking one of the parameters from the dialog - the _HType parameter, which corresponds to the HType field in the wce_history table. To see what parameters are available for a given dialog, you can View...Source that dialog after it's been rendered by WCE. If this parameter equals the value "Note", then the statement evaluates to true, and the Conditional Field Change is executed.

The Field parameter is the field that will be updated with the FieldValue parameter. Note that the FieldValue in this case is being populated with the WCE tags<#date> and <#time> which will create a current date/time stamp.

Since we're not updating wce_history in this case, we need to identify the table and the record that we're going to update. That's where the EntityTable parameters are used. In this case, the wce_contact is being updated, using the record identified by the ParentEntityID carried by the EditHistory dialog.

Any dialog clearing an activity (Schedule.html) has two default Conditional Field Change sections - one for updating the LastReach or LastMeeting fields for Completed Calls/Completed Meetings, and one for updating the Edit. You can override these default sections by adding sections of the same name. Here are the default sections:

(For activity type Meeting)

  <#conditionalfieldchange1>
testbefore=Meeting Held=<#params value='_htype'>
testafter=1=1
field=lastmeeting
fieldvalue=<#params value='date'> <#params value='time'>
entitytable=<#params value='etable'>
entitytablefield=UNIQUEID
entitytablevalue=<#parent field=uniqueid>
<#conditionalfieldchange1>

(For activity type Call)
  <#conditionalfieldchange1>
testbefore=Call Completed=<#params value='_htype'>
testafter=1=1
field=lastreach
fieldvalue=<#params value='date'> <#params value='time'>
entitytable=<#params value='etable'>
entitytablefield=UNIQUEID
entitytablevalue=<#parent field=uniqueid>
<#conditionalfieldchange1>

 


(and if one of the above actions are taken:)
  <#conditionalfieldchange2>
testbefore=1=1
testafter=Note=<#params value='_htype'>
field=EditTime
fieldValue=<#date> <#time>
entitytable=wce_contact
entitytablefield=uniqueid
entitytablevalue=<#parent field=uniqueid>
<#/conditionalfieldchange2>

Conditionally Recording History Items
You can record a history item if a specific condition is met. For example, you may want to add a history item when you close a sale. Conditional History Item triggers are defined in the <#recordhistoryitemx>/<#/recordhistoryitemx> sections - where x is an integer value (1, 2 or 3 for example). You setup the parameters for the Conditional History Item trigger in this section. Parameters are:
  • TestBefore - Conditional statement prior to update - must evaluate to true for even to happen
  • TestAfter - Conditional statement after update - must evaluate to true for even to happen
  • _HType - Value of history type
  • _Subject - Value of history regarding/subject
  • _Notes - Value of history details/notes
For example, to add a history record when a Sales item is changed from Open (or blank) to Won:
Note - this is the default behavior
  <#RecordToHistory1>
testbefore=<#fieldfield=salestatus blank="" notblank="open">=<#fieldfield=salestatus>
testafter=Open<><#fieldfield=salestatus>
_HType=<#fieldfield=salestatus test1='Won' val1='Completed/Won' test2='Lost' val2='Lost Sale'>
_subject=Completed Sale for <#parent field=EntityNameField>, <#parent field=EntityName2Field>
_Notes=Sales Stage <#fieldfield=stage><br>Product Name: <#fieldfield=productname><br>Product Type: <#fieldfield=producttype><br>...Details: <#fieldfield=notes>
<#/RecordToHistory1>

In the above example, standard WCE tags were used to generate appropriate values for the pre/post conditional statements, as well as the contents of the fields in the new history record.

Conditionally Sending Email
You can send an email if a specific condition is met. For example, you may want to send an email when you close a sale. Conditional Email triggers are defined in the <#sendemailx>/<#/sendemailx> sections - where x is an integer value (1, 2 or 3 for example). You setup the parameters for the Conditional Email trigger in this section. Parameters are:

  • TestBefore - Conditional statement prior to update - must evaluate to true for event to happen
  • TestAfter - Conditional statement after update - must evaluate to true for event to happen
  • To - Email address(es) for the To field
  • CC  - Email address(es) for the CC field
  • BCC - Email address(es) for the BCC field
  • Reply - Email address for the Reply field
  • Subject - Subject for the email
  • htmltemplate - File name of the HTML template for this email
  • msgtemplate - File name of the Email template for this email
  • message - Message for this email
For example, to send an email when a Sales item is changed from anything but "Won" to "Won":
  <#sendemail1>
testbefore=won<><#fieldfield=salestatus>
testafter=won=<#fieldfield=salestatus>
subject=Completed sale for <#parent field=EntityNameField>
htmltemplate=C:\Inetpub\Wirede\HTMLTemplates\LetterHead 1.htm
msgtemplate=c:\inetpub\wirede\email\completedsale.txt
to=employees@wiredcontact.com
<#/sendemail1>

In the above example, the email template CompletedSale.txt is used for the message, so the Message parameter is not needed - and the merge fields function is performed on the message template prior to being sent, just like any email.
 

Add Feedback