Your use case is the basic use case that offline was built around. The idea that you would have an agent out in the field collecting data, then an agent in the office processing the actual case afterwards. Offline processing will automatically stop when it reaches something it cannot process offline, such as a routing or utility shape.
For example, in the configuration below, offline processing will stop when it reaches the second stage.
Our expected use case is that field agents and agents in the office would be working from different work baskets. However, if you have the same agents doing both jobs, that is possible too...
To keep assignments from the "online" stages from showing on a user's offline worklist, you can either use different work baskets, or filter them out of the user's worklist when rendering the worklist for offline. See pzIsOfflineEnabled when rule and D_pyUserWorklist data pages. You can modify this data page to have its own custom offline worklist easily enough. Just keep the columns the same.
If you run into any issues, feel free to keep posting them here in the Pega Support Community and we will help you out.
Sorry I did nt get, my actual scenario is like this, user will be able to start the case in offline or online and first stage can be submitted either in online or offline then after submit ion of stage1 it will always be online case. we don want to make ass offline kind of app, from stage-2 onwards it should look like online cases fast response and DT,service call should wotk withour OSCO coding.
This is exactly the basic use case that OSCO was built around. I am not sure what things you have tried, but it sounds like you may be going about it the hard way.
Most folks would handle this as two case types. One offline enabled, one not. The second case type would get created at the end of the first case type. Usually, the second case type goes to a different work basket because typically the the two cases are handled by different people. You can put a utility on the end of the offline flow to create a parent case type or a child case type and to move one case under the other.
If both parts absolutely need to be handled by the same operator ID with the same case ID, then just create a flag property to set at the end of the offline flow via a utility shape. Then have the user worklist for offline filter out those cases in the DT using what I described in your first post.
So far, your use case sounds like a standard use of OSCO. It does not make sense that you would need to create temporary work objects or be modifying pyStartCase.