Integration Service Pack Namespace errors

Hi Team, what are these errors about the namespace and what is a fix for this.

I am using latest Integration Service package and using salesforce API call. All the output were created using ctrl+k so it automatically created its data type.

Now as I switch tenant suddenly all of this are throwing errors. Even if i delete all these unknown variables and also delete such namespace still its not letting me save the project which seems super weird.

All the packages are latest version and I cant seem to get to fix this even if I delete stuff.

Please advise. I also did project cache clean up.

@tejaskumar.darji

As you changed your tenant, did you created integration with in this tenant?
If not please do that connection in the latest tenant and add that connection in current tenant and also check in studio under the Namespaces check whether it is imported or not if not add those namespaces.

Happy Automation

Yes a working connection already exist in the PROD tenant. How can i manually add those previous tenant namespaces?

@tejaskumar.darji

You can add those manually only for that open the process from studio there you can see namespaces as above mentioned screenshot.

Yeah, I added them all, but it did not make any difference

@yedukondaluaregala I already added all the namespaces, but the issue still persists. It seems more related to the tenant connection or Integration Service dependency after switching tenants.

Yes, can you try by deleting the existing connection and try to re add from studio. Just give a try

None of these suggestions will work. The issue is because the connection thinks this is a different instance of Salesforce.

You have to keep the connection the same at design time, you can switch it once its published to test.

If you really need to test it without causing the regeneration it might work if you change all the connections without Studio being open by editing the xamls and changing the connection ID, if you dont change them all though it will for sure be a mess.

The custom types are defined in the .project folder, so you need to revert to a version where they arent ‘Unknown’ and can see them there.

Check connection IDs, package versions, and generated namespaces.

@tejaskumar.darji Please try this approach:

Switch to the tenant where you want to run the project.
Make sure the same Salesforce connection and Integration Service connector are configured in that tenant.
Remove the affected Salesforce / Integration Service activities from the workflow.
Remove the related output variables, arguments, and imports that show UnknownType or the old UiPath.IntegrationService.Activities.SWEntities… namespace.
Save and close Studio.
Clear project cache again, then reopen the project.
Add the Salesforce activity again from the target tenant and recreate the output variable using Ctrl + K.

Please let me know if it works or not

This is not a solution to the problem, basically you are saying just remove all affected stuff and recreate. That will obviously work! The question is about how to prevent this and avoid manual re-creation efforts.

This is simply like delete existing code and recreate. Just imagine if I have 50 SF actions and 100 variables would it really make sense doing above steps!

Yeah, I agree with this. I don’t seem to have a fix for it, but it’s definitely something UiPath can address, considering the rising use of integration services and connectors; this is going to be a real problem for a lot of folks.

There are many cases where the lower environment does not have enough test data, so developers have to use another tenant to test things.

bug feedback improvement

Is it working for you?

I didn’t face this kind of challenge till now. Just trying to help you to sort out the problem.

Yeah, it doesnt just affect integration service stuff, it affects robots too. I know how this all works under the hood now after trying to have two agents in a long running workflow and it nuking my project by continually only building the objects for one or the other cause something got confused, it needs to be easier and all the hash stuff I think causes alot of problems. Not having it might be worse, but we need something to make this easier.

Like I said, if you revert to the old code, before migrating, my approach of manually changing the connection ID in the xamls I think should bypass this issue and let you test in prod. Or publish and test it as a published package where you can change the connection

@tejaskumar.darji

The issue seems related to how UiPath handles Integration Service connection references and namespaces when switching between different tenants/environments. This can also affect robots and long-running workflows, especially after migrations or when multiple agents are involved.

A possible workaround is to revert to the pre-migration code and manually update the connection IDs inside the XAML files. Another safer approach is to publish the workflow/package first and then change the connection configuration during testing. It would be helpful if UiPath improves environment and connector handling to avoid these namespace and hash-related conflicts in future releases.