Like most of you we create all our processes and dependencies in one environment

afaik it will have an impact if you use manual type casting.

CDTs can be identified by QName, their QName includes the namespace and the name but this is not related at all with the environment's URL this is just the unique identifier of the data type. The namespace could be anything, by default it's the URL of the site (based on SERVER_AND_PORT) when using the Data Type Builder.

... that said, it doesn't matter if your CDT references a completely different URL in the namespace. This is the same for CDTs for external web services, the namespace has nothing to do with your environment's URL and they still work properly.

@Eduardo: as I reported in an earlier thread, using the type! constructor in an expression rule caused an import error when importing to a different environment. The official reply I got was that it had to do with my CDT namespace. I can link the thread if you want clarification.

Actually if you make sure the CDT is included in the application package any rule using the type! constructor will:

1. Report an error in package inspection (Applications - Import - Inspect) because the CDT is not in the environment yet and the inspection doesn't assume it will be created when it comes to analyzing the type! constructor dependencies:

"Reference to datatype [null] (Content > Free-form Rule) cannot be found."

2. But the import will succeed since the CDT will be created in the target environment as part of the import (Applications - Import - Import)

3. Once the CDT is in the target environment (regardless its namespace) the inspection will work too.

Here's an example forum.appian.com/.../108562 of an application that contains a rule defined as:

=type!AppianSupportEngineer(firstName:"Eduardo", lastName:"Fuentes")

which gets saved as

='type!{xxxxx.appiancorp.com:8080/.../}AppianSupportEngineer'(firstName:"Eduardo", lastName:"Fuentes")

if this app is "Inspected" in another environment you will get the error I describe in #1 but if you click "Import" instead of "Inspect" the import will succeed since the CDT is included in the package. I may be misunderstanding the problem you faced Mike but hopefully not. Ideally the namespace shouldn't be a problem as long as the CDT exists in the target environment or is included in the app to be imported.