- When making changes to or creating a new workflow template you also create other new objects e.g. standard tasks, workflow container elements based on new data references, new business object subtypes and so on.
- You do not transport these new object to your system, you only transport the workflow template.
- When you transport a workflow template it does not automatically transport other objects like standard tasks or data references. These new object must be transported seperately.
If you have already transported the workflow and it will not activate in the target system then carry out the following:
- In the target system, open the workflow template in the Workflow Builder (Transaction SWDD or PFTC) and do a syntax check. In the bottom of the screen it will list any errors. If for example a standard task is missing from the system it will have an error like “TSXXXXXXXX is not a valid object”.
- Transport the identified missing object to the target system, refresh the runtime buffers with transaction SWU_OBUF (in target system) and check the workflow template again. It should be possible to activate it in the target system.
When you make changes to existing workflows or create new workflow templates make sure you transport all new objects before you transport your workflow template. For example you could transport your objects in the following order.
- Newly created business object subtype (or changes to existing business object subtypes)
- Newly created standard tasks (or changes to exising tasks)
- Newly created data dicitionary objects which are referenced by workflow container elements (or existing data dictionary object that have been changed)
- Workflow template
Additional information regarding Workflow Template Versions
This is how versions work in relation to transporting workflow templates:
- Create or make a change to a workflow in your development system and transport it to Test.
- If the workflow already exists in Test and it has running instances then a new version of the workflow is created automatically in Test. This is done so that the existing instances can use the old version and new instances created after the transport can use the new version. If the workflow already exists but had no existing instances (in Test) then it would simply be overwritten with the new transport.
You do NOT need to have versions synchronized between your Development, Quality & Production systems.
This information can also be seen in the Knowledge Based Article 1603745.