# Submission Saving Rules
This page explains, from a functional perspective, what happens every time a [submission](/user-documentation/components-concepts-terminology.md#submission) is saved — from field validation and workflow transitions to formula recalculation, automation execution, and notifications.
Understanding this sequence helps you design forms, automations, and workflows that behave exactly as you expect.
## FAQ
When a workflow state changes, which state do conditions and formulas see — the old one or the new one?
**Always the new state.** The transition is applied during the save, before write automations, formulas, conditions, and read automations. From that point on, every step evaluates the submission with its new state. A condition like *"workflow state is Approved"* is true during the very same save that performed the *Approve* transition.
Can a write automation see formula values computed during the same save?
**No.** Write automations run before formulas are calculated, so they still see the formula values from the *previous* save. If an automation needs to react to a formula result, use a read automation instead — those run after formulas are recalculated and see the fresh values.
Can a read automation see formula values computed during the same save?
**Yes.** Read automations (reports, webhooks, emails, mobile notifications) run after formulas are recalculated, so the data they receive reflects the fully computed submission, including all formula fields freshly calculated during this save.
If a save fails, what gets rolled back?
Everything inside the protected save is cancelled: submission data, relation changes, and write-automation side-effects are not saved; uploaded files are not moved to permanent storage; no task is created. The sequential number reserved before the save is *not* reused (gaps are normal). Steps that run after the save — notifications, formulas, read automations — never execute if the save fails.
Are formulas on linked submissions recalculated every time I save?
On normal saves (web, mobile, single-record), yes — formulas on related submissions that reference the current one are recalculated, with large relation graphs handled in the background. For mass updates, imports, and migrations, this is deferred to a background job that runs afterward.
What is a "one-time calculation" formula?
A one-time calculation formula computes its value once — typically at creation — and then keeps it forever. On later saves the existing value is preserved and never re-evaluated. Use it to stamp a value that must never change, such as a "received at" date.
Do read automations fire when I edit a closed submission?
It depends on the save. A simple edit with no workflow transition on an already-closed submission skips read automations. A save that *transitions* the submission to a final state does run read automations for that save.
What is partial mode, and when is it used?
Partial mode disables required-field validation so a submission can be saved with mandatory fields still empty. It is used for mobile offline saves (a field worker saves a partially filled submission to sync later) and data imports (rows that don't contain every required field). Workflow transitions are not allowed in partial mode.
If I change a field a formula depends on, when does the formula update?
Formula fields are recalculated after the save is confirmed. The response returned to the screen after saving already contains the freshly computed values, so you see the update immediately.
## The big picture
Saving a submission is not a single instant operation. It runs as a sequence split into three phases:
1. **Before the save** — lightweight preparation (sequencing, loading the form definition, recording who is currently assigned).
2. **The save itself** — the core write, protected as all-or-nothing: validation, workflow transition, and write automations. If any step fails, the whole save is cancelled and nothing is partially written.
3. **After the save** — enrichment that runs once the save is confirmed: formulas, conditions, read automations, history, and notifications.
{% hint style="warning" %}
**The save itself is all-or-nothing.** If any step fails — a missing required field, a deleted [relation](/user-documentation/components-concepts-terminology.md#relation), an invalid workflow transition — the entire save is cancelled and nothing is saved.
{% endhint %}
## Phase 1 — Before the save
These steps run before the protected save begins.
| Step | What happens | Why it matters |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Sequential number | A new submission is assigned a unique, ever-increasing number within its form. | The number is permanent — it never changes, even after edits. If the save ultimately fails, the reserved number is not reused, so gaps in the sequence are normal. |
| Form definition loading | The platform loads the fields, workflow, conditions, and formula configuration for the [version](/user-documentation/components-concepts-terminology.md#version) attached to the submission. | Validation always applies the rules of the version linked to the submission. |
| Workflow start state | A new submission whose form has a workflow is automatically placed in the start state. | A new submission always begins its lifecycle in the correct initial state, even if the user did not choose one. |
| Assignee snapshot | For an existing submission, the platform records who is currently assigned and subscribed. | Only users who are *newly* assigned or subscribed will be notified later — not those who were already there. |
## Phase 2 — The save itself
### Form migration
If the form has been updated since the submission was last opened, the submission is automatically migrated to the latest active version before validation, so the most recent rules always apply.
**What you see:** you can save a submission even if the form changed since you opened it — the platform adapts it automatically. If migration is impossible, the save is rejected.
### Field validation
Every field is validated:
* **Standard fields** (text, number, date, list, user, files…) are checked for type, required rules, and format.
* **Relation fields** are checked for cardinality (minimum / maximum linked submissions) and that the linked submissions still exist.
* **System fields** cannot be written by the user and are ignored.
* In **partial mode** (mobile offline saves, imports), the required-field rule is skipped so incomplete submissions can be saved progressively.
{% hint style="info" %}
**Inactive user in a user field:** assigning an inactive user to a user field is rejected — unless that same inactive user was already in the field before the save, in which case the value is preserved to avoid breaking existing data.
{% endhint %}
### Workflow transition
This is where the workflow state actually changes. When a save includes a workflow action (the user clicked a transition such as *Submit for validation* or *Approve*), the platform applies the transition here and recomputes the submission's visibility conditions against the new state.
**From this point on, every later step — write automations, formulas, conditions, read automations — sees the new workflow state.**
### Write automations
Write automations modify the submission's own data as part of the save. They run right after the workflow transition and always see the new state. Because they run inside the protected save, if one fails the whole save is cancelled.
| Write automation | What it does |
| ------------------------- | ------------------------------------------------------------------------------------------- |
| **Change assignation** | Assigns or reassigns the submission to a user or group based on conditions. |
| **Change workflow state** | Forces a second workflow transition automatically (for example, auto-close after approval). |
| **Modify field value** | Sets or clears the value of fields on the submission. |
{% hint style="warning" %}
A write automation's condition is evaluated against the field values as saved by the user and the new workflow state. It does **not** yet see formula results — formulas are calculated later, after the save. If your automation needs to react to a formula, use a read automation instead.
{% endhint %}
### Files and tasks
Uploaded files are moved to their permanent storage only once the save is confirmed, so a failed save never leaves orphaned files. If the form is configured to create a [task](/user-documentation/components-concepts-terminology.md#task) automatically, that task is created and linked here.
## Phase 3 — After the save
Once the submission is safely saved, a second sequence of enrichment and notification steps runs. These steps do **not** cancel the save if they fail — the submission is already saved.
### Push notifications
The platform compares the current assignee and subscriber list against the snapshot taken before the save. Any newly assigned or newly subscribed user receives a mobile push notification.
### Formula calculation
All formula fields are recalculated here, on the saved submission — so they see the new workflow state, the user-saved values, and any changes made by write automations.
* If the submission is linked to other submissions through relation fields, formulas on those related submissions may also be recalculated (for example, an aggregation formula on a parent submission). For large relation graphs, this is handled in the background to keep saves fast.
* For mass updates, imports, and migrations, recalculation on related submissions is deferred to a background job to avoid overloading the platform.
* **One-time calculation formulas** compute their value once and then keep it forever — useful for stamping a "received at" date or a "created by" value that must never change.
### Conditions
All conditions (field visibility, required-field overrides, section visibility) are recomputed against the final state of the submission, with formulas already applied, and the result is cached so the next time the submission is displayed the correct field visibility is immediately available.
### Read automations
Read automations react to the save but do not modify the submission's data. They run after formulas and conditions, so they see the fully enriched submission.
| Read automation | What it does |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **Simple report** | Generates a [report](/user-documentation/components-concepts-terminology.md#report) from a template and attaches or sends it. |
| **Mobile notification** | Sends a targeted push notification to specified users or groups. |
| **Webhook** | Calls an external endpoint with the submission's data, for integration with third-party systems. |
| **Send email** | Sends a formatted email to configured recipients. |
{% hint style="warning" %}
**Closed submissions:** if a submission is already in a final (closed) state and the save does not include a workflow transition, read automations are skipped — this prevents spurious notifications or reports on minor edits to closed submissions. If the save is the transition that *brings* the submission to a final state, read automations do run for that save.
{% endhint %}
### Restoration history
A snapshot of the submission's field values (as they are after the full save) is stored in the history log. This snapshot is what lets administrators restore a submission to a previous state.
## Special cases
| Scenario | What changes |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Partial mode** (mobile offline, import) | Required-field and cardinality minimums are not enforced. Workflow transitions are not allowed. |
| **Pre-fill** | All automations are skipped; formulas return only pre-fill values. Used to pre-populate a submission before it is officially created. |
| **Mass update / import / migration** | Formula recalculation on related submissions and scheduled-job updates are deferred to protect the platform when many submissions change at once. |
| **Created on behalf of another user** | The submission is attributed to the target user, and the history records the ownership change. |
| **Restored from history** | The restored data is applied as a normal save; automations and formulas run as usual, and the workflow state from the snapshot is reinstated. |
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://www.center.daxium-air.com/user-documentation/support/admin-support/submission-saving-rules.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.