Universal request

[kummara _siva]

Hi ,I'm working on universal request.

I have created a incident from ur and then I want to transfer to different department .I selected not sure in the department type .actually it is closing the existing ur and creating a new one .but i don't want that it should route back same ur .How can we achieve this. Also in the servicesets table the record for ur is set to ture

Thanks in advance .

[Vikram Reddy]

Hello @kummara _siva,

Go check the record behind that "Not sure" option before you touch anything else. Open universal_request_service_set, find the row where Universal Set is true, and look at what's actually wired to it beyond that flag:

universal_request_service_set
  Name: Universal Request
  Universal Set: true          (this is the row your screenshot shows)
  Assignment group: ?
  Catalog item / record producer: ?

Universal Set = true only tells the platform "this is where a 'Not sure' transfer lands." It does not, by itself, spin up a follow-on ticket. Compare that to a normal named-department transfer: when you pick an actual department, the platform clears the Primary Ticket field on the existing UR, creates the new departmental record (incident, case, whatever), and repopulates Primary Ticket back on that same UR, same sys_id, with work notes logged on both records. That is the documented, expected flow.

"Not sure" does not behave the same way in most instances. Because the Universal Set service set usually has no catalog item or record producer attached to it, there is nothing for the platform to spin up as the new primary ticket once it lands there. What a lot of people run into in this exact scenario, and it lines up with what you're describing, is that instead of clearing and repopulating Primary Ticket on the same UR, the platform closes the current incident and generates a brand new Universal Request shell with no primary ticket at all. That's the "closing and creating a new one" behavior you're seeing. It's the routing target that's incomplete, not the Universal Set flag you already verified.

A few things worth doing from here:

• Stop treating "Not sure" as a routine transfer path. It's built for genuine last-resort intake, not day to day department handoffs. Using it as a general escape hatch is what's producing the orphaned UR.
• Stand up a real triage Service Set instead. Give it its own assignment group and a UR-certified catalog item or record producer, so anything routed there actually creates a ticket and keeps riding on the same UR instead of dead-ending.
• Confirm continuity yourself. Transfer a UR to a specific named department and note the UR sys_id before and after, it should not change. Then repeat with "Not sure" and compare. That tells you for certain whether it's spinning up a new master record or just clearing the primary ticket link.
• Check for a known defect on your version. There's a ServiceNow support KB (KB0999136) on universal request ticket transfer not working as expected, worth pulling up or comparing against your instance patch level before you assume this is purely a config gap on your side.

Thank you,
Vikram Karety
Octigo Solutions INC

[kummara _siva]

Asking for kb content .

[kummara _siva]

Thanks, Vikram.

Can you share the kb link or content

[Vikram Reddy]

Hey @kummara _siva,

Here's the direct link: KB0999136, "Universal request ticket transfer is not working as expected". Fair warning though, that's on the Now Support portal, so it sits behind your HI login, not the Community. I can't paste the full body here since I don't have access to your instance's support entitlement, but I can tell you what it actually covers so you're not wasting time chasing the wrong thing.

The scenario documented in that KB isn't your "Not sure" case, it's a different symptom: an HR case with a UR attached, transferred while impersonating the assigned-to user, targeting an IS incident, that throws an error instead of creating the new incident. Same general bucket, transfer not behaving as the docs describe, but a different trigger and a different failure mode than the silent close-and-recreate you're seeing. Worth pulling up on your instance anyway since KBs like this often get symptom variants added over time, but don't expect it to be a line-for-line match.

Since that KB won't hand you the fix directly, go back to the actual mechanism. A few people have hit the same "Not sure" stall you're describing, and it traces back to the same root cause every time:

• No Universal Set record at all. If universal_request_service_set has nothing with Universal Set = true, the "Not sure" transfer has no target and just fails or hangs.
• A Universal Set record with no catalog item or record producer attached. This is your situation. The row exists, so the transfer doesn't error out, but there's nothing for the platform to spin up as the new primary ticket, so it clears the old one and leaves you with an orphaned UR instead.

Since your Universal Set flag is already true, the fix is filling in what's missing on that same record, not creating a new one:

1. Open the universal_request_service_set record where Universal Set = true.
2. Attach a UR-certified catalog item or record producer to it, the same way your named departments have one wired up.
3. Set a real assignment group on it so whatever gets created lands somewhere a human will see it.
4. Re-test the "Not sure" transfer and check the UR's sys_id before and after. If it's genuinely fixed, the sys_id stays the same and Primary Ticket repopulates instead of the record closing.

If after that it's still closing and spawning a new UR instead of reusing the same one, that's no longer a config gap, that's a defect worth a HI case with your build number and the before/after sys_ids in hand. Support can check it against the specific fix version tied to KB0999136 or open a new one if your symptom doesn't match it.

Thank you,
Vikram Karety
Octigo Solutions INC