How to copy a closed/completed RITM to a new RITM

[j_hale]

Is there a quick or easy way to make a copy of a closed RITM?

When a requester does not respond to our follow up emails after several attempts we close their RITM with a "canceled" status. On several occasions we receive a response from the requester AFTER the RITM has been closed, asking our team to then re-open the request and move forward with the software/hardware purchase.

Our organization has been manually copying all RITMs prematurely closed over to a new RITM and then pasting all the information in the fields of the new RITM.

I'm still new to SNOW so I do not know scripting and have limited access (non-admin), but I can reach-out to our support team for assistance.

I'm hoping to find a one-click method that will allow me to choose the closed RITM and then allow me to copy the closed RITM to a new RITM.

In Peoplesoft finance we would use a "copy from" function, enter the requisition number we wish to copy, and then create a new requisition from the closed requisition.

Thanks,

Jonathan Hale

[Chuck Tomasi]

Hi Jonathan,

Creating a new RITM carries some implications with it that I'm not sure you want to tackle at this point. For example, where was the previous workflow in it's process? Do you need to get approvals again on the new RITM? How do you know? Do you tie the new RITM to the old REQ or create a new one? Was there a workflow on that REQ that needs to be honored? Lots of little things like that can drive you nuts when copying a record from one place to the next and trying to preserve state.

Option 1: Have the user start over with a new request.

Option 2: Provide the ability to re-open the old RITM (if you haven't canceled workflows, approvals, child tasks, etc.)

[sumiche]

So ... there is no ability in SN to just COPY a record?

Copy / Clone a task? (copy / clone a task to a different RITM? (because same task is occasionally used again?)

Copy / Clone an RITM (and with option to create copies of its task too?)

Copy / Clone an REQ (and with option to copy its RITMs and their tasks?)

... and then edit these new records / prune / etc., and have them go on their own merry way?

(and, in case or REQ, the ability to create a relation back to the original, so people could trace a trail of relationships, if necessary?)

That seems _wrong_ that SN won't do this.
Maybe "everyone" shouldn't be able to copy, but surely SOME people should be able to!!
It would save a great amount of time!!!

SM (NYC user)

[Chuck Tomasi]

Not natively.

It's not a simple matter of "clone this record". Consider the variables. If you copy an REQ, do you copy all the fields? Including the requested_for? The state (closed)? You certainly don't want to copy active=false. So who's to say "These are the right fields to copy!" because they don't apply to everyone.

Then you get in to related records. If you copy the REQ, and it has seven RITMs, are you copying all of them? Every time? Hmmm.. What about the tasks? They're even more transactional. 

Have I mentioned attachments?

There's a bit of thinking that goes in to copying a record and not everyone wants the same things copied. Configurable would be the way to go. Use a UI action that says "Clone record" and pops up a bunch of fields you can check which ones to copy (with a configurable set of which fields appear and their default of checked/unchecked.) Perhaps an option for child records and attachments. You configure once which fields to put on that form and which ones are checked. Then in each copy request, you simply tweak the checkmarks.

If you feel it's important (or you like my idea), I invite you to open an enhancement request! Our product managers DO listen.

Enhancement requests: Tell us how you would improve the ServiceNow product 

[sumiche]

Yes, have one checkmark for each type of child and select master options, e.g., the state of the new record is "open" or "unassigned" or whatever the initial state is.

In my application ... EVERY major-record-star-set has a copy routine. Click the key to copy the parent, answer some select questions about select children, and voila, there is your copy ... open status, new dates, any people tagged into the master/child set have been verified as still acceptable in the spots they're tagged into (or they get set to select detail values),  Some star-sets have more options than other (we're experimenting (to good result) with those checkbox-type options). The original history/audit trail stuff is not copied, the per-record-comments are not copied. But some of the work that my data-sets represent ... occur over and over again. And a good original job ... becomes like a template for all subsequent work of the same time / same area. This methodology has worked quite well for the last ... 22 years.

In fact, I was VERY SURPRISED that SN _does_not_ have such a copy routine!!!

The entire database is a set of shared work of one kind or another ... and a lot of it is hard to share, over-controlled, over-worried. The KB ... should be run as a wiki, policed by everyone and controlled by exception, not ... with constant oversight of absolute correctness. I get tired thinking of the work I have to do ... not a quick edit here / edit there.

But it's a different mind-set that my own.

I _will_ submit an enhancement request!

Thanks for your response.

SM