Why would you not want to start it? Starting it and immediately suspending it is an option. Otherwise just delay the creation...
My system allows an outside client to trigger the start of a process instance, using the latest version of the process definition. I have three requirements:
1. Emit a notification whenever I start a new process instance ("start"); that notification must include the effective version (ie. the process definition version used to create the process instance).
2. Emit a notification whenever I reach a certain custom activity (this gets handled by code in the custom activity itself)
3. The start notification must occur before the custom activity notification.
It appears that the easy way would be to simply use executionService.startProcessInstanceByKey, use the returned ProcessInstance reference to determine the effective version, and then emit the start notification.
However, if I do that, the start notification will only get emitted after I've reached a wait state, which is guaranteed to be after the custom activity executes. This breaks requirement #3 above.
If, on the other hand, I can create a process instance without starting it, I can:
1. create the process instance, and from that reference, determine the effective version
2. emit the start notification, including the version determined above
3. start the process instance; when I reach the custom activity, emit the custom activity notification.
So, does that make sense? I had trouble clearly explaining this.
Your explanation is clear, and it explains what I expected. You were asking a 'technical' question in the direction of what you thought was the solution instead of asking a design question in the functional area.
I think you could/should use eventlisteners on the process start event. You can call a java class there that sends the notification before the process is at the custom activity. If that does not work, you can make the start node async (do not forget to give the start state a name!). The process instance returns immediately then and the rest is executed via the jobExecutor.