@████████ or @████████ have either of you ever had drafts not save?

I have not had this issue, but we do not use Drafts for most of our processes.

I haven't had any recent reports of this, but I also moved to a new district, and we are not heavy on drafts.  Previously, we used drafts on many processes but mostly external and did not have issues.  Are you still on the same version as you were in December?

No we are on v12 now and have run the April update. Thanks for the response!

I'll run some tests and see if I can duplicate, we are on the same version as well.

Where are you seeing the data saved?  I did a few tests and I can see where it stores the draft email, name, submission ID and date but not any data that is saved in the draft.  I ran a test against the [LF_Forms].[dbo].[cf_bp_data] table using the draft button as an internal user and it only stores the original data submission, not anything I updated but saved as a draft.

Merry Christmas! Swap out [YOUR_DB_NAME] with your forms server name. You need the submissionID from the draft you need as well.

 

-- Rebuild FullVar using the same logic as your sample (left of '_.', right of '.')
-- while avoiding row explosion.
SELECT
    d.submission_id,
    d.attribute_id,
    fld.label AS FieldLabel,
    d.bp_data_id,
    d.value,
    FullVar =
        CASE
            WHEN mL.name IS NULL AND mR.name IS NULL
                THEN m.name
            ELSE
                CONCAT(
                    ISNULL(mL.name, ''),
                    CASE WHEN mL.name IS NOT NULL AND mR.name IS NOT NULL THEN '\' ELSE '' END,
                    ISNULL(mR.name, '')
                )
        END
FROM [YOUR_DB_NAME].[dbo].[cf_bp_data] AS d

OUTER APPLY (
    SELECT TOP (1)
        f.label
    FROM [YOUR_DB_NAME].[dbo].[cf_fields] AS f
    WHERE f.attribute_id = d.attribute_id
    ORDER BY f.field_id
) AS fld

OUTER APPLY (
    SELECT TOP (1)
           b.member_id,
           b.member_path
    FROM [YOUR_DB_NAME].[dbo].[cf_bp_dataset] AS b
    WHERE b.attribute_id = d.attribute_id
    ORDER BY
        CASE WHEN b.member_path LIKE '%[_].%' THEN 0 ELSE 1 END,
        LEN(b.member_path),
        b.member_path
) AS pick

JOIN [YOUR_DB_NAME].[dbo].[members] AS m
    ON m.id = pick.member_id

OUTER APPLY (
    SELECT
        left_id = TRY_CAST(
            LEFT(
                pick.member_path,
                NULLIF(CHARINDEX('_.', pick.member_path), 0) - 1
            ) AS INT
        ),
        right_id = TRY_CAST(
            SUBSTRING(
                pick.member_path,
                NULLIF(CHARINDEX('.', pick.member_path), 0) + 1,
                4000
            ) AS INT
        )
) AS parts

LEFT JOIN [YOUR_DB_NAME].[dbo].[members] AS mL
    ON mL.id = parts.left_id

LEFT JOIN [YOUR_DB_NAME].[dbo].[members] AS mR
    ON mR.id = parts.right_id

WHERE d.submission_id = 16431
-- AND m.name = 'singleDate_mi'

ORDER BY FullVar, d.bp_data_id;

I wasn't able to reproduce the issue and the script you gave does show the values that were submitted on the initial Start but nothing updated and stored as a draft.  My understanding that those values do not come through until an actual submission happens.  

Yep, that's correct. I can see the values but they do not appear for the original user nor anyone that reassigns afterwards. In this scenario this is NOT the message start event. 
The values are stored as a draft before the submission happens. That is where that query comes in handy. It grabs the values without being submitted when it is saved as draft. There is another query required to get the submission ID of the draft to them pull the data. 

I cannot reproduce the issue on command. It is always am emergency where a user tells me they have been saving a draft for weeks and have lost all their data and no longer know what they saved because they rely on the save as draft feature.  

 

Update: We have a ticket in with LF Support. This issue cannot be reproduced on command but I can prove that a draft exists and data is present in the database but that data does not reach the Form. All the usual tables that show a draft is present show the submission_id for the draft in question. 

Since we can access the draft data, we have a time consuming and tedious workaround where myself or team member manually keys in all the missing data. 

I would bet that LF Support drops this ticket like a hot rock since it cannot be reproduced. If so, I'll add to the clues and details when it happens again. 

LF Support requested the entire Forms database to analyze. I am super grateful they took additional steps and didn't cancel the ticket. I got that off to them last Friday. 

@████████ and @████████ was there something that led you to stop using drafts? Or was this something that just never got put into use? Thanks!

I still use drafts and never have much of a problem other than user errors which are little things like they forgot they saved it as a draft and thought they actually submitted it.  Even from an external public form, I haven't run into the issue you are referring to.  I do give a limit on how long drafts will be kept though to protect users from submitting very old drafts after form updates have been made.

It's not that we have "stopped" using drafts, it's more that they just aren't as useful in the processes we are currently using.

Hi Chris,

I see our support should have updated your ticket with a detailed analysis and resolution, have you reviewed it? If you have any questions or concerns, post here or update the ticket so we can help you.