using data fields for everthing?

Sooner or later you will have to archive your database.  100,000 instances per year X 20-30 workflows X 80 Fields X N Bytes per field could get pretty big.  If you log and audit every field, the space will grow at several times that rate.

I don't really understand when you say you don't want to take the time to create SmartObjects, yet you want to use data fields because they are quick and easy.  If you create SmartObjects that use the SmartBox, it should take no more time to create those data fields than it does to create process level data fields. 

Process data fields are really meant to contain the state of a specific process instance.  They should be fields that you use specifically in the workflow.  While you can store every variable and field ever needed by your application, I'm not sure that would be the most efficient approach.

I would be happy to reply to this post with several other approaches with you if you are interested.

I have an approach that might be beneficial with little or no coding.  It's up to you to see if it will fit with your team's style.

Consider storing the data for your forms in SmartObjects.  Create & deploy the SmartObject using the built-in SmartBox (the default) data store.  In Visual Studio drag the SqlDataSource control on to your web page and configure it to connect to the K2 SmartObject Source instead of SQL.  You can use the standard data source wizard to connect to your SmartObject.  Make sure to take the option to store the connection string in the web.config file.  Now that you have a data source on your form, you can use standard .NET databinding to move data to and from the controls.  You can even bind to complex controls like the form view control that will automatically generate fields for all of the SmartObject properties.  The next thing you need to do is save the data to the SmartObject and start the workflow.  When you save the data to the SmartObject, be sure to hang on to the primary identifier of this particular request and pass it as a process level data field to the workflow.  Alternatively, you can start the workflow first and use the Process ID as the primary key for the SmartObject. 

Once you have saved the data to the SmartObject you can reference it in your workflow without any code.  With the process designer open, go to the K2 Context Browser and click the data (third one down) tab.  Notice under Data Fields and XML Fields at the bottom is one called References.  Right-click and Add; a wizard will walk you through relating a SmartObject method (usually load) using a primary key.  In this case you will either use the ID you stored in the SmartObject or the Process ID.  Once you complete this wizard, your SmartObject and all of its data fields will be in the references section.  You can use any field in the SmartObject anywhere in the workflow by simply dragging it from the context browser.  The runtime will take care of getting the field value from the SmartObject where the keys are equal. 

Using this approach, your workflow will contain only the data it truly cares about, like the primary key that links the workflow and the SmartObject.  All of your data will be stored in the SmartObject where as a side benefit you can easily use it for reporting.  Whenever you need to display this data again on a web page, you simply specify the key of your SmartObject as a querystring parameter in the client event, then the SqlDataSource control can use this value to retreive all of the fields and display them.

 I've used this approach many times and it can greatly reduce the amount of code you write while at the same time minimizing the amount of data stored in process level data fields. I think there might be a tutorial in the K2 help that goes through this step-by-step.

david