Methods for attaching multiple documents to a workflow

We're installin 6.5 and during get-acquanted testing, found that attaching documents to a workflow is evidently a one-at-a-time process. It doesn't appear that CTL-click works for selecting multiple files from a folder to attach to a workflow. Since some of our transmittals to customers can contain many docs ( >50 not unusual) and we're using workflows as the medium, does anyone know an efficient way to attach multiple, selected docs from a folder to a single workflow? We need the ability to cherry-pick the docs from the folder, that is, not every doc in the folder will be transmitted to the customer.

Nothing in either the Webtop manual or in my testing revealed an efficient way to do this.

Find more posts tagged with

Comments

DCTM_Guru

This must be due to your customizations. I can select multiple files and attach them to workflow. In the Webtop user guide, it even states this:

To start a workflow by first selecting one or more files, navigate to the files, and select them, then select Tools > Workflow > Start Attachments.

billthecat

Thank you, that helps. Here's a followup: if the workflow has already been started, ("Attachments +" shows up) and I need to add more files to the workflow, can I attach multipes easily in one motion using CTL-click, or do I need to do the attach-select action repeatedly for single files? For example, during doc import, I can CTL-click multiple docs in a desktop folder and upload them all in one motion. Does that same ability exist after the WF is started?

Chris_Campbell

Actually Johnny, this is a known issue that is being addressed by the TCM Team. I brought this up at EMC World this past year in some private conversations with the product managers.

What billthecat is referring to is attaching multiple documents to the same workflow package. That is not to be confused with attaching multiple workflow attachments. Those are two completely different objects and concepts within Documentum. Let me give some quick background for those who may not be familiar with the process and I'll explain where in the code the problem lies.

Background

Under the covers, a workflow is really made up of two fundamental objects: the workflow and the workitem. The workflow object is essentially a container object holding all references to how a process is defined and works at runtime. The workitem is the actual object that is acted upon when anything needs to happen. So whenever you are working with individual tasks, you're dealing with the workitem.

When you attach documents to a workflow, it can be linked to either the workflow or the workitem. When linked to the workflow, that information is stored as a workflow attachment. (dm_wf_attachment). When linked to the workitem, it is linked as a package item (dm_package). What is the difference? A large one. All workflow methods by default work only on dm_package objects. So if you're doing lifecycle promotions, it's done on those workitem packages, not the workflow attachments. Workflow attachments are pretty much there for the ride... support material or items that don't need any processing. Now, some workflow activities do have options to perform actions on workflow attachments, but that's the exception, not the rule.

A document is placed as an attachment or package based on a few key factors. If you highlight a document and invoke a "Start Workflow" action on it, the system places the document as a package. If you start a workflow without first selecting a document, it will usually place the document as a workflow attachment. You can also manually place documents as a workflow attachment any time during the workflow process.

The problem

Somewhere along the line, (post 5.3) the ability to manually place multiple documents into a package was lost. For example, if you select three documents to be in a workflow, the first document is placed in a workflow package. The other two are placed as workflow attachments. Try it and see. It's easily reproducible. That means that a workflow performing actions on those documents is really just acting on the single document in the workflow.

Currently, all form controls only allow the user to place a single object in a package. In some cases, this has been mistakenly hardcoded. It's as if (and this is just fantasy) some programmer along the way forgot the fact that packages are meant to hold multiple documents.

Note: this doesn't apply to Web Publisher workflows because it uses the concept of change sets. A change set is a single container object holding many, many objects. The single change set object is placed in the workflow package and the WP workflows then use the corresponding wcm methods which are written to open the change set object and grab the array of objects. That's why this issue doesn't pop up there. From everything that I can tell, this problem is mostly limited to the TCM product line since all those products use workflows.

The fix?

Right now there isn't one. I *hope* that one will appear by SP3, but I haven't been told. The problem isn't easily fixed because it's just above the DFC layer. However, the actual DFC code is fine and functions as it should. Which means that it's possible to write a few custom methods for your workflow using good ol' trusty DFC to merge the documents into one package. That's what I had to end up doing. The first activity in my workflows grabs all the "extra" documents and relinks it to the main package. It isn't pretty, but that's what we have to work with.

I'll try and post more later when I have time and if others have questions about this issue.

Chris_Campbell

You can add documents to a workflow after it has started (keeping in mind that they will be attached as workflow attachments and not as part of the workflow package. Easiest way is to open up a workflow task, click the "Add" link and select as many documents that you want attached.

billthecat

Wow, keep peeling away the layers of the onion. I think most of the people on the team were unaware of the distinction between a doc that is a package on a WF vs. docs which are attachments. From your last response, if I have it correct, even if multiple docs were selected before Tools/Workflow, only the first document encountered by the WF is considered a "package" ?

Some advice needed.

We'll be using WF's as one-way document curriers to the customer, and also as internal, iterative processes. For the internal processes, we thought that for ex., we would attach 15 documents to a WF and send it along to the next activity, that activity being for the performer to approve or reject the documents. What really happens in the current process is that the 15 may be accepted, rejected, or some fraction of the 15 would be accepted and the rest rejected. Can you suggest a way to handle that?

DCTM_Guru

This would require some customization, but my recommendation would be to follow the Webpublisher paradigm and create a container (ie folder) that would be attached to the workflow and link the documents to this folder. To approve/reject individual docs would probably have to map to custom attributes on the docs.

Chris_Campbell

billthecat wrote:From your last response, if I have it correct, even if multiple docs were selected before Tools/Workflow, only the first document encountered by the WF is considered a "package" ?

That's correct. Some form controls (say if you're using TaskSpace) only accept one document, or if they do allow more than one document: the startworkflow action grabs only the first document, places it into a package and then places anything else as a workflow attachment. It can be a bit tricky and it's confusing because the interface doesn't make it very clear which of your attachments are in a package and which ones are attachments. (It was easier to tell in 4.2 and 5.3 webtop IMHO.)

You can visually tell if your documents are in a package or in a workflow attachment. You just need to know what to look for. Open up any workflow task from your Documentum inbox with multiple attachments. The first document listed is usually in a package (as long as the workflow requires a package.) Any other documents in a package should visually line up directly under the first document. If the second document shown is indented then it's a workflow attachment. If your eyesight is bad, then always dump the workflow and workitem objects to check for sure.

billthecat wrote:We'll be using WF's as one-way document curriers to the customer, and also as internal, iterative processes.  For the internal processes, we thought that for ex., we would attach 15 documents to a WF and send it along to the next activity, that activity being for the performer to approve or reject the documents.   What really happens in the current process is that the 15 may be accepted, rejected, or some fraction of the 15 would be accepted and the rest rejected.  Can you suggest a way to handle that?

The problem I describe only really matters if you need to do any default workflow actions like lifecycle promotions or applying an ACL. Any custom methods you write can point to whatever they need depending on your requirements. Your scenario can be handled despite the above described little hiccup. (In fact, that's easy.) My personal preference is to package 'em all up. (Best practice is to have supporting documents, items that aren't part of the actual workflow but need to be referenced as workflow attachments and keep the real documents in the packages.) It's developing a methodology to handle the 15 documents which could be rejected or accepted.

There are a few lazy methods to go about this: make a separate workflow for each document which will drive your users insane; keep them grouped together creating a "accept all or none" situation; or make a workflow with 100 single package "containers" that you may or may not need.

Offhand, there are two ways to go about this. The first is attach all the documents and let the task performer remove the documents if they are deemed to be "rejected". This requires just about zero custom coding to do, but may not fit your security requirements and the rejected documents wouldn't have a way to be edited/fixed. (Finishing the task would be considering accepting the documents left and completing the task.)

The second would be to use a more elegant UI (i.e. Forms) and a custom method or two to flag or note the documents that need editing and a followup activity using your custom method to remove the offending documents and route them elsewhere or start a sub-process with those bad documents.

Chris_Campbell

DCTM_Guru wrote:This would require some customization, but my recommendation would be to follow the Webpublisher paradigm and create a container (ie folder) that would be attached to the workflow and link the documents to this folder.  To approve/reject individual docs would probably have to map to custom attributes on the docs.

The "change set" paradigm is one way to go about it. If you want to do it properly, you just need to keep an eye on your document links and do the proper cleanup afterwards. You'd also need to do some initial setup somewhere. Either by creating the folder ahead of time and manually placing/linking the documents to the folder, or doing it programmaticly in the workflow. If you have WP, then there's nothing stopping you from using the wcm methods to help you out.

Approving and rejecting individual documents if you don't use the "Hey, I trust the user to add/remove documents" methodology would require a way of tracking which ones to keep and which ones to reject. Easily done in 6.5 using a SDT. You can write a form validation method that writes the good/bad document lists to a repeating attribute in the SDT and have the following activity with a custom method do the actual dirty work of sorting the mess out. The SDT is also auditable by BAM so you can track what was dropped/added... whatever. Using a SDT avoids using custom attributes on your documents, especially for storing values only needed for when a document is in a workflow.