The Problem
When using K2’s SharePoint Event Integration you are provided with multiple trigger/hook points to which you can tie your process for initialization.  Commonly, in a non-content typed library, you simply select “Item Added” hook and move on in the wizard. 

However, because of the order in which the “Item Added” event and metadata save events are triggered by SharePoint, metadata will not be available immediately for use in your process.   If you expect to make decisions in your process based on metadata within moments of the item being created you will be sorely disappointed. 

First Attempts
The first workarounds leveraged to avoid this SharePoint timing issue involved implementing a start rule on a process or activity instructing it to wait for x seconds.  This opens up a nasty can of worms if the servers involved are under unexpectedly high load or if process execution speed is paramount to the business need.  Additionally you COULD violate best practices and check for the data in a SmartObject event and if the metadata isn’t ready, loop back and wait x seconds before trying again – but doesn’t that seem messy? and it couldn’t be good for performance..

New Perspective
So, what other events in SharePoint do we have access to that won’t keep this metadata limitation until Office 2010?  Well, I’m glad you asked.  In fact, SharePoint’s “Update Event” does respect timing in regards to the metadata. In every test I’ve performed when firing a process based on the update event, the metadata is ready and waiting for me when I need it from a SmartObject event.  But that isn’t the best part; The metadata you can map to process datafields and the folio in the SharePoint Events Process wizard in K2 works flawlessly when the process is triggered from SharePoint’s update event, so you’ll probably be able to make the decisions necessary just based on this initial data keeping your decision making lightweight.

Decisions Decisions
Besides the fact that the method I’m describing keeps you from violating best practices with start rules and loopbacks, there are other advantages to creating a control process to handle the processes you want to tie to a particular SharePoint list.  

• You may have an approval process associated with a Document Library for all but one content type.  In the case of the final content type, you need a more complex approval solution and therefore need a completely different process associated with it.  Having a control process triggered by the update event will allow you to make decision regarding which approval process to execute.
• As above, you may have a particular content type that requires no approvals at all, you can allow for the control process to simply do nothing in the case of this content type.
• You may want to take control of an approval process under certain scenarios.  For instance, if a capital expenditure is up for approval and someone updates the document or metadata, you can add logic to the control process, to send the Approval process back to the beginning and notify the SharePoint user that they just made the approval start over.

Example

Here I’m integrating with a document library that has two content types.  Both content types have a yes/no column named “Process Started” which will allow us to make our first decision in the control process: Is there already a process in motion to handle this document?  We don’t want an approval process to get kicked off every time someone or some system updates the data, so we create a control process that looks something like this and leverage the “ProcessStarted” yes/no data.

A series of wizard highlights I snapped while creating this example

• Within the Sharepoint Events Integration wizard, opt for the “Item Updated” Event:
• Still in the Event Integration wizard, map your decision making field, “ProcessStarted”, from the SharePoint event to a a process datafield for easiest access in your line rules:
   
• Configure the 1st line rule for the scenario when a process had already been set in motion, so the control process can just end silently and set the other line rule for the inverse “<>”:
  
• Add an IPC event as pictured above in the activity “IPC-StartDocumentApproval” and be sure to map any data you will need in the child process such as the document name, folder, site/list url, and any Content Type columns that you mapped in the Sharepoint Events Process wizard:
  
• Finally, add a SmartObject event to your control process to update the “ProcessStarted” status successfully.  Instead of a yes/no column, I’d also recommend using a text column that you can also purpose as a status field.  As the approval process reaches each milestone (ie. Started, Approved, Complete) you can use a SmartObject event to publish that status directly in the Document Library lessening load on your reports and bringing pertinent data closer to your users.
  
  
   

Now, each time a SharePoint Update event is triggered, K2 will evaluate the current conditions and decide whether to start an approval process for the document in question.  Additionally, the K2 control process can be expanded to make decision based on other available metadata and start one of several or multiple processes to handle the business rules associated with a particular content type, document type and/or matching data relationship.