Web Service method missing Body and Parameters after importing workflow.
I have been doing some Workflow work with many different methods to create child tickets. They were working fine before exporting the workflow in preparation for the April Sandbox Refresh. After the Refresh I imported the workflow fromt he JSON file and my Headers, Methods, Parameters and Body tab entries are blank.
I have attached my exported file.
Asked by Nathaniel Obee
on Thu 4/7/22 5:07 PM
Last edited Fri 4/8/22 6:32 PM
Sign In to leave feedback or contribute an answer
Answer (1)
This answer has been marked as the accepted answer
Mark Sayers
Fri 4/8/22 9:23 AM
Hello Nathaniel,
I'm assuming you exported this from Sandbox, then re-imported it into Sandbox after the refresh, is that correct?
Sincerely,
Mark Sayers
Sr Support Consultant, CS
1 of 1 users found this helpful.
For web service methods, here are the properties that are migrated: ID, Name, Description, Verb, Url, IsActive, ProviderID, AccountID, Created/Modified UID, Created/Modified Date.
We don't migrate encrypted settings, which includes: Headers, Parameters, Body, and Authentication sections of web service methods.
Config Migration skips encrypted/sensitive data, because it's very likely this data is different between environments anyway since the main use case of this feature is to go from Sandbox to Prod. - Mark Sayers Fri 4/8/22 1:39 PM
We don't migrate encrypted settings, which includes: Headers, Parameters, Body, and Authentication sections of web service methods.
Config Migration skips encrypted/sensitive data, because it's very likely this data is different between environments anyway since the main use case of this feature is to go from Sandbox to Prod. - Mark Sayers Fri 4/8/22 1:39 PM
Mark,
I find this to be very disappointing. The way i read this, the tool was designed to copy only half of the Web service method. From my perspective it's leaving out the most important parts.
Did you not have a use case for interaction with the TDX API? All the Ids are the same in Prod and Sandbox. Which is awesome because I don't have to re define each value when moving from SB to Prod. Except the Tool doesn't do that.
This functionality makes the export/import feature half useful to me.
Nate - Nathaniel Obee Fri 4/8/22 1:49 PM
I find this to be very disappointing. The way i read this, the tool was designed to copy only half of the Web service method. From my perspective it's leaving out the most important parts.
Did you not have a use case for interaction with the TDX API? All the Ids are the same in Prod and Sandbox. Which is awesome because I don't have to re define each value when moving from SB to Prod. Except the Tool doesn't do that.
This functionality makes the export/import feature half useful to me.
Nate - Nathaniel Obee Fri 4/8/22 1:49 PM
The original design of the feature was to allow users to prototype things in SB and move them to Prod. IDs between the environments won't be the same if you're doing that because you'll get different IDs when those items are created for you in Prod. So that is why the items weren't copied exactly for the export (which is already a complicated process on the back end of things to encrypt the files to protect the exported SB data, and then upload and re-encrypt it when imported into the new Prod environment).
It does the hard work of creating the workflow and the methods for you, and then you'd just need to populate the tabs of any methods with the accurate Prod values, possibly while keeping the method open in Sandbox to be sure everything is formatted the way it needs to be. - Mark Sayers Fri 4/8/22 2:13 PM
It does the hard work of creating the workflow and the methods for you, and then you'd just need to populate the tabs of any methods with the accurate Prod values, possibly while keeping the method open in Sandbox to be sure everything is formatted the way it needs to be. - Mark Sayers Fri 4/8/22 2:13 PM
I'm happy to relay your feedback to our Product team though, but we wouldn't want to drop an exact copy of a method into Prod from Sandbox because if the attributes/parameters/auth account aren't valid in Prod (which they wouldn't be if you were only just building this out in Sandbox and never had done any prep work for it in Prod) it would just break the workflow and need lots of corrections anyways. Specific references in a call's body to attribute IDs for instance would be invalid in Prod because the IDs would have needed to be newly created with IDs that almost certainly would differ from Sandbox, and even if they didn't differ the system would know that they weren't an exact match.
- Mark Sayers
Fri 4/8/22 2:16 PM
Yes, please do forward this along. I would appreciate some more development in this area, clearly I have some expectations.
For this one workflow I'm not creating any new attributes so the Ids for Service, requestor, impact, urgency, and many others do not change between environments. However I understand even if I were to import a form with new attributes it won't match SB IDs.
The workflow is broken by not importing the encrypted element anyway. I would prefer a more complete copy if it's not going to work without adjustment post-import.
Also better messaging about the process on the import/export screens would be nice. I don't recall seeing anything about what won't be exported.
Thank you for the explanation. Your prompt response is consistent and always appreciated. Feel free to reach out to me on this if I can help.
Nate - Nathaniel Obee Fri 4/8/22 2:44 PM
For this one workflow I'm not creating any new attributes so the Ids for Service, requestor, impact, urgency, and many others do not change between environments. However I understand even if I were to import a form with new attributes it won't match SB IDs.
The workflow is broken by not importing the encrypted element anyway. I would prefer a more complete copy if it's not going to work without adjustment post-import.
Also better messaging about the process on the import/export screens would be nice. I don't recall seeing anything about what won't be exported.
Thank you for the explanation. Your prompt response is consistent and always appreciated. Feel free to reach out to me on this if I can help.
Nate - Nathaniel Obee Fri 4/8/22 2:44 PM
Ouch! That wasn't apparent to me, either.
I agree with Nate's last comment...the workflow is broken without all of the data. However, if the data is included and it matches in prod, it will work correctly and the real value of the import/export feature will be realized. Maybe the product team could add a checkbox to let us choose weather we want to include the encrypted data when building the export so we could accept the risk of it working/not working correctly when we import it.
Personally, I would rather be prompted with a message that workflow web methods will not be included in the export and must be manually copied/pasted to Prod.
Thanks for passing this information on, Mark. - Bobby Jones Fri 4/8/22 4:24 PM
I agree with Nate's last comment...the workflow is broken without all of the data. However, if the data is included and it matches in prod, it will work correctly and the real value of the import/export feature will be realized. Maybe the product team could add a checkbox to let us choose weather we want to include the encrypted data when building the export so we could accept the risk of it working/not working correctly when we import it.
Personally, I would rather be prompted with a message that workflow web methods will not be included in the export and must be manually copied/pasted to Prod.
Thanks for passing this information on, Mark. - Bobby Jones Fri 4/8/22 4:24 PM
Adding a public +1 that the workflow ends up broken either way and I'd much rather the encrypted data come over and perhaps have to be adjusted, rather than just being missing entirely. But if that's for some reason not possible, the documentation should be much more clear as to what's not coming over.
Thanks,
Anthony - Anthony Marino Tue 6/28/22 12:53 PM
Thanks,
Anthony - Anthony Marino Tue 6/28/22 12:53 PM