Skip to content

When processing a request, the System performs the following sequence of steps:

  1. Evaluative field dependencies: Field dependencies are UI-only and are validated before triggers are fired. If Vault Java SDK then changes data, field dependencies are not re-evaluated.
  2. Execute BEFORE Action Triggers.
  3. Execute BEFORE triggers.
  4. Write record changes to database.
  5. Update changes in VQL index.
  6. Execute AFTER Action Triggers.
  7. Execute AFTER triggers.

The data available in BEFORE and AFTER event triggers depends on the operations (INSERT, UPDATE, and DELETE). For example, in an INSERT operation, you cannot get old or existing values because a new record is being inserted. Similarly, setting a field value only makes sense in the BEFORE event in INSERT and UPDATE operations. It doesn't make sense to set field ​value after it has been persisted or in a DELETE operation. The following chart illustrates when you can get or set field values.

getNew()getOld()
getValuesetValuegetValuesetValue
BEFORE_INSERT
AFTER_INSERT
BEFORE_UPDATE
AFTER_UPDATE
BEFORE_DELETE
AFTER_DELETE

As illustrated above, BEFORE triggers can change field values, but these values are not persisted to the database and not updated in the VQL index yet. In this case, using the QueryService to retrieve a record being modified by a trigger will only return the old (existing) values. In order to get the values set by a trigger inside a transaction, you must use the RecordService#readRecord method. However, this method generally uses more memory. It is only recommended when you need to get field values modified by multiple triggers in a single transaction. Otherwise, we recommend QueryService to retrieve record data.

Because AFTER triggers happen after database updates and VQL indexing, you can use QueryService to retrieve both old and new values.

Certain field types in Vault have values set by the System. For example:

  • Lookup Fields are read-only fields that the System populates with the "Lookup Source Field" value.
  • Document Reference Fields have two fields (bound and unbound), and when configured to reference the "Latest Version", the bound field becomes read-only, and the System populates it with the latest document version value.

In general, the System populates field values after the BEFORE event. Because these field values are set by the System, the changes are not reflected in the BEFORE event. For example, getNew() and getOld() will return the same existing value or null accordingly. However, the AFTER event will return the new value set by the System in getNew() and the existing value in getOld(). For example, when creating a new document, documents using document auto-naming will have a null value for name in BEFORE_INSERT events.

In addition, because System-initiated requests do not fire triggers, triggers will not fire when the System updates a System-populated field.

If your trigger updates a document reference field, you must set the Document Version Reference to Specific Version. Learn more in Vault Help.