I recently updated a CDT, which is referenced in a process model subprocess. The

I just tried the following:
1. Start a process (A) with one version of CDT with VARCHAR 1000 set for a field
2. Update the CDT to VARCHAR 2000 for that field
3. Run a sub-process from process A to get the error
4. Start another process (B) with the updated CDT
5. Change the CDT back to VARCHAR 1000 for the field
6. Run a sub-process from Process B to get the error
7. Re-run sub-process from Process A to see what happens

No dice: even with the original VARCHAR setting, Process A fails. It doesn't matter if the CDT specification matches exactly.

My last hope, before facing a production nightmare, is to omit the CDT's from the application export, in hopes that on import to production, both the updated process models and existing processes will reference the unchanged CDT's in production.

We have no staging server, so I'll have to try to test this out on Dev first.

It seems to me that the by-reference CDT checking shouldn't have to be so strict. It should be smart enough to read that an updated CDT is equivalent to the one it is configured to support.

Hi Daniel, We've done a lot of versioning of CDTs over the last few years, and have as a result gone back through our workflows and removed most passing by reference because of the sorts of issues you are experiencing.
If you instead passs the parameter by value on input and map it on output, you don't get the problem (in this case, Appian is smart enough to auto-convert most CDT changes).
This is a shame, because you lose the benefits of by reference passing (performance / memory usage / simplicity). Given Appian can auto convert CDTs when passed by value, it would certainly be a good improvement if it also did it when passed by reference.
There are still a few cases we use passing by reference, but only when we know the subprocess we are calling will ALWAYS return quickly (ie: has no user tasks, msg task, scheduled tasks, etc). That way their will never be running instances of them when you upgrade.

I agree. I'm planning on taking a second look at refactoring my CDT-by-reference sub-processes as we speak. I'm not going to be able to address all of them, but there are some short-lived processes I can update.

But this particular business process was a challenge to implement. It goes several sub-processes deep. The end-users required reports on a few of the inner sub-processes, some of which involve tasks that can take several days for the users to complete. They have their own dashboards.

Fortunately the CDT's I'm passing don't require a lot of change. The reason I wanted to increase from VARCHAR 1000 to 2000 was because I needed to make that change in the database to support a necessarily long entry. I wanted to cover my bases and make the XSD match the change in the database lest the discrepancy come back to haunt me later.

Because the CDT change I wanted to make was a minor one and optional, my workaround is to push the updates without the CDT's to production.

Afterwards I'm considering pushing the whole build (including the CDT's) back from production to development just to make sure everything is in sync.

In cases I need to share data between longer running processes my shared PV is of type text and contains the serialized data of my CDT. Serialization is done with the function externalize. An event that triggers on change of the CDT serializes the data and in the other process an event that triggers on change of the shared text PV deserializes it (function internalize) again. This seems a bit arkward at first but allows to share ANY data between the processes.

That's a great tip. I'll need to think about how that would look in this particular process.