Managed Documents Workflow

[jamesmiller]

We are currently in the process of implementing the Managed Documents application in our instance of ServiceNow.   We have found that the default workflow setup for document versions will not work for what we would like to implement.   We would like to review and approve documents based on workflow that routes the document "container" for review while allowing users to add versions into the application.   Once the review is complete we would want to take the last version that was uploaded and then publish this to a KB for end users to reference.  

We are currently experiencing an issue with the workflow that is attached to the document "container" (dms_document) table.   It will fire the first time without issue but any attempts to fire the workflow a subsequent time does not work.   Are there any restrictions on this table that prevent a workflow from running more than once?   What might be causing this issue?

Below is a high level outline of the process we currently have built:

Create a new document and complete required information

Default field of state = Draft

Added new form button to the Managed Documents screen which when clicked changes the state of the document "container" to awaiting review

The workflow which is attached to the Managed Documents application fires automatically when the state = awaiting review

The running workflow record can be seen from the Managed Documents screen by means on a related list which was created via a new system relationship

Like stated above the initial run of the workflow works without issue, it is changing the state back to draft and attempting to click the button a subsequent time to pick up the workflow, produces no results.

Let me know if you have any questions or need any further information on what was described above.

Thank you,

Jim

[rajeevlochan82]

The Most Appropriate scenario is to take care of logic in same workflow. So Once your approval is rejected then change document state , get the document revised and change state back to some state which can then loop back to approval in your workflow. This way the worklflow will keep looping until it is approved. So instead of ending your workflow after rejection , build some logic so that after approval rejection workflow is not closed completed but loop to some other condition in workflow.

I have not tried using Business Rule to Trigger Workflows but there are functions available which probably may start a new instance of workflow ...

http://wiki.servicenow.com/index.php?title=Workflow_Script#gsc.tab=0

[jamesmiller]

Rajeev,

The problem with putting the logic in the same workflow is that when a reviewer/approver rejects the "revision" because content is missing on invalid, the revision then becomes out of date.   Adding the additional steps in the same workflow would still keep the review going on a revision that is missing information.   The updated/correct content is put into a new revision and then the workflow is kicked off starting at step one.   This is why we are attempting to run the workflow on a "container" to give users the ability to add or change anything they need to for a revision and then approve the overall document.   Once it is approved by all, the most recent revision will be pushed out for everyone to reference in a knowledge base.

Thank you

Does anyone else have any ideas?

[bndeacon]

Hi James,

We recently began using SN for Contract Managment and thus, have also started using managed documents. The ootb functionality didn't work for us either so we did some fairly extensive alterations to the workflow. I'm not sure I have the answer to the method you're proposing, but I think I do at least have an alternative point of view to offer which you may find useful for your purposes.

How we changed ootb - first, we stripped the approvals process down such that regardless of the number of reviewers approving or rejecting, the state of the document does not change until the author moves the state through (to move from draft to review a button must be clicked, from review to publish, same thing). We did this so no singar listed reviewer could disrupt the workflow - everything basically just stays in waiting period until the author deems it ok to move forward. We did this because we found a oddity in the approve/reject function initially - the workflow could wait for any number of approvals, but the first rejection canceled the workflow. Next, we drastically changed the notifications triggering. For reviewers, we made the wording a little friendlier about needing their input, etc. However, for the author, we essentially recreated the document information area and revision approvals table in an email notification within the workflow. Why? One primary reason: information immediately available to the author for decision-making concerning the document without the necessity to go in to SN. Our notification specifically tracks whenever a reviewer takes an action - comment,   new attachment, approval/rejection - concerning the given revision.

For your purposes - if everyone needed to be involved in all movements of the document record, instead of just having the author receive the latter notification above, set it to also send to the listed reviewers.

Hope that helps,

Brittany