In a Rollbase Web App, triggers automate business
logic to satisfy a variety of use cases. This video demonstrates two types of triggers in
the context of a sample application. This Library app tracks titles that library
members check out. When a member checks out one or more titles,
a library employee creates a new check out record.
The record stores the library member’s name, titles they check out, check out date, and
due date. The Check Out object and Title object are
related and both have a text field for status. When a member checks out a title, instead
of expecting the Librarian to also modify the status of the Title record, we want to
create a trigger to automatically change the status value to Checked Out.
When a member checks in a title, we want to change the title’s status value back to
Available. The same type of trigger works for both updates, but we need one for each
status change. The first status change should occur when
the Librarian creates a new check out record, so the trigger belongs on the Check Out object.
From the tab menu, we access the object definition. We navigate to the Triggers section, and click
New Trigger. A variety of trigger types are available.
We choose Update Field Value because we want to change a field in a related record.
By default, the trigger is deployed, meaning that it will work for both administrative
and non-administrative users. Next we choose when we want the trigger to
run, which is after the user creates a new Check Out record.
We add a descriptive name. For the integration name, we’ll use c_out
to represent checked out. The Any Update value for On Field Change will
be ignored because this trigger fires after creation–not on update of a record.
The trigger should change the Title object’s Status field.
On unauthorized use, the trigger will throw an error.
complex logic and calculate values dynamically. This trigger only updates the Status field
The message confirms that the formula is valid. There is no need to delay trigger timing or
repeat the trigger, so this trigger definition is complete.
After saving, the object definition contains the new trigger.
I already created the second trigger in a similar way. Let’s look at how its definition
differs from the first trigger. Instead of firing on create, this trigger
executes after an update. When a Library Employee changes the record to show that a member returned
a title, the trigger changes the status of the Title or Titles to Available.
The name reflects the trigger’s purpose. An update in the Check Out record’s Status
field fires the trigger. The trigger changes the Status field of the
Title record. The formula for this trigger sets the field’s
value to Available. Before testing the first two triggers, we’ll
create the third. First, consider the purpose of this trigger.
When a library member checks in a title, the application should keep a record of the check
out. This could be accomplished in a variety of ways. In this case, we will use a separate
Check In record. When a Librarian changes the Status of a Check
Out record to Returned, the trigger should create a new Check In record that stores information
from the Check Out record. I already created a Check In object definition.
Similar to the Check Out object, it contains relationships to Library Member and Title
to store the relevant values. The trigger will copy values from the existing
Check Out object to the new Check In object. Rollbase Conversion Map components describe
how to map objects of one type to another and are required to convert one record type
to another. End-users, triggers, or workflows can initiate record conversion.
Since the data comes from the Check Out object and the trigger is defined here, the Conversion
Map belongs in the Check Out object definition. The Data Maps section has a button for creating
a new Conversion Map. First, we select the type of object to convert
Check Out data. The Library app Title object has the suffix [title_lb].
We give the conversion map a logical name, Check Out to Check In, and, the integration
name c_out_to_in. We map the fields. In both Check Out and Check
In, Library Member and Title are lookup fields because they are relationships.
If the map cloned the related records, Title records would be duplicated each time a new
Check In record were created, so we leave this box unchecked.
Although it would be useful to delete the source Check Out object, since we plan to
use the conversion map in a trigger, this checkbox would have no effect.
We save and now the Check Out object contains the Data Map.
In the Check Out object definition, we add a new trigger to create the Check In record.
For Trigger Type, we select Create a New Record. Similar to the last trigger, this one should
fire on update of the Status field. We provide a logical name and integration
name. The trigger should fire on an update to the
Status field. We select the conversion map, and set the
trigger to throw an error for unauthorized users.
Again, we ignore the timing and repetition sections. Now we get to the Formula, which
will be different from the one we used in the previous triggers. This trigger should
only fire if a Librarian changes the value in the Status field to “Returned”.
We use the Template Helper to find the correct token to obtain the value from the Status
field. When this trigger executes, Rollbase replaces the token with the actual value from
the record before it evaluates the expression. We start the conditional expression and copy
the token. The token must be enclosed in quotes, since it is a string.
If the value of Status equals “Returned” we want the expression to return true and
fire the trigger. Otherwise, it should return false so that the trigger does not fire.
The editor shows the formula is valid. Now, let’s test our three triggers to see
if they work correctly. We create a Check Out record.
Notice in the Title records that the first trigger worked. It changed the Status to Checked
Out. When the library member returns the titles,
the Librarian will change the Status of the Check Out record to Returned. The second trigger also worked correctly and
changed the Status of the title back to Available. The third trigger should have created a new
Check In record. And, here it is! This video demonstrated the use of triggers
to change a field in a related record and to create a new record. Triggers can accomplish
other functionality such as managing workflows or sending automated emails. See the Rollbase
documentation for information on using other types of triggers. Thanks for watching!