Change Class and Workflow with one only state as trigger

Support Portal has an example of a script that changes the workflow (you would need to modify it to also change the class): How to automatically change object workflow to another

But as bright-ideas.dk said above, writing new VBScripts is not recommended anymore and this should be implemented via a vault application for future compatibility.

After looking into this further it turned out Property Calculator can be used to change the workflow so this would be my recommendation to avoid scripting. We'll look into updating the support article with this approach.

Below you can find a sample rule that moves the object from workflow "Reviewing drawings" to workflow "Reviewing drawings 2". Note that the Calculation Event Handler needs to be set to BeforeCheckInChanges.

I figured this out, but there’s another problem. The customer claims that they are not able to trigger a transition, even though the permission is set to "all". What could be the problem here?

You may need to add an extra step where you move with an automatic transition that then causes the workflow change. So the user would move the object to state "Change workflow", then the automatic transition moves it to "Change state" and then Property Calculator kicks in.

One thing is missing: after switching, the metadata from the old class is carried over. You can delete it manually on the metadata card, but is it possible to do this automatically?

Whilst the class defines a metadata structure (what properties to show, their order, which are mandatory, etc.), the general concept is that you can add additional properties to an object if you wanted to augment that list with other pertinent data.

So, for example, I could add a "Project" property to any object to record it against the project, even if the class itself doesn't define that property.  Beyond that we even use some of these properties to record things like relationships between objects.

When you change the class the system probably now sees these properties on the object as "additional"; items that are no longer part of that class-defined structure, but ones that are now effectively added on top of it.

I assume that you probably could remove those properties via the VAF (maybe even via PC or similar) if you can define what they are.  Via the VAF you could even write code that would remove all properties that are not defined on the class if you wanted.  But I suspect that most configurable options won't do this automatically as it could cause some odd behaviours in situations where these properties have been added on purpose.

Whilst the class defines a metadata structure (what properties to show, their order, which are mandatory, etc.), the general concept is that you can add additional properties to an object if you wanted to augment that list with other pertinent data.

So, for example, I could add a "Project" property to any object to record it against the project, even if the class itself doesn't define that property.  Beyond that we even use some of these properties to record things like relationships between objects.

When you change the class the system probably now sees these properties on the object as "additional"; items that are no longer part of that class-defined structure, but ones that are now effectively added on top of it.

I assume that you probably could remove those properties via the VAF (maybe even via PC or similar) if you can define what they are.  Via the VAF you could even write code that would remove all properties that are not defined on the class if you wanted.  But I suspect that most configurable options won't do this automatically as it could cause some odd behaviours in situations where these properties have been added on purpose.