In step 1, the user requests the display of a record either through the creation of a new record or by viewing or editing an existing record. The server retrieves the record from the database and passes it to the before record load server trigger, which performs pre-processing on the record form, such as setting default values in fields or changing the display characteristics of fields on the form.
In step 2, page content is pushed to the browser in the HTTP response to the record request. The browser loads the page. Once the page is loaded, the before a user edit client trigger occurs.
In step 3, the user makes changes to fields on the form. Form level client triggers such as before field edit, after field edit, and after field sourcing occur based on the user’s interaction with the form fields.
In step 4, the user saves the record. The before user submit client trigger occurs. If a return user error action is executed, workflow processing stops at this point.
If there are no validation errors, processing continues on the server or the before record submit server trigger occurs. Before records submit is an ideal place in which to perform validations and other business logic, such as calculations along with updating data on the record that is currently in the process of being saved. There has been no data persistence at this point, so it is possible to cancel the submittal of the record and return an error to the end user by executing the return user error action.
In step 5, the system persists the record in the database, either inserting a new record or updating an existing record. This only occurs when before records submit executes without returning an error. There is no database rollback feature once the record is persisted.
The changes are always in the database once the persistence takes place. Finally, the after records submit server trigger occurs after the record has been successfully persisted in the database. All of the data from the submitted record will be available at after record submit.