Help...how to manage catalog request drafts vs. item updates?

[Kristin J]

Hello! We recently implemented the "save as draft" functionality along with a couple catalogue items that are designed to be iterative (information is gathered and input over a period of time before the full form is submitted).

We are coming up against the situation where there are saved drafts for an Item that requires an update.  If we do nothing, these drafts are deleted when the system detects the update to the Item, and then when the user returns to their draft, they can only start over.

Is anyone out there proactively checking for existing drafts before an update, or better yet, has a way to re-map fields and rebuild a draft somehow? Deleting drafts is not acceptable for us as there is a lot of detail being submitted in these forms, and I'm concerned that we have released an unsustainable service.

Thank you for any help you can offer!
Kristin

@JayGervais  

[Sebastian L]

Hi, 

I am editing my response, as I found a property you can set: 

glide.sc.delete_draft_item_on_version_change. 

Set this property to false (create it) and it will not delete drafts with a different version. It should have this line in the widget "widget-sc-cat-item-v2"

[Kristin J]

Thank you for this tip! This could be work as part of our development/deployment process when we have changes to an item. We have to come up with something...I don't see how we would just quietly delete people's drafts without getting some negative consequences!

@JayGervais 

[Sebastian L]

If you set the property to "false" the system will never delete the draft, so the user will always keep it, even after you update the item!

"glide.sc.delete_draft_item_on_version_change" 

[Kristin J]

True! But depending on the change to the item, some things might break between draft and the republished item? I'm looking forward to testing it out and seeing what happens.