Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
Cloning Requested Items - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • Cloning Requested Items
KB0777685

Cloning Requested Items


1019 Views Last updated : Jul 24, 2025 public Copy Permalink
KB Summary by Now Assist

Issue

The user followed the documentation to Clone requests. While this did successfully place 10 reference fields on the checkout cart page, REQ, RITM, and SCTASK records do not contain the correct "Requested For" values for the new users entered in those reference fields. Instead, each of cloned REQs has the same information as the original REQ ("Requested For" information included).

Resolution

After some time, it was found that the behavior the user was experiencing was expected per their configuration.

In an Out of Box (OOB) scenario, there is a parent Request (REQ) which has the "requested_for" field, and then the same field appears on the Requested Item (RITM) via dot-walking (request.requested for). The same dot-walking applies for Service Catalog Task (SCTASK) records (in this case, request item.requested for).

This is how the proper names are carried consistently down through each level of the REQ > RITM > SCTASK, and why this works fine OOB.

In the user's case, however, they have variable values which are entered when the item is ordered. The variable values are not going to change per cloned request, because the initial values entered in those variables should not naturally change. It makes sense to clone them. The idea of cloning requests is to process the same request for someone else. That's the function of this cloning tool.

For example, if hypothetical user Stephen Strange requests a new cell phone with a variable asking for a color for the phone, and he chooses "infinity-stone green" and then clones the request, all Requests will have RITMs showing the "Color" variable question's answer as "infinity-stone green". This is expected. Stephen is cloning the details of the request. He is just changing who the request is requested for (e.g. changing it to also be requested for Tony Stark, Steve Rogers, etc). This happens just fine until the Flow attached to the Catalog Item runs.

Why the requested_for value is always changing back to the original requestor in the user's case is because they have a Flow which is setting the "requested_for" value back to the variable value stored in custom variable "u_requested_for" (see Flow "Submit Custom Request").

To be sure, when the cloned REQs are initially submitted, the correct "requested_for" is set. Only after the Flows associated with the child RITM kicks off is the value set back to the original request's "requested_for" value. This is what needs to fixed.


The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.