Hi Brian,

This is a common scenario and I can think of two ways to accomplish this, the first is my recommend approach, the second is an additional option.

Recommended:

1. 
   
2. We usually recommend that you store all business data (those that are not required by the Workflow to make decisions) externally. This is usually either using SmartObjects or custom SQL tables. The reason for this is two-fold:
   - When you need to access or change data and it is stored in the process, you will need to go through the API and need Admin permissions for this.
   - When you need to do reporting on Business data, you have full control over the structure, SPs, indexes, etc. If you store it in the Process, the datafields are denormalized in the DBs to make it generic enough across all processes. This can be tricky if you have complex queries.
   
3. Since the data is stored externally, you don't have to start the process if the user needs to save it - using a Save button. Just save the values (in SmO or SQL DB) and provide a page where users can access their incomplete submissions.
   
4. Once the user is done, he or she will click the Submit button. This will again save the updated values (or create a new record in the relevant database) and start the process. You will only pass in the ID of the record to the process datafield, so if you need to access the data later, you can easily retrieve it again in the process or on the approval page.

Alternative:

1. 
   
2. Regardless if the user selects Save or Submit, save the new record (SmO or SQL) and start a new process, saving the Record ID to the process. You will also need to set a field in the process, let's call it Submitted. It will be set to False for Save and True for the Submit button.
   
3. In your process, you will add an additional activity called Complete Request. This will have a client event, used by the submitter to further amend changes before submitting. You will also need a line from the Start Activity to the new act and a line from the new Act to the Approval Activity.
   
4. Add a line rule for each of the lines going to Approval and Complete Request. The one to Approval checks if Submitted == True, the other if Submitted != True.
   
5. The last part would be to add the actions for the Complete Request activity. 1 called Submit and one called Save. The Save will also use Update action type and the Submit will use Complete.

The advantage of the first approach is that you do not need to start a process. So if a user decided to not complete the request, you can just delete the record. If the process has started, you will need to do additional cleanup on the K2 side.

The good side (or bad, depending who you ask) of the second approach is that a user can access all items directly from the K2 Worklist. This can be achieved using the first approach, but will need a customized Worklist (not difficult but still needs time).

Hope this helps.

But this then mean that you still need to do a lookup with the Process ID to get the Worklist item to progress it?

No, the Worklist (custom or out-the-box) contains the serial number, thats all you need to progress the K2 Process.

I like the option 1 you describe, where the process it not started until the last page. thanks!