Copy Service Request

[anbu2]

Hi All, I'm trying here to copy the existing service request to create a new one. Once the 'Copy' option is selected, it should not automatically create the new ticket, it should just bring the user to a new form with all of the same user-input fields copied (SD, Description, any other RITM-specific catalog variables);   the user should still be required to review the form and submit (and have the capability to add a new attachment, since any old attachments will not carry over) I also had a chance to try the OOB functionality but that doesn't suit my requirement i would like a "Copy" feature to be specific.

[Uncle Rob]

Not knowing your environment I have to assume you have at least some complexity when it comes to catalog items and workflow.   The reason this shouldn't be treated as a database copy is that you need to make sure the variable data is right before insert.   When you launch a catalog item, the workflow gets launched.   That workflow could be making all kinds of decisions based on the variable data on insert.

So if you're changing variable data after the insert... too late... the workflow is already in flight.

[anbu2]

Yes i agree with your point in my case i'm quite sure that there will be only change in the description and short description variables on the catalog form apart from that there could be users adding attachments. Other variables which decides the flow of workflow will remain same.

[Uncle Rob]

Hmmm... is this just one kind of Catalog Item, or does the copy feature need to apply to any/all Catalog Items?

[jbauguess]

We have a "Copy Request" from a catalog item.   I wrote about it here.   I may need to update the code in the gist in that link, because I have modified it recently (nothing was broken, I think I just cleaned up the code some).

It's a variable set with a reference to request items, and it filters based on the current catalog item.   When you populate the field, it gets all the values from that request item's variables and fills out the form.   That way, you could change one or two things if needed.   We use this for onboarding requests (new employees, revising contractor end dates).

You can add "exclusions" as well, to make sure certain pieces of data do not come over.   In the example above, I don't want the start date from a previous request to come over, because they may be copying a request from 2 years ago, and a new employee would not be starting their first day of work on such a date.

[anbu2]

Hey Justin, I don't see the code in that article can you please copy paste the code here