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, orIf a custom parameter was made "required" but had not yet been filled in on the Drafts, orA new custom parameter was added to Custom Form A, orThe form logic on Custom Form A is added or modified relative to what was in place when the Drafts were created, orIf 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

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 goneIf 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 SubmitA new custom parameter was added to Custom Form A -- sticking with my update expectation here, that new field would now showThe 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 DraftIf 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

Doug_Den_Hoed__AtAppStore

Community Advisor

Fråga

New "Drafts" feature Q&A

Forum|Forum|5 years ago
August 23, 2020
4 svar
1679 visningar

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

Det här ämnet har stängts för svar.

Heather_Kulbacki

Community Advisor

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

Adobe Employee

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

Skribent

Community Advisor

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

Adobe Employee

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

Skribent

Community Advisor

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

Adobe Employee

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

K

KevinQu1

Level 10

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

Adobe Employee

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

K

KevinQu1

Level 10

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."

Anmäl dig

Logga in med socialt nätverk

Logga in på communityn.

Logga in med socialt nätverk

Söker efter virus i filen

Denna fil kan inte laddas ned