Support supplied me with the following input:
Generally it is NOT a good idea to create objects in the rules of another object. The reason is that conceptually objects do not have enough knowledge of the application to make a jusdgement of whether to create other objects or not. Practically, the rules are executed by rule engine in an ad hoc fashion and if you are not careful unnecessary objects can be created all over the place. However, there are scenarios when creating objects by rules could be useful.
It is DEFINITELY a very bad idea to use actions that interact with the user from the rules of an object. It is generally not a good idea to call a process from the rules of the object, either.
The logic of how the application behaves, especially as far as the UI is concerned should belong to a process and to a process only. In 90% of the cases a process is started from the UI and, therefore, it is aware of what is going on in the application, especially as far as the user interaction is concerned.
Therefore, there are two ways of implementing what you want:
1) Move all these functionality into the process that starts the whole thing from the user request (not the process called from rules - such process should be removed from the configuration):
IF MyObject.MyAttribute WAS CHANGED Then
ENTER NEW DuplicateObject
2) If you want to create duplicate object in rules, have some attribute in the Duplicate object that would allow the calling process above to uniquely find it and display a form for it, for example, store a timestamp in the parent object and in the duplicate object. The process will then find the duplicate object by the timestamp of the parent object and display its form
