8.3 Posting Data

A diff of the bucket data (see Bucket Diff) is posted to the server on step save. This operation is performed asynchronously—the client need not wait for the step to save before the next can be requested.

Since validations are shared between the server and the client (see Validation), saving should only fail in exception situations. Should a failure occur, the server will instruct the client to kick the user back to the previous step (kickback).

A step cannot be saved if it is locked; such attempts will result in an error.

To prevent a user from skipping steps, the client may post only one step past the last step that has successfully saved; otherwise, the user is kicked back to the last step that was saved.

Once those basic checks have passed, the document is updated:

1. The diff is first sanitized to strip out unknown fields, internal fields posted by non-internal users, and to filter fields on permitted characters;
2. The sanitized diff is then applied to the existing bucket on the document;
3. Calculated values marked for storage (see Calculated Values) are re-calculated on the server (the values posted by the client have already been discarded by the first step in this list);
4. Server-side Data API calls (see Data API) are triggered using the diff as input data and an empty bucket for response storage (see Server-Side Data API Calls);
5. The last premium calculation date is cleared (indicating that premiums are no longer valid);²⁶
6. Data marked as sensitive is encrypted and the ciphertext written to the bucket in place of the plaintext (see Encryption Service);
7. The current step is incremented and the top visited step  is set to the larger of the incremented step or the existing top visited step id; and then
8. The new document state and bucket data are written to the database.