Hi guys,
I’m using the new Document Understanding with the new Studio Activity “Extract Document Data” (UiPath.IntelligentOCR.StudioWeb.Activities):
Please take a look at the type that was generated from this activity.
In our company we push the changes to git and then Jenkins will build a package via the Jenkins UiPath Plugin.
The problem is that Jenkins throws an error about this type:
How can I solve this?
Hello! We ran into this same issue on Studio 24.10.6 with Document Understanding 2.17.4 and wanted to share what we found in case it helps others.
The error we saw was “Cannot create unknown type … UiPath.IntelligentOCR.StudioWeb.Activities…CustomGptDocumentType…Bundle”.
In our case, this was tied to the “Generate Data Type” option in the Extract Document Data activity.
When this is set to True, UiPath generates a strongly typed output (IDocumentData) based on the selected extractor. That type appears to be generated dynamically, which you can see in the namespace such as CustomGptDocumentType_.Bundle, and it gets serialized into the XAML.
What we observed is that this works fine on the original development machine, but when another developer pulls the project or opens it in a different environment, Studio may not be able to resolve that generated type and throws the “Cannot create unknown type” error during load.
What worked for us was setting “Generate Data Type” to False in the Extract Document Data activity, deleting and recreating the output variable, then saving and committing the project again. This switches the output to IDocumentData, and after making this change, the project opened cleanly across machines.
The strongly typed output is helpful for IntelliSense, but in our testing it behaves like a dynamically generated type that may not always be available across environments, which can introduce challenges in team-based development and source control scenarios.
We also noticed that UiPath has identified related type resolution issues with this feature, such as “ambiguous type” errors noted in recent Document Understanding release notes and tied to Studio fixes, which suggests this is an actively evolving area. https://docs.uipath.com/activities/other/latest/document-understanding/release-notes-document-understanding-activities
For now, we are standardizing on setting Generate Data Type to False for shared projects.
I really dislike the suggestion to turn off the strongly typed data type in lieu of the generic type.
This suggests a wider issue to me where coded source files would also cause errors in the pipeline because that would be generated in the same way as this object.
Both of these can be shared between users when the project is shared and read from source control etc, so if it causes unknown types there are other issues.
To isolate the issue, if you try to do the same with a coded source file, making a custom type and referencing it in the workflow, and that doesnt give the unknown error, then the issue is related to access to the document understanding center in my opinion.
The activity reads the taxonomy of the document and builds a class and compiles that into a .dll so you can use it in the project, but the .dlls don’t get stored in source control.
Your pipeline needs to build them again, and if it cannot read the document understanding center to do so then it cannot make the type.
