Forms and Data
How a Chronicle form reads and writes Salesforce data: when records are saved, how duplicates are avoided, how related records are created, and what is kept about each submission.
Designing the form itself is covered in the Form Builder guide. The settings here mostly live in the template's Behavior panel, and they decide what actually lands in your org.
Access
Access sets the direction of data flow between the form and the record it's bound to.
| Mode | What it does |
|---|---|
| Read / Write | The default. Existing values load into the form, and answers are written back. |
| Read Only | Values load, but every input is disabled and nothing is written. |
| Write Only | Nothing is read. Inputs stay editable and saving works normally, but no existing record data ever reaches the form. |
Write Only is a deliberate hard stop for sensitive forms. Existing values are never loaded, and merge tags that would pull from the record resolve to empty rather than exposing a value. Literal pre-fill defaults and static values still apply. Use it when the person filling the form should not see what's already on the record.
Lock Behavior
Lock Behavior decides what happens when someone reopens a form that has already been submitted. It is separate from Access: Access is about direction, this is about lifetime.
| Setting | What it does |
|---|---|
| Never lock | The default. A completed form can be reopened and resubmitted, rewriting the same record. |
| Lock once submitted | Once the submission is Completed, the form is frozen. |
Locking matters because a form's link is durable. It lives in emails, browser history, and any link a Flow generated. Without a lock, reopening that link shows a fully editable form pre-filled with the previous answers, and submitting rewrites the record. For a consent or attestation that has already been signed and acted on, that is rarely what you want.
The freeze covers reading as well as writing. A locked, completed form shows its completion screen instead of the form, the previous answers are never sent to the browser, and attempts to save or add a signature are rejected. If the template returns to the start on finish, Start again opens a genuinely fresh submission rather than reopening the old one.
Save Mode
Save Mode decides when answers reach the bound record.
| Mode | What it does |
|---|---|
| On Submit | The default. Each Continue stages answers on the submission so progress can be resumed, and the record is written once, at submit. |
| Progressive | The record is written on every Continue. |
On Submit is usually what you want. It avoids half-finished records, lets record-level validation see the whole form at once, and makes duplicate matching reliable because every answer is known before the first write.
Saving early on a specific page. In On Submit mode, each page has a Save when leaving this page toggle. Turning it on commits everything staged so far when the user continues past that page, then refreshes the record so formula and other calculated fields are available to merge tags on later pages.
A note on file uploads. Files and signatures attach to the submission as they're added. In On Submit mode, a file added before the record exists stays on the submission rather than also appearing on the bound record.
Avoiding duplicate records
Deduplicate on takes a list of fields on the form's main object. When a form is about to create a new record, Chronicle first looks for an existing record whose values match all of those fields, and updates that record instead of inserting a second one. If more than one matches, the most recently modified wins.
This only applies when creating. A form opened against an existing record always updates that record. Matching is also skipped when any of the match values is blank, so a half-empty form can't collide with an unrelated record.
Because all answers are known at a single write, this pairs naturally with On Submit mode, and the match field can live on any page of the form.
Find or create parent records
A form writes to one object, but records rarely stand alone. Parent records rules let a form find, or optionally create, a related record on completion and link it to the record just submitted, with no code and no Flow.
A common example: a form that captures a case or registration, and needs the Contact it belongs to. The rule finds a Contact by email address, creates one if there's no match, and stamps it into the submitted record's Contact lookup.
Rules are edited in the Pre-fill & Static Values section of the template panel. Each rule needs:
| Setting | Meaning |
|---|---|
| Lookup field | A lookup on the form's main object. The target object is derived from it automatically. |
| Field mappings | Which values from the submitted record are copied to the parent record. |
| Match on | Exactly one mapping is the match key, the field compared to find an existing record. |
| Create if not found | Whether to create the parent when nothing matches. |
Rules run when the form is completed, on forms bound to a record. If more than one record matches, the most recently modified wins. When a rule can't be applied, it is skipped and the submission still completes, so a misconfigured rule never blocks a user.
Parent rules write to objects outside the form's own object, and they run for guest users on public forms too. Configure them with that in mind.
Related Records
Where parent rules point the submitted record at one related record, Related Records goes the other way: the person filling the form adds as many rows as they need, and each row becomes a child record linked back to the submitted record.
Add a Related Records cell to a page and configure it:
| Setting | Meaning |
|---|---|
| Child object | The object each row creates. |
| Relationship field | The lookup on the child object pointing back to the form's main object. It's stamped automatically on save. |
| Row Content | Simple fields to build a small set of fields inline, or Use a form template to reuse an existing template built on the child object. |
| Match on field(s) | Optional. When set, a row that matches an existing child record updates it instead of creating another. |
| Minimum / maximum rows | How many rows the user must and may add. |
Rows are staged until the form is completed. They're held on the submission as the user works, so a half-finished form resumes with its rows intact, and the real child records are written when the form is submitted. A form that isn't bound to a record has nothing to link rows to, so rows stay staged and never materialize.
Rows are added and updated, never deleted. Removing a row from a form does not delete a child record it created on an earlier visit.
Reusing a template for rows keeps one definition in one place: point the cell at a template built on the child object, and the form renders that template's fields as the row content, always using its currently active version. Those templates can be one level deep only, so a template used for rows cannot itself contain a Related Records cell. Exporting a form brings its row templates along.
Display tables
A Data Table cell shows a read-only table inside the form. It has two sources:
- From a field. The cell reads a field holding a JSON array of rows, and each column picks one property from each row. Use this when the host page or an earlier process has already assembled the data.
- From a query. The cell defines an object, a filter, and a sort, and Chronicle runs the query when the form loads. The filter can compare against a fixed value or a live field on the form, in which case the table updates as that field changes.
Two things to know before using one on a public form. The query runs in system mode, so it returns records to anyone who opens the form: only query data you're comfortable exposing. And values render exactly as stored, so a picklist shows its stored value rather than its label, a lookup shows an Id, and a date shows in ISO format. Pre-format the values if presentation matters.
What is kept about each submission
Every submission keeps a log of what happened to it: each successful save, and each failure with the underlying Salesforce error. Add the Submissions Log component to the Form record page to read it. This is the fastest way to answer "the user says they submitted it, so where did it go", because a validation rule or permission error that was hidden from the user is recorded here in full.
Save a copy of each submission is a toggle in the template's Behavior section. When it's on, every successful save also records the full set of submitted values.
This setting is on by default for newly created templates, and it stores personal data. The saved copy includes whatever the form collected, so it is subject to the same retention and privacy expectations as any other record of that data. Turn it off for forms where you don't want a second copy, and leave it on when you need a durable record of exactly what someone submitted.
Existing templates are unaffected: the copy is only kept where the toggle has been switched on.