Extend Solutions Workflow vs Custom Workflow

dcjung

Wanted to get some feedback regarding the relative pros and cons of extending the OOTB Solutions workflow vs. creating custom workflow from scratch.

At a previous client we used a workflow model in which users first created a workflow and then created/updated their content. So we coded custom wft templates in which we generated the XML job spec based on user input. In addition, since our end users were "high maintenance", we built other features such as attaching a DCR to a task so that the users wouldn't need to manually navigate to the dcr and attach. In this scenario, our users complaints about Teamsite UI drove the workflow design. Personally, I found the benefits of custom coding templates were that it allowed us greater control and flexibility.

At my current client, we're using a workflow model in which users locate their Interwoven generated pages, edit their related DCRs, and then submit them to extended versions of the OOTB solutions workflow. In this model, users aren't really required to interact with the workflow forms all that much, so they're probably better served with this paradigm.

I was wondering if there were any thoughts on the long term (compatibility with upgrades, best practices, etc) pros and cons of custom coding workflow templates vs extending the OOTB solutions workflows.

TIA

Adam Stoller

I believe that the use of workflows to drive the content *creation* phase is important - for reasons you indicated.
Modifying existing content and then submitting it through a workflow is also a natural process.

What I believe should be avoided is trying to train users to create new content outside the framework of a workflow process -- far too many things can go wrong and end up confusing all parties involved.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com