In SOW when create request from interaction catalog variable values are not being saved?

[vinimcc]

when i go to service operations workspace and create a catalog request, the request submits but when ope the request the field values are all empty. Works fine creating request from portal but not from SOW-Interaction. Also i have admin role

[vinimcc]

submitted form has empty mandatory fields even though they were submitted correctly

[vinimcc]

 1st shot above is for non portal ready service and second one is for portal ready, both create records in criable table sc_item_option_mtom but ony non portal one has values for the variables

[snehareddym]

When I create a request from an Interaction using the Create Request UI Action in Service Operations Workspace, the catalog variables are populated correctly and are not empty. I also verified this with the mandatory variables filled in before submission.

Could you please share the specific catalog item or any additional steps required to reproduce the issue?

[vinimcc]

the services in our cataolg are all created by the team . Most are portal ready and orderd through our portal. Some are non portal ready. The non portal ready ones persist variable values when ordered through 'create request' button from an interaction in SOW but the portal ready ones dont persist variable values. e.g. payload from portal ready:

Request URL

https://xxxdev.service-now.com/api/sn_sc/v1/servicecatalog/items/347b6350dbd46f84723ad024ce961968/or...

Request Method

POST

Status Code

200 OK

Remote Address

xxx

Referrer Policy

same-origin

1. {sysparm_quantity: 1, variables: {IO:1d7be350dbd46f84723ad024ce9619d1: "true",…},…}
1. delivery_address: "xxx"
2. get_portal_messages: "true"
3. sysparm_item_guid: "c49585641b51cf90b11cca21604bcb3d"
4. sysparm_no_validation: "true"
5. sysparm_quantity: 1
6. sysparm_requested_for: "83cef911e904300020939befc5e267c8"
7. sysparm_watch_list: {}
8. variables: {IO:1d7be350dbd46f84723ad024ce9619d1: "true",…}
1. Automation Variables: ""
2. IO:0d7be350dbd46f84723ad024ce961943: "83cef911e904300020939befc5e267c8"
3. IO:0eee8bae1b9d2290b11cca21604bcbf9: ""
4. IO:1d7be350dbd46f84723ad024ce9619d1: "true"
5. IO:02a05f6a1bdd2290b11cca21604bcbcf: ""
6. IO:2d7b2750dbd46f84723ad024ce9619e7: "true"
7. IO:2d7b2750dbd46f84723ad024ce9619ed: "8f9b4daddb611704492579fdae9619e9"
8. IO:6b5a610d1bda6810f1b9caab234bcb69: "Automation:NonPrivileged"

e.g. payload from non portal service

Request URL

https://xxxdev.service-now.com/amb/connect

Request Method

POST

Status Code

200 OK

Remote Address

xxx

Referrer Policy

same-origin

Request URL

https://xxxdev.service-now.com/service_catalog.do

Request Method

POST

Status Code

302 Found (from service worker)

Referrer Policy

strict-origin-when-cross-origin

1. sysparm_ck

546a786c1b9d8f90b11cca21604bcb93c76ce7c6bddc199f7a6eadadb343878054cbc44f

1. sysparm_action

order

1. sysparm_quantity

1

1. sysparm_id

ae923cc4dbd88b40649bd604ce96196e

1. sysparm_catalog

undefined

1. sysparm_catalog_view

undefined

1. sysparm_cart_name
2. sysparm_item_guid

26580d201b91cf90b11cca21604bcbf2

1. IO:fa927cc4dbd88b40649bd604ce961938

fb8d563c2b0c34002093d4b419da15bc

1. IO:e9b2cda5db1ee384fee56a5b8a96197f

Yes

1. sys_original.IO:e9b2cda5db1ee384fee56a5b8a96197f
2. IO:22101bec93cf82109ff9b7847aba10b4

test

1. sys_original.IO:22101bec93cf82109ff9b7847aba10b4
2. IO:36927cc4dbd88b40649bd604ce961909

83cef911e904300020939befc5e267c8

[snehareddym]

I tested this behaviour in my instance using both an OOB catalog item (Apple iPhone 13) and a custom catalog item.

For both catalog items, I submitted requests from:

1. Employee Center (ESC)
2. Service Operations Workspace (Interaction → Create Request)

In all scenarios, the variable values were successfully persisted and displayed on the resulting RITM. I also verified that the values entered through SOW and ESC were stored correctly in the variable editor.

Additionally, I tested a custom catalog item both with and without being available in Employee Center, and the variable values were still populated correctly when the request was submitted from an Interaction in SOW.

Based on my testing, I have been unable to reproduce the issue where variables are empty on the RITM after submission.