Custom code in K2 blackpearl

As you may, or may not be aware, the underlying code of workflows produced by K2 blackpearl have Windows Workflow Foundation (WF) at the core.

With the previous K2.NET 2003, there was a Notepad-like editor that allowed you to over-write the code generated for the event.  It was compiled “on the fly” – you could just update some code (to fix an error for example) – and then “continue” the workflow.

With K2 blackpearl, there are so many event wizards, templates and other functionality “out of the box”, you will may not ever need to write any custom code.   I haven’t had to as yet – but one day, I’m sure I will, for some reason or another.  

This is not the same as when using the K2 API and ASP.NET (C#) to open K2 connection, and worklist, etc – and inter-operating with the K2 server/runtime.   This is with regard to code within the workflow.

Another K2 Insider Gabriel Malherbe has posted a great article about how to add code to events within K2 blackpearl – with some screen-shots, etc. 

It’s not for the faint-hearted – code within WF introduces a new swag of functionality, acronyms and techniques – XOML for one – and I’ve never been a fan of the design interface for WF (within Visual Studio).

But – if you HAVE to include some custom code within a K2 workflow – and can’t achieve the same result by calling a web service, or SmartObject method – then this article is a good start.

Thanks Gabe !

Source : Writing custom code in a K2 blackpearl client event


The ‘point’ of origin – K2 blackpoint

Well, it’s a great day when someone asks you “so, what’s happening with that BlackPoint” thingo from K2 ?” – and I can reply “It’s out !”


SharePoint workflow.  More features.  No code.

Click here to view the home page :

For those who haven’t heard about the K2 blackpoint, the easiest way to describe it is that it’s a cut-down version of the flagship K2 blackpearl product :

K2 blackpoint, a subset of K2 blackpearl features and tools, is for SharePoint users that want the ability to build workflows and process-driven applications quickly — without code, without complexity.

As was shown at a recent SharePoint user group meeting, there are a number of workflow solutions out there, with Nintex, Skelta, and the Microsoft offering of SharePoint Designer and WIndows Workflow Foundation (WF).

The K2 blackpearl product stood out as the better choice for an enterprise scale workflow & BPM tool, with Nintex looking rather appealing for SharePoint-based workflow.

That’s all changed now, with the introduction of K2 blackpoint – using the word ‘point’ as it’s a SharePoint-only workflow product.

Let’s have a look at the features that are included “out of the box” :

  • K2 studio – new Microsoft Office style workflow designer tool.  Had posted about this earlier, click here to read.
  • K2 process portals – SharePoint portals to manage processes, instead of the K2 workspace (as with K2 blackpearl)
  • Out of the box reporting
  • Works with Windows SharePoint Services (free) as well as Microsoft Office SharePoint Server (MOSS)
  • Works with SharePoint Forms Server – or without, by coding ASP.NET pages

So – K2 blackpoint does what it says – SharePoint workflow, no code.  

There’s some buzz on the interwebs regarding the differences and advantages/disadvantages when compared with Nintex Workflow

Here’s a few that are relevant (IMHO) – not the official cross-reference from K2 or anything like that :

Server – K2 blackpoint runs using a dedicated workflow server. Nintex is fully integrated into SharePoint, which means it’s processes are hosted by SharePoint, as with SharePoint Designer workflows.

Licensing – being a separate server, a single K2 blackpoint server can support multiple SharePoint servers, rather than requiring a separate license (costs)

Upgrade – if workflow requirements increase over time, there will be an easy upgrade path to the K2 blackpearl product, including the K2 Visual Studio designer and Visio, as well as K2 connect for SAP, and K2 SmartObjects designers.  If using Nintex, and workflow needs/requirements are greater, then it maybe end up (unfortunately) as a “start-over” task, with an enterprise scale product (K2 blackpoint or K2 blackpearl)

Functionality – K2 blackpoint has out-of-the-box reporting capabilities, and assign-to-Content-Type features.   For users familiar with the new Word-2007 environment, the K2 studio tool will be easy to create & configure workflows, as well as the K2 designer within SharePoint (like the designer for Nintex). 

Extensibility – can easily code webpages and web services using the K2 API, and SourceCode.Workflow.Client namespaces.   And, can use ADO.NET to interact with SmartObjects created by the K2 blackpoint, or within SharePoint.

Integration – being fully integrated to SharePoint means that Nintex resides within the content database.  This can be GOOD, with regard to disaster recovery.  K2 blackpoint has it’s own server, and SQL Server databases, which would require (additional) backup & disaster recovery plans, etc

Click here to view a PDF with the complete comparison document – between K2 blackpoint and K2 blackpearl.

One of the comments that is usually directed at K2 is that “it’s too expensive”.   Well, how’s this for an answer :


K2 blackpoint will be priced on a per-server model — $5,000 (U.S.) for up to 200 users, $10,000 (U.S.) for up to 500 users and $15,000 (U.S.) for unlimited users.

So – the K2 blackpoint product may be cheaper for a lot of implementations, has more functionality, and scalability, and is a true BPM solution – and is easily upgradeable (to K2 blackpearl) when/if you need to.

Seems like a no-brainer, to me.  But – hey, that’s just me !   

In case you’re wondering, here is a list of what’s NOT included in K2 blackpoint, and requires the K2 blackpearl version :

  • Visual Studio designer
  • K2 SmartObjects designer
  • K2 Workspace
  • Custom report designer (within workspace)
  • Process simulation (coming soon for K2 blackpearl)
  • Code editing, within the workflow designer (would require K2 for Visual Studio)
  • K2 connect for SAP, etc
  • Business Data Catalog, within SharePoint

Click here to view the home page for K2 blackpoint, including :

  • Details on training
  • Video clip showing main features
  • Sign-up for a free trial of K2 blackpoint BETA

And – there’s even a competition to celebrate the launch. 

The prizes are pretty good, just need to do some some searching for “clues”, and enter codes on the website :

  • 1st prize : DELL 30 inch Flat Panel monitor
  • 2nd prize : Canon PowerShot S5 digital camera
  • 3rd prize : Nintendo Wii

Click the following link to see details about the K2 blackpoint Game – get the point(s), win something cool.

Can’t wait to start playing around with K2 blackpoint – looks like it’s going to be great !

Wrap-up from MOSSIG

Wednesday night was the symposium on workflow at the Microsoft Office Server Special Interest Group, otherwise known as MOSSIG.

Was a bunch of about 40 folk in attendance – with Subway mini-sub’s replacing the usual nerd-dinner of pizza.  We all filed in to hear about Nintex workflow, K2, Skelta, SharePoint Designer and .NET workflow (Windows Workflow Foundation).

Tim Wragg was the “M.C.” for the night, inviting the vendors/experts to do a quick introduction and overview from each product.


Steve Heaney presented the Nintex product, which is a SharePoint integrated workflow tool.  Using a web browser, the user can create workflows using pre-defined activities, with an intuitive and easy-to-use interface.

The main target audience is for business users, although there is extensibility capabilities using Visual Studio and .NET code (WF).


Next up was Vinay Joseph from SDM, showing the Skelta product.  A quick demo-by-screenshot run-through showed the full BPM scale of the architecture.  Able to run on SQL Server or Oracle, and rich activity monitoring and KPI-driven initiations, as well as business rules engine and workflow server.

Some detailed reporting also, and able to use work calendars, and load-balanced servers with the Advanced Server Edition.

Also uses a web-browser based process designer, although I couldn’t really follow the flow of the one shown, was using a swimlanes view of a process, not standard workflow “flow view”.   I’m sure Skelta has a similar “flow” designer for processes, just didn’t see what it was like.


Jey Srikantha then showed us through the K2 product, covering the abilities to create workflows using either Microsoft Visio, Web browser, Visual Studio, or an office-style designer.  

Then quick run over SmartObjects, process portals, workspace, event bus, and the community aspects to K2 – with the K2 Underground and Black Market.  Looks like an enterprise scale capable product, with many, many pieces to the pie.

SharePoint Designer / Windows Workflow (WF)

Elaine Van Bergen then spoke about some tools that you may already have.  Certainly most installations of SharePoint would be via some form of licensing that would provide for SharePoint Designer.  A point and click designer, but from a Windows App this time.  

There are a reasonable amount of functions available, but certain logic such as looping ain’t gonna work.  Also, deployment to environments such as DEV, TEST, PROD is tricky too – and some security hiccups whereby the user that started the process is the permission set of the entire process lifetime.

However, it’s often a great choice for a quick & simple process, usually the first question is “can I do it in SharePoint Designer”.

If needing “full control”, you can have full reign to create workflows using Visual Studio, and the .NET Framework and Windows Workflow Foundation (WF).

This requires certain skills, as the code can be tricky – and it’s not so good if a business user wants to be able to maintain the process definition and business logic, or the activities and business process model need to change repeatedly (or rapidly). 

If only needing to code it once and never touch it, then WF and .NET is a good option.  And there’s lots of code out there, samples, snippets and so on.

But – if wanting to do any reporting, then you’d need to log data to a SQL Server database – using code, and then use Reporting Services to create some custom reports over the database.


So – that’s the FIVE of them (with Elaine covering two really).

Tim then invited all speakers to a sit up front, and begin the panel discussion proper.  

Was a good feature/function-driven discussion, beginning with the value proposition that each offering brings to the table.

There are some topics below without an entry for certain product/offerings, doesn’t mean “no comply, senor”

Just that the conversation jumped around a lot (which is great) – and my notes are a bit scattered in parts (which is bad).


Value Proposition / Summary Statement

  • Nintex – ease of setup/configuration/use
  • K2 – start small, grow to enterprise/ fully extending MS stack
  • Skelta – framework, embeddable, scalability, completely web based.  Ease of use, minimised code / no-code
  • SPD/WF – free – part of .NET framework. part of Microsoft license – already have in many organisations

Workflow Definition

If you throw back to a 101 thinking, what do you consider workflow to be, from the perspective of your product/offering ??  :

  • Nintex – human oriented WF, but can automate process to do something when item is modified; end to end with no human interaction – eg. Cascading delete
  • K2 – focus on business process, human or system involvement, work between participants & update backend systems, visually looking at current activity, implementing BPM & Reporting – to gain visibility on how to improve and ultimately save money
  • SPD/WF – workflow definition the same “concepts”, more need to think back to WHO will be designing – business user might do in Visio/flowchart, but tricky to understand SPD or WF visually, when compared to screen shots of other (K2, Skelta, Nintex) – they actually look like a workflow (!).   Thus, audience is mainly technical users, developers, etc.  

Target Audience

The next topic for feedback was related to making dynamic changes to a process, such as when requirements change.  One comment was related to “depends on WHO is making the change – sometime a user might change process to suit SPD, for example”.

So, some more thoughts regarding the “who” question with regard to workflow

  • Nintex – business users – their salesman uses internally, created a workflow to follow leads, and create SharePoint sites on commencement.
  • K2 – provides Visio designer for business users, or the web browser, and office-style tools, as well as developers within Visual Studio
  • SPD/WF – would be developers mainly for .NET WF, and even SPD not so well suited for business user

Versioning of processes

  • Nintex – integrated to XOML as with SharePoint Designer, will continue on old process / any new process will have the new version
  • K2 – has workflow server can have multiple versions of workflow, with the ability to download the source code for processes from previous versions
  • Skelta – has a listener to monitor workflows, handle change

Source Code

  • Nintex – can save process definition, and is saved within SharePoint
  • K2 – works with TFS from within Visual Studio.  Can open cross-designer files, between Visio, Visual Studio, web browser, office-style
  • Skelta – saves in database as XML file, independent of SharePoint
  • SPD – is within SharePoint, WF will be in Visual Studio + TFS


  • Nintex – has some out of the box, but really just as a learning tool to help create a quick process
  • K2 – can’t really “template” a business process, every organisation is different.  Instead, have common building blocks (wizards), and other re-useable pieces like SmartObjects


  • Nintex – can call other workflow pieces / web services
  • K2 – inter process communication, web services to backend systems, can use SmartObjects, K2 connect for SAP, SharePoint search


  • Nintex – can publish to another site, another server, but can’t assign to a particular ContentType
  • K2 – uses MSBUILD packages which can be copied to another server, also environment library & configuration pages for security.  Is able to assign to Content Types
  • SPD – limitation of deployment to multi-server – DEV, TEST, PRODSPD – can’t do across every list

Disaster Recovery

  • Nintex – in SP Content Database
  • K2 – different set of databases
  • Skelta – other database also / Skelta advanced server failover cluster
  • SPD/WF – SharePoint database also


Didn’t cover $ amounts, more of a discussion between licensed and “free” tools such as SPD/WF; false economy in that you have more developers or consultants, for a longer period of time & thus cost. 

Of course, there may be already some developers in the organisation who can be tasked with such development, and thus would be a valid choice in this instance.


  • Nintex – can code in WF, and use code samples from Microsoft community built custom activities.  SDK pack available, and Nintex-Connect website for community input/response.  Call BizTalk, wait for response
  • SPD – can also be customised, uses same “coded in Visual Studio” .NET WF activities as for Nintex
  • K2 – can create workflows in Visual Studio, and new ServiceObjects, EventBus, full K2 API, and portal site, with black market – components, wizards, templates, connect to SAP
  • Skelta – out of box activities, server events, human workflow, connectors to SAP, Oracle, etc.   API’s can be built / custom activities
  • WF – anything that can be done in Visual Studio.  Is a framework of code / classes / building blocks

Management of Workflows / Capacity Planning

  • Nintex – reporting is coming soon, with avg, max, min, etc
  • K2 – custom reports, report builder, simulations from historic data
  • Skelta – can do KPIs/thresholds to start or react to a workflow


  • Nintex – designed to very intuitive, more often business users need training in “identifying business problem”
  • K2 – training can be a few hours to do initial processes, 3 day training course available
  • Skelta – 7 day (!) training course for business users


By now, the session had moved into the question & discussion stages of the evening – with a few main topics as follows :


One question was asking “what if I use say, Nintex, and then outgrew, wouold I be stuck, could I upgrade ?”.  

Well, no – not the specific code from one product to the other, but it would signal a need to maybe change your processes.  If you outgrow the “tool”, you’ve most likely (also) outgrown the “process”.

Take the opportunity to review & analyse the process and design using some of the new features of the “upgraded-to” product.   (Or – you simply chose the wrong product to begin with !?!)

User Interface

With a process or workflow operating as the business layer for an application, what about the presentation layer, shown to users/participants – as opposed to the developers/creators of the workflow :

  • Nintex – InfoPath forms (Forms Server), view flow in site.  Can do “Lazy Approval” – reply via email with a Yes or No, for example
  • Skelta – MSN messenger, can send approve, SMS reply
  • K2 – InfoPath, WebForms, WebParts, Windows app’s also – multi-viewer technologies / presence based routing

Bear in mind that you need to be careful on mobile devices, don’t just show a mobile-ised version of a 60 field InfoPath form, for example !

Time To Market

This is another aspect, that I didn’t get time to ask about.   I’d expect that Nintex is a very short production ready timeframe (probably under 10 minutes too).

K2 & Skelta look similar, with more hours & days required depending on customizations and integrations.  And SPD would be a quick deploy & up-and-running.

The longest (by a decent amount) would be the WF custom coded option.  Aside from the complex code that has to be written, as with any code, development & deployment – there will be a longer time to dev, test, etc.


Some great topics, not just to hear how the products stacked up, and their abilities, but some key workflow “concepts”, and even back to simple application analysis & design, architecture & infrastructure – and coding/development and deployment.

Like with any development project, there are options and better/best/not-so-good ways to do something – depending on the situation at hand.

With regard to workflow, there are considerations like :

  • Which tool will meet the needs now, and future – as there’s no real upgrade path
  • The “who” focus is key – who needs to update a process, may determine the tool choice also.
  • The “when/how often” will/does the process change will also be a factor

These sorts of questions & answers will need some business analyst time to identify firstly the business environment – and then the tools at hand (as was covered during the panel session).

Thanks to all the presenter/panelee’s – and for Tim Wragg for deftly steering the discussion along.  

Now that you’ve read all the way to the bottom (!), there are some downloads from the evening available. 

There is the Workflow Panel Session PodCast of the entire sessions (40 MB – mp3 format), and you can grab the slide decks from Skelta, Nintex and K2.

Should you code your business logic or use a workflow model?

Found this interesting article from Paul Andrew from when he was the product manager for Windows Workflow Foundation and Windows Communication Foundation.

He has since moved into the SharePoint product team – his title is now “Microsoft Technical Product Manager for the SharePoint Developer Platform”.

Great to have a WF-oriented person within the SharePoint world.

Workflow development is a natural progression from writing code. But many developers are uncertain about when to use a workflow runtime instead of just writing code for business logic.

It’s a good question because it’s possible to develop all of your business logic in code.

However, using a workflow runtime offers some major benefits in certain scenarios.

This article applies directly to Windows Workflow Foundation (WF), but there are many aspects that are true for workflow implemented using “K2” – as much as for WF. 

The reasoning is still the same – with obvious differences in the technical implementation – the article essentially highlights that the workflow approach is a better way to go.

(P.S.  You don’t have to write ANY code if you use K2 – instead of WF !)

Here are some of the decision “criteria” from the article (code vs workflow) :

  • long-running business logic ?
  • business logic or business rules of process change frequently ?
  • needing visibility into business-logic for non-developers ?

Fairly brief article – worth a quick read – some good points.  

Source : Redmond Developer News (June 2007)

At the copa, copacabana

OK – maybe a bad choice of words, but the song is in your head now, right ?

Some of the K2 folk are discussing K2[blackpearl] at the cabana sessions next week – Tech.Ed Australia, on the Gold Coast.

As already mentioned – there are THREE sessions – here’s a bit more information / agenda :


Wednesday Aug 8th  1:20 PM

Blessings of K2 [blackpearl]: Empower business users to build & deploy workflow processes

Business users understand the processes in the organisation and now, with K2 [blackpearl], the tools are available for them to automate these processes.

In this cabana session we will show how the familiar MOSS and web-based interfaces allow a business user to quickly and easily design and execute a business process and how this effort can be extended by developers.

This one will be showing off the very cool new Sharepoint Workflow designer – with the ability to export as a CAB file, extend in Visual Studio and then re-deploy back to MOSS !    

If you’re familiar with Sharepoint and Sharepoint Designer is “ok”, but a bit limiting – and you don’t really enjoy Windows Workflow – this will be an eye-opener.


Thursday Aug 9th  3:05 PM

Bring Business Processes to Life: Model your business processes with K2 [blackpearl] & Microsoft Visio 2007

K2 [blackpearl] enables business and systems analysts to turn their business processes in to live running applications. By using familiar tools such as Microsoft Visio 2007, an analyst can take any Visio diagram and turn this into a K2 [blackpearl] process.

In this cabana session we will show how the business processes deployed from within Visio can be leveraged by developers using Microsoft Visual Studio 2005.

We will also show how existing K2 [blackpearl] processes can be imported into Microsoft Visio 2007 and manipulated within the familiar Visio environment.

How many folk do process design within Microsoft Visio ?   Everyone, right ?    Yep – me too.   I’m working on a project at the moment, converting a business-y/spec within a Visio diagram, into a K2.NET 2003 process.

Well – you can now do it all-in-one.   Just apply the Visio activities to a Black Pearl process – and “deploy”.   This is great for a business user (B.A.) to create the initial design – and then a developer can grab it into Visual Studio for extending and up-shifting the functionality.

And – can then re-open it in Visio – very cool !


Friday Aug 10th  11:05 AM

Into the Depths with K2 [blackpearl]: A deep dive into the rich development tools & capabilities

K2 [blackpearl] empowers developers to build complex workflow applications without having to write lines and lines of code.

With K2 [blackpearl] developers can create enterprise class business process applications from within Visual Studio 2005 and easily deploy them to its host and to MOSS and/or other systems.

K2 [blackpearl] builds on top of the .NET 3.0 framework extending WF and WPF capabilities to provide an easy-to-use development experience.

In this Cabana session we will show how developers can build SmartObjects that connect to data in disparate LOB systems including MOSS, Biztalk, SAP and Active Directory.

We will also demonstrate how developers can efficiently extend on processes interoperability and dynamic forms designed and deployed by a business user.

This sounds a lot more involved – show me the code !    Well, you don’t need to do much code within Black Pearl – the whole SmartObject stuff allows you to define an object model that spans multiple systems.   Great for integrating, architecting, etc.

Make sure you come and have a look – this one will be the best of the THREE – for the techies amongst us.

Going to be lots to learn – I’m sure I’ll pick up something I haven’t seen/heard before.   

Please leave me a comment if you’re coming along to Tech.Ed, and we can meet up to say hello !

OOB vs. SPD vs. WF vs.

Battle of the acronyms

In late-January, 2007, I presented a technical demo & discussion session at MOSSIG (Microsoft Office System Special Interest Group).  I’d posted an overview of the content @, but thought it would be worth including at


Tonight was my night to do a presentation @ MOSSIG – entitled Workflows in MOSS.   Just thought I’d cover some of the basics of the prezzo/demo – for those who couldn’t make it – and those those wanting a re-cap (there was a LOT of content !)

Firstly, a brief overview of Business Process Management – collaboration, office automation, integration with back-office systems – and then onto MOSS (Microsoft Office Sharepoint Server)

Within Sharepoint 2007, there are a number of ways to introduce Workflow, each with varying levels of detail.

I like to refer to these as the “small”, “medium” and “large” flavours of workflow implementations.

This is the same when considering (1) functionality, (2) complexity and (3) skill-level-required.

Small – Out Of The Box (OOB)

A number of workflows are installed with the MOSS server is setup. This allows a user to have a document in a library (for example) – with an approval workflow with emails sent to different people requesting comments.

The workflows are pre-installed & pre-configured – you just have to “run them”.

Fairly small level of functionality – can’t change how they operate – and small level of complexity (good for users, bad for developers).

BUT – a relatively small level of skill involved – so most non-techy users can jump into some quick workflows.

To MOSS or not to MOSS? Workflow may be the answer. (screen-shots)

Introduction to SharePoint Workflow

Medium – Sharepoint Designer (SPD)

The replacement for FrontPage is more than just a HTML editor, and web page creator. Open a “site” from within SPD, and you can add a workflow that you create from scratch.

This is point and click, with a list of Conditions and Actions. This is fairly detailed in it’s functionality – allowing a developer (or power-user) to have logic steps (if-then), and resultant happenings (update a list item, send an email, move/delete a list item, etc)

Medium level complexity, yet limited to the set list of options. And no ability to debug. And more skills required, but not rocket science.

SharePoint 2007 Workflow Jumpstart (some great links down the bottom)

Large – Windows Workflow Foundation (WF)

Using Visual Studio.NET and 3.0 of the framework, developers can codify almost anything with the custom-written workflow. This allows for many different integration points – such as the ability to call web services (I don’t know if SPD can do so – will check).

Basically watered-down BizTalk – very advanced functionality is possible – but it’s all code-driven – highly complex. And can be tricky to deploy to use within Sharepoint.

A fairly large amount of skill required to drive this one.

Windows Workflow Foundation (WF)

B# _NET Blog Getting started with Windows Workflow Foundation (WF)

MSDN Getting Started with Microsoft Windows Workflow Foundation: A Developer Walkthrough


Regardless of the workflow “creation”, one thing lacking is a proper workflow “server”.

Sharepoint is handling this all behind the scenes – but you can’t see how workflows are progressing in an easy to understand GUI sense – nor report on workflow average durations, or staff through-puts – and thus refine & “tune” your business processes.

And so – “there’s a gap” – with the need to develop “more custom” workflows than those provided in SPD – but – needs to be easier & more productive than WF within VS.NET.


This a .NET written IDE and server for integrating to/from Sharepoint. With the ability to have GUI based workflow layout & design, K2.NET offers developer ease, while not relinquishing features & flexibility.

A number of templates within the toolbox provide different wizard screens, allowing for easy configuration of decisions & actions – or – you can jump into the code, and modify the auto-generated code – or include your own.

You could (in fact) override the generated code – and write an entire “application” within K2.NET Studio – in VB.NET or C#.

Integration with other systems is thus “EASY” – you would do as within any other .NET code module – or call a web service.

Sharepoint-wise, you can update to/from a document library or list item – as well as have InfoPath forms residing within a document library – and displaying work item details for users to interact with the workflow.

The only downside to K2.NET is the price – it can cost $40,000 or more for a K2 implementation – before any workflows have even been created.

BUT – the time-saving alone – for costly developers – and the ability for business-analyst (tech-savvy) to be involved in design & development of workflows is great.

Another BUT – the integration with MOSS is limited to some extent – not much more that with SPS-2003. Such as the inability to interact with InfoPaths “Forms Server” forms – that’s coming in vNext (code named Black Pearl – just hit Beta).

Even so – well worth a look. Here are some links to find out more about K2.NET :

K2.NET – Enterprise Workflow for .NET

The Leading BPM offering for .NET

Example Customer Solutions – as webcasts

Technical Overview of K2.NET

PDF Overview (right-click & Save As…)

In this article, Grant examines how to work with 2003 enterprise human workflow application for the Microsoft .NET platform. – Overview of Enterprise Human Workflow Tools

Information For Business – Windows Vista Partners

Please feel free to email me with any further comments / questions following on from the MOSSIG wrap-up.