New "Drafts" feature Q&A

[Doug_Den_Hoed__AtAppStore]

Well, Q's to start with, at least, but looking for some A's...

For context, the Requests can now be saved in Draft mode, and now support multiple Drafts per Queue Topic:

• The "Draft Saved" automatically occurs as data entry progresses (e.g. once the Name is entered), but for situations where Drafts are either inappropriate, unwanted, or would complicate a workflow, how can the Draft feature be turned off, either globally, or by Request Queue, or by Queue Topic?
• When a Draft is saved, an API search on OpTask (e.g. by name) fails to retrieve the draft, and as there does not yet seem to be any additional information about Drafts in the API Explorer, how can Drafts be detected and examined via the API?

Assuming one or more Drafts exist that refer to "Custom Form A", what is intended to happen ("As Designed") to the custom data entered on those Drafts if:

• a custom parameter on Custom Form A was deleted or removed, or
• If a custom parameter was made "required" but had not yet been filled in on the Drafts, or
• A new custom parameter was added to Custom Form A, or
• The form logic on Custom Form A is added or modified relative to what was in place when the Drafts were created, or
• If user decides to add an additional Custom Form B to all existing Requests via Bulk update, how can such a bulk update also be made to those Drafts?

Regards,

Doug

[Heather_Kulbacki]

For your second part, I can't answer what is intended to happen "as designed" but my (sometimes high) expectations would be:

• a custom parameter on Custom Form A was deleted or removed -- I would expect the form to update the next time the user went in to continue making edits or Submit, meaning that parameter would be gone
• If a custom parameter was made "required" but had not yet been filled in on the Drafts -- again I would expect the form up update the next time the user went in to continue making edits or Submit, that field would need to be filled in before allowing them to Submit
• A new custom parameter was added to Custom Form A -- sticking with my update expectation here, that new field would now show
• The form logic on Custom Form A is added or modified relative to what was in place when the Drafts were created -- again updates should show on Custom Form A when the user goes back into that Draft
• If user decides to add an additional Custom Form B to all existing Requests via Bulk update, how can such a bulk update also be made to those Drafts? -- Here I would only expect the additional form to be added if it was also added to the request queue that the draft was created from - if that's not possible, then I would expect to be able to search/report on all drafts and add the form manually with a Bulk edit

[Anna_Asatryan]

Hi Doug,

Thank you for the questions.

Heather, thank you as well for the answers. They are all correct and that's how it works now, except for the last one. If an additional custom form is attached to the topic/queue for which there is already a draft created, next time the user opens the draft to submit the request, the request form will show the newly added custom form.

Doug, as for the first 2 questions:

• There is no way to turn off the draft functionality. Could you please explain a bit more what would be the situations where drafts would be inappropriate, unwanted, or would complicate a workflow ?
• The draft isn't yet an optask, that's why it can't be retrieved via an optask search API call. Currently, the drafts can't be accessed via the API.

Let me know if you have any other questions or feedback.

[Doug_Den_Hoed__AtAppStore]

Hi Anna, Thanks for confirming the intended behavior. One example where Drafts could inappropriate, unwanted, or would complicate a workflow would be a ticket submission that is tied to a Service Level Agreement (eg response within 4 hours of submission): I can easily imagine debates over a Draft not being fully or properly submitted leading to contention over SLA calcs. Regards, Doug

[Anna_Asatryan]

Hi Doug,

We implemented the drafts in an "auto draft" way so that users don't take any extra actions and if they do want to just submit the request, they can ignore the draft and it will be deleted when sent. So, there isn't an extra action required from the user if they don't want to deal with the draft.

Let me know if this answers your concern.

Kind Regards,

Anna

[Doug_Den_Hoed__AtAppStore]

Good point Anna, Auto-save preserves partial entry in cases where someone loses connectivity, gets interrupted or needs more time, which is preferable to both submitting the Issue prematurely or having to start over, and (I now agree) is “worth turning on”, even if there was an option to turn it off, so I withdraw my suggestion. My only remaining concern is that I cannot (yet) get at them with the API (noting I have no immediate need to do so). Regards, Doug

[Anna_Asatryan]

Thanks Doug! I am glad we clarified the first part.

For the API, let me check couple of thinks with the development team and get back to you.

Kind regards,

Anna

[Anna_Asatryan]

Hey Doug,

Sorry for the delay in getting back to you on this. There is a way to access the drafts via API now, but it can be done by the logged in user only. We currently don't plan to make it widely available via our API.

[Doug_Den_Hoed__AtAppStore]

Thanks for the update Anna.

Regards,

Doug

[CalvinFold]

I should note for anyone who uses layout templates and New Request is NOT in the first tab position under the Requests (issues) global nav. We have a request dashboard as the first tab and the New Request as the second tab, for example.

If you move the New Request button from the first position, then clicking on the name of the draft will not open that draft, it will open whatever dashboard is in the first position. OOPS!

Support is working on this. Putting the New Request button back to the first tab fixes the issue, though we haven't because the dashboard is more important than the draft mode right now.

[Anna_Asatryan]

Hi Kevin,

I apologise for the inconvenience caused by that issue. It has been already fixed and should reach production with this week's patch.

Kind regards,

Anna

[CalvinFold]

No worries Anna. I had intended to circle-back and update my comment after finding out the patch coming soon; think it goes in overnight tonight?

I only posted here in case someone else ran into this "surprise."