An incomplete form can contain useful intent, but it does not carry the same meaning as a submitted response. Partial-response architecture works only when draft identity, completion state, delivery timing, destination schema, and retention rules make that distinction explicit.
Model a draft as changing state, not a stream of submissions
Saving every field change as a new response creates artificial volume and makes it difficult to reconstruct the customer’s latest position. A session-scoped draft instead represents the current known progress for one form visit and can be updated as answers or navigation state change.
In OK Flows, drafts are unique by form and session. The stored state includes answers, visitor context, the last step, the last question, metadata, and the last-saved timestamp. This provides an operational snapshot without declaring that the respondent completed the experience.
- Use one stable draft identifier per form session.
- Update the snapshot rather than appending a record for each keystroke.
- Keep the last meaningful progress position with the answers.
- Treat client and server draft writes as best-effort so capture cannot block the form.
Make completion a state transition
Final submit should create the completed response first, then mark the corresponding draft as completed and connect it to that response. That transition prevents a scheduled partial process from later treating the same session as abandoned.
Salesforce documents CloudPages Smart Capture journey admission around customers who submit a form. A partial-response workflow is therefore a separate implementation decision: unfinished progress should not enter a completion-triggered journey merely because some fields contain values.
- Draft: mutable, incomplete session state.
- Completed response: immutable submitted outcome.
- Partial delivery: optional copy of incomplete state for a recovery purpose.
- Final delivery: mapped outcome associated with the completed response.
Use a quiet period before classifying abandonment
A pause is not automatically abandonment. The respondent may be reading, switching applications, checking information, or returning after a short interruption. Synchronizing a draft immediately after every save can trigger recovery actions while the person is still actively completing the flow.
Use the last-saved timestamp and a configurable quiet period to identify eligible stale drafts. The appropriate delay depends on journey length, question complexity, channel, and the urgency of the follow-up. A manual operational sync can have different controls from an automated schedule, but both should preserve the same incomplete-state marker.
Design a destination for partial intent
Do not map partial progress into a Data Extension that downstream users interpret as completed submissions. Create a destination or record contract with an explicit partial status, draft identifier, session identifier, last progress position, last-saved timestamp, and only the answers appropriate for recovery use.
The identity available at abandonment may also be weaker than the identity available at final submit. If a trusted customer key was resolved securely, it can connect the partial to the intended audience record. If only anonymous session context exists, do not infer a person from incomplete or ambiguous answers.
- Explicit record type or completion status.
- Stable draft and session identifiers for deduplication.
- Last step, total steps, and last-saved timestamp.
- Trusted audience key only when it was resolved through the intended identity contract.
- A retention date or policy appropriate for unfinished data.
Separate recovery eligibility from contact permission
Possessing a partial answer or email address does not by itself establish permission to send a recovery message. The activation workflow must evaluate the organization’s existing communication permissions, suppression rules, campaign context, and legal requirements before contacting the person.
This is especially important when the form itself collects permission. An unfinished answer to a consent question should not be interpreted as affirmative permission. Privacy and legal owners should define which partial fields may be retained and which recovery actions are allowed.
Make successful transfer and retention explicit
When OK Flows successfully delivers an eligible partial payload, that draft is removed from the local draft store. The receiving Salesforce architecture must therefore own the retention period, deduplication strategy, recovery status, and eventual deletion of the transferred partial record.
Salesforce Data Extensions support retention configuration, including time units and row-based or object-level behavior. Choose those settings based on the partial-data purpose rather than inheriting the retention policy of the completed-response destination.
- What proves the partial was accepted by the destination?
- How does a later completed response suppress or close recovery activity?
- How long is unfinished data retained, and why?
- Can a repeated sync update the same partial record safely?
- Which team owns failed delivery and deletion requests?
Test the race conditions
The most important tests happen at state boundaries: a scheduled partial sync starting at the same moment as final submit, a browser closing before the last debounced save, a destination timeout after accepting the payload, or a customer completing through another device after a partial was transferred.
A robust design can identify which state won, prevent a recovery action after known completion, and preserve the respondent’s submitted answer even when downstream delivery fails.