As we discussed in a previous post, we can make code in different areas of the Application Composer. However, when will the code we make actually run?
To answer this, let's start with the most common place where scripting is done, Triggers.
Triggers
Triggers are categorized into Object Level Triggers and Field Level Triggers.
Object Level Triggers
These triggers fire when things happen at the object level. Here are the types of Object Level Triggers you can create:
- After Create: Fires when a new instance of an object is created. Use to assign programmatic default values to one or more fields in the object.
- Before Modify: Fires when the end-user first modifies a persistent field in an existing, queried row.
- Before Invalidate: Fires on an existing object when its first persistent field is modified. Fires on a valid parent object when a child row is created, removed, or modified.
- Before Remove: Fires when an attempt is made to delete an object. Returning false stops the row from being deleted and displays the optional trigger error message.
- Before Insert in Database: Fires before a new object is inserted into the database.
- After Insert in Database: Fires after a new object is inserted into the database.
- Before Update in Database: Fires before an existing object is modified in the database.
- After Update in Database: Fires after an existing object is modified in the database.
- Before Delete in Database: Fires before an existing object is deleted from the database.
- After Delete in Database: Fires after an existing object is deleted from the database.
- Before Commit in Database: Fires before the change pending for the current object (insert, update, delete) is made permanent in the current transaction.
- After Commit in Database: Fires after the change pending for the current object (insert, update, delete) is made permanent in the current transaction.
- Before Rollback in Database: Fires before the change pending for the current object (insert, update, delete) is rolled back.
- After Rollback in Database: Fires after the change pending for the current object (insert, update, delete) is rolled back.
Field Triggers
These triggers execute when a field has its value changed without pressing the save button.
Validation Rules
Object-Level Validation Rules
An object-level validation rule is a constraint you can define on any standard or custom object. It is evaluated whenever the framework attempts to validate the object. This can occur upon submitting changes in a web form, when navigating from one row to another, as well as when changes to an object are saved. Use object-level rules to enforce conditions that depend on two or more fields in the object. This ensures that regardless of the order in which the user assigns the values, the rule will be consistently enforced.
Source: Oracle Documentation
Field-Level Validation Rules
A field-level validation rule is a constraint you can define on any standard or custom field. It is evaluated whenever the corresponding field's value is set. When the rule executes, the field's value has not been assigned yet and your rule acts as a gatekeeper to its successful assignment.
Source: Oracle Fusion CRM Application Composer Scripting Guide
Custom Button
From Actions and Links, you can create your own buttons with code behind them. The code you write for the button will execute upon clicking the button.
However, there is one case where you will press the button you made but won't see any results or effects. This is because the code probably needs to commit some actions to the database. This happens only after pressing the save button.
For example, if you create a button that will create a copy of a record of an opportunity via pure Groovy scripting (without using web-services), you press the button and the code to make the copy record executes, but you won't see that copy until you click the save button. Only then are the transactions pushed to the database and the copy of the record will appear in the UI.
Object Workflow
Object workflows fire when their conditions on the event points are met. There are only two possibilities: create a new record and update a record. That is when the code in the conditions will execute.
Required/Updatable Field Condition
The code of this condition executes or is evaluated when the dependent field changes its value or when the save button is pushed. It all depends on the logic of the condition code. Usually, if you have a script that checks if a field has changed its value, then this will execute only when a dependent field is set, and that field actually changes its value. But if you have a condition that checks for a particular value, then this could also execute when the save button is pressed. So it all depends on the script set in these conditions.
Expression from Default Values on a Field
This code will execute when creating the record, as this is the initial value that the field will display. The code will execute upon record creation even if that field is not displayed on the creation page and only on details.
Expression from the Mapping of Lead to Opportunity and Deal Registration to Opportunity Conversion
As its position is in the map used for conversion, this executes the moment we convert Leads to Opportunities or Deal Registrations to Opportunities.