A Process can be configured to run automatically whenever a record is saved to an object — either by a user through a screen, or by another Process writing to that object. This allows the platform to validate data before it is committed, or to trigger follow-on calculations immediately after a save occurs, without any manual action from the user.

There are two types of save-triggered Process, and they serve fundamentally different purposes.

Pre-Save Processes

A Pre-Save Process runs before the record is committed to the database. If it succeeds, the record is saved normally. If it fails, the record is not saved, and the user sees the failure notifications returned by the Process.

Pre-Save Processes are used for:

Validating user input before it reaches the database
Calculating derived attribute values as part of the save
Enforcing business rules that should prevent a save when violated

Because a Pre-Save Process runs synchronously with the user's save action — the screen waits for it to complete before refreshing — it must be fast and lightweight. Complex or long-running logic in a Pre-Save Process will cause a noticeable delay for every save. Reserve Pre-Save for small, quick operations.

Constraints on Pre-Save Processes:

A Pre-Save Process can only write data back to the same object that triggered it. It cannot write to other objects.
It cannot use Process Outputs in the normal sense — the save output is handled automatically via the ES_SAVE_OUTPUT named range.
It cannot use Process Parameters — there is no user interaction at this point.
If it uses Process Inputs to load other data, those inputs must use fixed filters or constant values only. Runtime parameter-based filters are not available.
Notifications are only displayed to the user if the Process Result is Failed. Notifications with a Warning or Information severity are written to the Calculation Log but not shown on screen.
Only the lowest-ordered EU_NOTIFICATION output is displayed to the user. If multiple notification outputs are configured, only the first (lowest order number) appears in the edit overlay.
Pre-save processes do not work on File Type attributes

Process Logic workbook for Pre-Save:

The workbook must include:

ES_SAVE_INPUT — receives the object's new or modified record before it is committed.
ES_SAVE_OUTPUT — contains the updated record after any calculations or modifications. The platform reads this and writes it to the database.
ES_RESULT — the standard result indicator. Set to Failed to prevent the save.

Create a Pre-Save Process

Open the Configuration application and navigate to Process Configuration \> Processes.
Click New and configure the Process as you would any Spreadsheet Process — name, description, Process Logic workbook, Result Location, Application, and Logging Level. See Create and Configure a Process.
Do not configure a standard Process Output. The Pre-Save output is handled automatically via ES_SAVE_OUTPUT.
If additional object data is needed in the workbook, configure Process Inputs with fixed or constant filters.
Enter an Audit Comment and click Save and Refresh.

Associate the Pre-Save Process with an object

Navigate to Objects \> Objects and select the object.
Click Detail, then Edit.
Set the Pre-Save Process field to the name of the Process you created.
Enter an Audit Comment and click Save and Refresh.

Once configured, the Pre-Save Process runs automatically every time a record of that object is created or modified.

Post-Save Processes

A Post-Save Process runs after the record has already been committed to the database. Because the save has already occurred, a Post-Save Process cannot prevent it — its purpose is to react to the save, not to validate it.

Post-Save Processes are used for:

Updating related records in other objects
Triggering follow-on calculations that depend on the newly saved data
Synchronising derived or aggregated values

The triggering object's data is automatically provided to the workbook via the ES_SAVE_INPUT named range. The Post-Save Process can then read that data, perform calculations, and write results to other objects using standard Process Outputs.

Constraints on Post-Save Processes:

A Post-Save Process must not write data back to the object that triggered it. Doing so creates an infinite loop — the write triggers another save, which triggers the Post-Save Process again, indefinitely.
Post-Save Processes do not support sending outgoing emails directly. If email notifications are needed as part of a Post-Save flow, handle them through a separate mechanism.
Post-Save Processes cannot use Process Parameters.

Process Logic workbook for Post-Save:

The workbook must include:

ES_SAVE_INPUT — receives the saved records from the triggering object.
ES_RESULT — the standard result indicator.
Named ranges for any Process Outputs writing to other objects.

Create a Post-Save Process

Open the Configuration application and navigate to Process Configuration \> Processes.
Click New and configure the Process as you would any Spreadsheet Process — name, description, Process Logic workbook, Result Location, Application, and Logging Level.
Do not configure a Process Input for the triggering object — its data is loaded automatically into ES_SAVE_INPUT.
Configure Process Inputs for any other objects whose data is needed.
Configure Process Outputs for the objects the Process will write to.
Enter an Audit Comment and click Save and Refresh.

Associate the Post-Save Process with an object

Navigate to Objects \> Objects and select the object.
Click Detail, then Edit.
Set the Post-Save Process field to the name of the Process you created.
Enter an Audit Comment and click Save and Refresh.

Once configured, the Post-Save Process runs automatically whenever a record of that object is saved — whether saved by a user through a screen or written by another Process.

Save-Triggered Processes