Is this the kind of thing that could be solved with the out-of-the-box
approval workflow? Given that you have different approvers, I'm not sure
there's a good way to do this automatically (unless you have a list
somewhere that matches them up, in which case automated deployment may be an
option).

For 50 libraries  you will definitely want to do this with a VS2005 or VS2008
workflow. You will build one workflow  with an association form that accepts the
emails of the approvers  involved. This form comes up when the workflow is
associated with the doc library. This is how the OOB Approval workflow is
designed. Deploy the workflow as a Solution/feature (check the Install.bat
included in the workflow template for how to deploy) . Once deployed you will
need to activate it in each doc library to supply the approver credentials.
This could also be done programmatically, but is probably more work than its
worth once the workflow template is deployed to the sites.

For examples, download the MOSS SDK and check the Samples/Workflows directory
that gets installed along with the SDK. It's got about 13 sample workflows in
it.

I'd like to understand this better. Given that the OOB workflows should
provide the required functionality, what is the benefit of creating the
workflow in VS and deploying it as a feature? Is it just that you have
fewer manual steps (activate per library as opposed to assign per library)?

If you were to do this with OOB workflows you would either need to create  the
workflow as desired in each library or create the workflow  attached to a content
type and then add that content type to each library. Now if the workflow needs
to be attached to multiple  content types, you're back to creating the workflow
multiple times as you need it configured. If you create the workflow in VS and
package it as a feature  you'll only need to activate it where needed, not
reconfigure it over and over.

The OOB workflows were written in VS and deployed as a feature. I guess I took
the question to mean that the OOB approval workflow  wasn't suitable for what
they wanted to do and that a custom workflow was needed. When they said manual
I thought they were talking about creating one workflow in SPD for each library.
What I meant was if building a custom workflow to be re-used in 50 libraries  you
don't want to do that in SPD. If the OOB workflow is sufficient then simply
activate a custom instance in each of the libraries and enter the different
approvers when activating each instance. Or better yet, if the approvers  are
based on document  types then attach the workflows to Content Types and implement
the content types in the libraries. One workflow per content type, instead of
one workflow per library.

"I guess I took the question to mean that the OOB approval  workflow
wasn't suitable for what they wanted to do and that a custom workflow
was needed. "

Maybe I am wrong, but when I manually  go to create  a workflow  for a
document library it asks for an approver email address. I do not know
what who that approver is until I look at the .xxx of the person
submitting the document. Then I have to go to a list (or something
like a list?) to get the specific approver and insert the correct
email address for the approver.

Is there a way to do that in an OTB workflow??


"When they said manual I thought they were talking about creating one
workflow in SPD for each library."

Correct. I am assumimng that unless I am able to somehow associate
the workflow with the ~50 existing doc libraries  when I deploy the
workflow in a feature, wouldn't I have to go back to each one an
associate it manually?

Then I was reading your question correctly. Using SPD you would need to build
the workflow  50 times. Using VS you build it once and instantiate it in each
library or a content type(s) used in the libraries.

"You will build one workflow  with an association form that
accepts the emails of the approvers  involved. This form comes up when
the workflow is associated with the doc library. "

I want the workflow to be kicked off automatically when the document
is uploaded for approval.

The approval  pairs, consisting of who is uploading the document
(Department ID) and the approver for that department content (along
with his/her email address), I plan to store in a custom list that is
maintainable by the sysadmin.

So I will read the list and get the approver email address when the
workflow starts.

Does this sound like a good plan? If so, dwould you happen to know of
the Workflow example I should reference?

I don't know of a specific example that reads data out of a list to set the
approvers. It should be doable however. The one thing I would do differently
would be to plan to attach the workflow  to a content type rather than a document
library. One content type could cover all 50 libraries  if they all use the same
document type.

All document  types (assuming you mean .Doc, .PPT, EXCEL) will be used.

Additionally I need to apply  this workflow  to Image libraries  and
Videos down the road.

You say "It should be doable however" Can you provide  me with any
resources on how it would be doable ... at least something that gives
me an inkling on how ?

I don't know of a specific example, but since you have access to code in
the workflow  it should be just a matter of instantiating the SPList object and
using a Foreach loop to look at each SPListItem until you find the pairing you
need.

Don't confuse Content Type (document type) and document  template. In a regular
document library you can load .doc, .docx, .ppt, etc but they are all loaded as
a content type called document. You could create  a new content type that
inherits from document called "Approved File" or something like that and attach
the workflow to it. Use that as the basic content type for your 50 libraries
and you're done.

"since you have access to code in the workflow  ..."

Are you saying that I have access to the workflow code in the SP OTB
workflows? Where does the code reside?

No I mean if you write your own workflows in VS, then you have access to the
entire SharePoint Object model and can easily retrieve the information from the
list. The OOB workflows are compiled and can't be altered.

Nope; this assumes you're creating your own (which would be necessary for
your dynamic approver lookup).

To use a foreach loop on the SPList object,
I think you'd see better results with the GetItems method. The code would
look something like this (from the WSS SDK example; obviously you'd need to
specify the correct field name, type, and value in your SPQuery):

SPQuery oQuery = new SPQuery();
oQuery.Query = "<Where><Eq><FieldRef Name='SenderEmail'/>" + "<Value
Type='TEXT'>2 weeks</Value></Eq></Where>";
SPListItemCollection collListItems = oList.GetItems(oQuery);

I have not looked at the WSS SDK. Sounds like I need to do that.